Weblog entry #16 for rkd

DebConf communication channels and decisions
Posted by rkd on Fri 28 Jan 2011 at 22:44
Tags:

This post is designed to describe communications channels and decision processes of DebConf. This is mostly designed to help new team members integrate into the team better and be able to contribute substantially. This only describes internal communication channels, not between DebConf and attendees.

I should emphasize that this is the ideal process. Since time is so limited, things get rushed. You shouldn't worry about the steps above slowing you down, they are mostly what you'd do anyway if you are working transparently. Furthermore, once something has been delegated to you, just try to be public in your discussions and document what you will do. This is supposed to be a guide to help you take initiative, not slow you down.


#debconf-team (on OFTC) is the primary IRC channel. Most people idle here. Discussion and decisions often happen here, but saying things only in IRC isn't enough. IRC is ephemeral, so important information and decisions should be on the website, wiki, or mailing lists. IRC is good for getting advice from past members and keeping people up to date, and real-time communication among teams. Groups actively talking among each other usually use this channel. Not everyone can be expected to watch IRC all the time.

The mailing lists, in particular debconf-team@ are for permanent records of meetings, and for getting feedback from all team members. For a decision to have weight, there should be a chance given for this list to provide feedback.

The wiki is the place for permanent and organized documentation. Ideally, the wiki is a place for team members and others to go to find out just what we are doing. (Official information for attendees goes on the website, not the wiki.)

Decisions in DebConf are hopefully made by delegation or rough consensus, but often time gets short and things have got to get done. Tradition and historical precedent play a big part: not everything can be re-designed every year. What follows below is a rough best-practice for a decision process, but I'm not saying that everything always is or has to be like this. Things get faster once you get more familiar with people.

People first should read historical documents or chat with people and learn how things have worked in the past. People should know what you are working on, either through IRC or a mail to debconf-team@. This will get you feedback early and perhaps some additional advice and help.

The group discusses and decides on some sort of proposal or course of action. This could be by IRC, lists, or whatever they need. It should be some public forum so that other people can watch and give feedback.

The group's proposal is sent to list for feedback. Hopefully, they would have a preliminary write-up on the wiki so others can add to it there. Perhaps there is more than one proposal and they can be given side by side. Sending a proposal isn't just so that people can object: even if everyone thinks it looks good, it is important that there is some record of the process. You can get other opinions on the proposal here, and if it seems there is rough consensus, then you could consider it decided - just let someone know that you are implementing it.

If it's not clear that there is agreement on the proposal, you should bring it up in a IRC meeting. Add it to an agenda, and we can discuss it. Discussing it at a meeting has the advantage that most people are there, so we can make sure that the idea isn't lost due to indecision. We want meetings to be efficient, so try to have at least a description on the lists first.

Finally, things should be documented on the wiki or website. This is important to maintain transparency, and since this will be the first place people look for reference in future years.