DecisionMaking

DebConf is intended to be a flat organization (just like we think Debian should aspire to be). This means that there should be some sort of consensus decision making kind of process.

Decisions happen in meetings, via joint authority of everyone there, with the power vested by virtue of being a public meeting with a published agenda. An idea is given, and there is debate, and once there are few enough objections, it is approved. There is not usually a vote, but people's opinions are weighted by virtue of their past experience and knowledge of the matter at hand.

But, you say, a bunch of people in a meeting seems too ad-hoc to be a bad idea, you are right. But we have a secret: communication and transparency. (okay, not really a secret, but perhaps a mystery to some people). If all information can be made available, the wisdom of everyone together can provide a remarkably good decision making platform.

Idea creation

Before decisions can be made, there need to be specific things to decide.

The best strategy is to start with what is known to work, and incrementally change from there. If things are reinvented each year, it makes a much more work than is necessary, and thus makes DebConf less sustainable. With incremental changes, hopefully it is possible to keep improving in a sustainable manner. Also, it is pretty important to not reinvent things each year for another reason: things are complicated, and did not spontaneously emerge in their present form. Trying to make a new complicated thing will likely have all sorts of unforseen issues. The exception to this is making things new and minimal to allow them to evolve over a few years.

There is a close interplay between those who are doing the work, and those who have done it in the past ("wise old wizards") (and attendees). Clearly, those who do the work could decide they don't want to do something. However, the point of DebConf is not to make an ideal conference for an organizer (but it should be fun, or else they won't do it). It is to make an ideal conference for attendees. And for this, feedback from attendees is critical - and for this, the old wizards are a good proxy.

Ideas should be documented somewhere. The wiki is better than the mailing list, since it allows a single point for things to be improved, instead of needing to follow an entire email thread.

If possible, to keep things long-term sustainable, there should be a common every-year procedure listed on the wiki. Any special local changes, applicable to this year, can be listed on a year-specific page.

Decisions

So, you, have documented your great idea, and want to get a go-ahead for them. It's a bit different from the past, so you want some sort of "approval" before you start doing something that might not work out so well. But there is no single person to ask permission of - and that is by design. The typical process is to discuss and document (see above) the proposals and ideas. The purpose of a meeting isn't so much to have the same people debate again, but to seek broader feedback. At the meeting, "wise wizards" (mostly old organizers and attendees, who don't have much time for DebConf anymore, but have much experience with what works and doesn't) start paying attention. The meeting announcement is a reminder to check the proposals and pay attention to IRC. During the meeting, they'll give advice and make suggestions. If you got sufficient feedback before this point, with luck there will be collective "sounds reasonable, good luck", and then you can consider things approved.

Let's say that there becomes an issue which is so difficult that it appears decisions can't be made.

If there are multiple reasonable paths (as agreed by enough people), then whoever does the work gets choice in implementing it. (If someone really has another idea, both could start working and then decide which to use later.) If no one wants to do something, then let it not be done (until later). This is a good way to get new contributors, too.

If the disagreement is some people thinking an idea should _not_ be done (in preference of something else), then it is more complicated. Historically, this is often local team (or newer people) proposing an idea which older people are concerned about (but it can be anything). In this case, there should be more documentation, clearly stating advantages and disadvantages of each option, in order to try to bring things closer together. It's always better to assume disagreements come from slight lack of understanding, instead of some sort of fundamental difference in goals.

If there is a real impasse, then the wizards and perhaps other attendees should be polled for their preference. At the end of the day, the their thoughts and the status quo should probably take precedence over something new. If they are, well, then elders probably know best.

Advice for local teams: These "wise elders" must not be alienated. Their feedback is critical to the success of DebConf. Seeking challenges to your ideas leads to better results. If you seek advice early enough, and make use of it early enough, there won't be as many problems later when you go down a heavily diverging path.

Notice that key among all of these things is transparency and communication. With sufficient communication, lack of dissent can be considered agreement. Without sufficient communication, you may not find anyone who can give a go-ahead. Make sure you send information well in advance of decisions (an email a day before meetings, instead of dumping everything in the meeting). Make sure people are kept up to date as things develop. Make sure there is an budget (as accurate as can be) at all times, that can be agreed upon and used as a basis for future decisions.

After decision

Once a decision is made, there is a tendency to not update the docs with any modifications agreed upon. This shouldn't be forgotten!

Practicalities

DebConf Chairs?

In a twist from our idealized flat organization, there are some "DebConf chairs" appointed. When first appointed, it led to a steady decline from consensus decision making to primarily seeking chair approval.

The DebConf chairs should not be looked to for approval. They will probably be in the "wise elder" category, but if questioned, they should provide help in seeking the advice of the rest of the team, not provide advice or decisions themselves. In practice, it is somewhat frequent for the local team to get fractured from the elders, and DebConf chairs should be primarily focused on keeping this relationship healthy. Thus, your mental model of how DebConf works should place no special importance on the chairs.

Budgeting

Money is one of the most complex complex matters we have to deal with (because it is the most limited). Big matters should be thouroughly discussed in meetings, due to the complex nature of trade-offs. Small things should be approved in bulk, as part of a budget decision, with details delegated to those people in charge of the specific item, subject to continued updates as they do things, and warnings before the money is actually spent.

I would recommend creating a sorted list of things to spend money on. Amounts and priorities are allocated. When more money becomes available (either through extra fundraising or attendees fees, fewer sponsored attendees, or cost-cutting), the next thing on the list becomes allowed. This way, an entire money discussion doesn't have to happen at every meeting. The budget coordinator keeps track of these things and provides advice on when money is available.

Splinter ideas

Ideally, the team will be focused on the core conference, and not focus on specific events at the conference. There are many things that can happen at the conference which would be nice, but are not critical. DebConf should provide a base for these ideas to occur. If someone wants to make them happen, they should be given support and

These types of things can include: conference proceedings, talk tracks, . The model can even be extended to other more central activities such as day trip, conference dinner, ....

Institutional memory

Changing everything when you join DebConf probably isn't best. I would recommend the following system: Work with a team one year, following in the footsteps of those currently on the team. Improve things, but don't change things too much. Then, the next year, continue with that team and make all the changes you want. Since you have experience, your changes will be much improved.

Under this system, there is a simple way to make decisions: those who have done it before can decide how to do it in the future. The more experience in more different areas one has, the more weight they should have. Yet, with experience comes responsibility: the responsibility to realize that slow but steady changes and improvements are good, and is better to mentor people with new ideas than to keep things the way they were before.

A key part of this is a natural progression of turnover: there are many different DebConf teams, and we need new people. After you've done something a few years, see if there's something else you want to do, and let new people come up with their new ideas. Eventually, there are new team members taking over for you before you are burned out and DebConf suffers.

Last words

Notice that key among all of these things is transparency and communication. With sufficient communication, lack of dissent can be considered agreement. Without communication and transparency, lack of dissent just means that people don't know what you are doing. If you actively seek feedback and challenges to your ideas, then lack of dissent also implies that people agree.

Without sufficient communication, you may not find anyone who can give a go-ahead. Make sure you send information well in advance of decisions (an email a day before meetings, instead of dumping everything in the meeting). Make sure people are kept up to date as things develop.