Communication

This page lists the various communication channels and their use, and provides hints for helping everything to go smoothly.

The most important part of DebConf is transparency and openness. This is because:

• Debian is an open organization.
• DebConf is constantly turning over. You want the next generation of team members, who are lurking now, to be able to see what is going on so they be informe. If we aren't open, we can't get the next generation to step up.
• Transparency is accountability.
• There is always a shortage of people. Make it easy to get involved to help with that shortage.

Communication Channels

IRC

• Good for real time communication and brainstorming. Not good for lasting decisions or wide consensus. Not everyone is expected to read all IRC scrollback, though many people do. As a suggested workflow, brainstorm on IRC, organize everyone's ideas onto a wiki page, then start a mailing list thread about it, then if people like it, implementation will be delegated at a meeting.
• #debconf-team is for overall work and is the main list.
• #debconf is where most attendees hang out and plan spontaneous activities, coordinate during the conference.
• #debconfN-localteam (or whatever it's called that year) is the local team channel. Most significant work should be on #-team instead. For more thoughts on this, see "local vs global" below.

IRC meetings

• Used for decision making. Enough people should pay attention that decisions can be considered binding, but time here is very limited, so, this is not good for brainstorming of figuring things out. Sometimes brainstorming and solving problems has to be done during meetings, but people will start to get cranky. A better strategy is to try to brainstorm and create options in advance - either wiki pages or mailing list threads - so the hard thinking is done in advance.
• Should be announced several days in advance. Held on #debconf-team. Logged.

Mailing lists

• Best for broad discussiion and decision making.
• If threads get too big here, consider using the wiki for organization.
• debconf-team: General team work, and most local planning as well. This is the "master" ist and everything should be . With enough consensus, decisions here can be considered binding. Key people are expected to at least be aware of what is going on here.
• debconfN-localteam: Localteam mailing list. This was originally created as a list for local people to discuss things in their own language. This isn't a place for local people to work and organize everything local in isolation from global knowledge. Global peolpe often subscribe here, but that's only a small subset.
• debconf-discuss: Generally for attendees and attendee-organized things.
• debconf-videoteam:

Wiki

• Best for long-term storage and institutional memory. Unlike the things above, it is low-barrier and also random access, so it can be organized. Several people working together can take a wiki and turn scattered ideas into a plan that can then be decided.
• I can't emphasize enough how important it is to organize all of the scattered plans and information onto the wiki. Just do it.
• New team members are encouraged to read pages in Category:DebConf_Manual, and general procedure pages should be placed in that category.
• There is also a DebConfNN category each respective conf's pages should be placed in.
• Piece of advice: Fewer, longer pages about a unified topic tend to be better than many short pages, since short pages get lost and forgotten when more well known ones take over. Also, people will at least skim a big page but may not get around to all the small pages.

Website

• Like the wiki, but focused on attendee-facing information. Thus, this is more "static" and official, but also means there is a greater barrier to putting information on it. Information on addresses, phone numbers, locations should be here.
• For specific things, there are often links from here to the wiki for coordination purposes.

VCS: debconf-team

• A VCS designed to hold slightly sensitive files, mainly: money, when related to sponsors or attendees, attendee information, sponsor information, venue information which the venue wouldn't want released. If in doubt, consider debconf-data. Being open makes it easier to get more help, which is critical for both the short-term and long-term success of DebConf.
• A repo admin must allow access to each person using this. This can sometimes be hard to acquire. You don't necessarily have to be involved for years an dyears to get access, if someone knows you well enough (especially local people).If you need access, consider asking someone on your localteam to advocate for you. Difficulty in getting access is another reason to try to not put inforation here without reason.
• Files in here don't disappear, and are available for future teams. This is important for institutional memory, so that future teams can check past procedures. But this also means that extremely sensitive data (example: attendee reimbursement forms with bank numbers) shouldn't be put here: this doesn't even need to be shared with the team once reimbursement is done, and has no reason to hang around forever. The procedures and blank forms, however, can be stored (and should be in debconf-data or the wiki instead).

VCS: debconf-data

• Intended to be a low-barrier form of coordination, where as many people as possible can get access and help out.
• A VCS designed to hold public files, and files are viewable on the web (svn.alioth.debian.org)
• Getting read/write access here is intended to be a fairly low barrier step, so that people can easily help out. The more that is here, the more people can help.
• The website is stored in debconf-data.

Role aliases: registration@, content@, sponsors@, etc.

• Used for internal team communication, when dealing with specific private matters.
• The people on role aliases, when not discussing private (dealing with sponsors or people-specific details) should use a public mailing list for making decisions, then use the private alias to apply these decisions to specific people/things.

RT:

Registration system

Real-life team meetings

• They are good and important for local-team cohesion. However, don't forget to fill the Internet in as to the results. A quick mail of meeting minutes to -team is sufficient. Big decisions should be cross-checked with -team.
• When meeting with people from venue, hotels, etc, also send a summary to -team.

Common Problems

Things are getting too disorganized and the herd of cats isn't making a coherent plan.

• Try making a wiki page and collecting all the ideas, and having people revise that.

Should I use -team or -localteam mailing lists/IRC

• Just because something is local (food, venue, accom, etc), does that mean that it should be discussed on the localteam mailing list? Not necessarily. DebConf is built up over a long time, with lots of tips and tricks necessary for a good conference. It's important that local things aren't done independently, but instead work as part of the broader global team. Since many global people don't subscribe to every year's local lists, it is best to do as much on -team as possible. -localteam can be used for coordination of local volunteers, who want to do things, but not necessarily the month-long planning procedures.
• Put another way: local things interact very strongly with global things, so there isn't a good division. Especially since the local team changes every year, we can't assume local things will organized just like expected every year.

I want to plan something for DebConf, but don't want to get in your way, so I'm going to work separately.

• Don't feel an obligation to be separate just because you are donig something new. Use our lists, but realize most people have bigger problems they will be focusing on. They'll try to give suggestions where possible. Also, we need to take care of the biggest issues first, then will focus on fitting the smaller pieces in closer to time.
• Hidden motive: we want people to get involved in side projects, so that they will eventually become involved in more team stuff.