The week before DebConf has been traditionally been DebCamp. This has been advertised as a time for core teams to come early to work on their projects together, and this post will talk more about what that means.

At DebCamp, there is not much infrastructure set up yet. We have (unfurnished) hacklabs, accommodations, and usually food from the very beginning. We'll have Internet access, but the network and power distribution isn't set up yet. People find what they can and make their own space to work. The DebConf team works on setting up hacklabs starting on day 0 or 1, and the DebCampers serve as the test subjects to make sure that everything works.

There intentionally aren't many scheduled activities during DebCamp. The organizers have too much else to do, and events aren't the main purpose of DebCamp. If some people wanted a place to meet, they could probably find a place, though. Some years, there have been one or two workshop type events on the DebCamp schedule.

DebCamp has frequently been explained by "Development teams like debian-installer and debian-edu also have the possibility of meeting beforehand for undisturbed collaborative work. ... Interested teams should contact the organizers upfront to make special arrangements." (From the DC10 website) Also included in DebCamp are the DebConf organizers - we desperately need that time to pull organizers from over the world together to get us on the same page locally. Furthermore, anyone without a workplan can attend DebCamp by paying their actual costs.

However, saying that DebCamp is limited to these groups of people doesn't reflect reality: Anyone can attend. Thus the DebCamp description doesn't necessarily reflect the actual limits for attending. This has the appearance of resulting in (and some people believe it has) a DebCamp which is biased towards those who well-connected with organizers, since they know that basically anyone can go and get a free extended holiday with Debian people. In fact, getting anyone to review the submitted workplans has met resistance in the last few years.

For DebConf10, we did manage to reach agreement to filter out possible tourist-like people, but it was a similar (or only slightly more strict) criteria than DebConf itself. This was done very late, too late to be fair to force adjustments in travel plans of too many people. The difference between the DebCamp listed criteria and who has gotten sponsored for DebCamp in the past caused contention among some new organizers this year. Why didn't they know that they would have qualified for DebCamp past years? The moral of the story is that we need to be more clear on the purpose of DebCamp and make the actual qualifications for attending concrete and well-known so that it remains fair.

Of course, it's also true that non-core developers and other interested people to attending DebCamp is a good thing, since it is a strong motivator to get more involved in Debian. Local people are encouraged to attend and learn/hack/volunteer. DebCamp isn't meant to be exclusive, just to reflect the realities of a limited budget.

DebCamp is a very important part of DebConf, both for Debian development purposes and for DebConf set-up purposes. However, since it is a week of limited attendance with mostly the same people attending year after year, we need to ensure that it remains transparent to the rest of Debian.

The following post is the work of Pablo Duboue, the DebConf10 fundraising team leader.

So you want to make DebConf, eh? You will need quite a bit of money then. That's when fundraising comes into play.

There are traditionally two sources for funds for DebConf: government and businesses. A third one, micro-donors, has been mentioned, but haven't been explored yet. (Note, in this text I use the terms sponsors and donors interchangeably, as all sponsors are actually doing a donation to the Debian project earmarked for the use at a given DebConf.)

Government funding has been key in a number of DebConfs. In DC10, though, by the time fundraising proper started, it was too late to secure it. Extrapolating from two DebConfs that had government funding, I would venture the following two pieces of advice: target a government level as local as possible (city, provincial level) and try to secure the funding at the time of the bid (which, by the way, can help you win the bid). A successful process will include government representatives aware of the bid status and the whole bidding process. This partnership can help unlock extra government resources such as housing or transportation. But to reiterate, if you haven't at least applied for government grants by the time the DebConf previous to yours is happening, then you have to plan to go along without government funding.

Business funding for DebConf includes a significant amount of recurring donors. Keeping them happy is even more important than any money they will put forward for a given DebConf. Now, because of the high level of recurrence and the fact that government funding can cover easily one third of our costs, fundraising without government funding really means your projected funds are one third off. If that is the case, make sure to communicate that to the rest of debconf-team and even the larger Debian community (see below "asking for help").

This entry has been truncated read the full entry.

The DebConf registration team has the hard job of coordinating accommodation, food, and payments for hundreds of people.

There are two major dates here: the sponsored registration deadline, and the reconfirmation deadline. There is also the date of opening registration, but that's usually more a matter of "how soon can we?" than "when should we?"

The sponsored registration deadline (April 15 for DC10) is the deadline for requesting sponsored accommodation, food, or travel. This allows us to figure out how much we'll have to pay for attendees - attendees who register after this point should pay enough to cover their own costs.

The reconfirmation deadline (June 10th for DC10) is used as a ping for attendees, particularly the sponsored ones. Attendees must reconfirm they will attend, so that we don't waste money reserving more food/rooms than we will have people using them. This deadline usually depends on the date we must give firm numbers to our accommodations.

Historically, registration hasn't ever closed, anyone can come, just if you register too late you won't necessarily get any free stuff (and definitely no free food/accommodation). The deadline for food and accommodation themselves has been based on the logistics of the conference itself - DC9, when we ran out of physical rooms for accommodation, and DC10, when we had to give firm housing numbers to Columbia. Food has tended to be easier as caterers could take updates on shorter notice, usually the day before.

DebConf8 began a system where attendees could pay a registration fee if they desired. This was encouraged, for example, for attendees whom could get this fee reimbursed by their company, but was not required nor encouraged of sponsored attendees. DC8-9 had two classes of fees: Professional, covering the actual costs, and Corporate, covering about double of professional and for companies or registrants whom could provide extra financial support for DebConf. DebConf10 added an extra layer of "pay per day" on top of this.

It's up to the registration team to pin down attendee numbers as early as possible, as this is usually the biggest cost. DebConf provides food and accommodations to a huge number of people, but the numbers are constantly changing. It's hard to know how many people will drop out at the last minute. It's hard to know how many people will actually pay a corporate or professional fee, as opposed to mistakingly selecting it when they'd rather something else. Our registration system can't support all the little intricacies of how much an attendee will cost us, or pay us. Without knowing how many people will attend, how can we accurately get the right number of meals and right number of rooms? Sponsored people may always choose to not eat some meals with us, possibly saving us money there. How many people with travel sponsorship will actually request their full reimbursement?

The registration system, Pentabarf, is used to track attendance numbers, but it isn't completely reliable. Not everyone in it will attend all days, and most people who aren't staying with us don't have accurate dates of attendance. Thus, it can only be used as estimates, not for all decisions.

The difficulties above are challenges for the registration and budgeting teams, but are not too bad - they just require thought, time, and answering many questions from attendees.

My last post discussed the year-to-year budgeting of DebConf. This post discusses what makes budgeting difficult within one particular DebConf. Since every DebConf is unique in its arrangements, the particular difficulties always vary year-to-year. For example, DebConf10 was easy in that Software in the Public Interest was in the same country so that we had easy access to bank accounts, but more difficult venue payment logistics. I'll use DebConf10 as an example below.

For DebConf10, we get our venue "for free" thanks to the support of the Columbia Computer Science department. However, we had to pay for guard costs after building hours, and custodial costs. For custodial costs at least, we had to go through many layers of bureaucracy, and people kept insisting it would be more than they quoted. (It ended up being about half, since DebConf attendees were so responsible!)

DebConf sponsors many attendees. This means that all their food and accommodation costs are paid by us. We have sponsored registration and reconfirmation deadlines to set a maximum of the number of people we have to sponsor, but people are continually dropping out and it's hard to know just how many people to reserve for. Sponsored people won't always eat every meal with us, and usually won't decide until the day before - so figuring out food amounts is hard, too. Furthermore, we have unsponsored people who will want food and accommodations (paying themselves) which we must somehow plan for.

Different venues operate on different payment rules. This year, CU Housing was fairly strict on asking for attendee counts and room assignments two weeks in advance. Then, as time gets closer, they got more flexible, and in the end told us that they will, in fact, only charge based on number of people actually attending - a huge win for us. Similarly with CU Dining, we had to go through great lengths to make sure that we would pay only for meals we ate. At CU, food had to be paid in advance, but accommodation and other costs are paid afterwards.

We have to guess how much will be spent on miscellaneous supplies once DebConf starts. We have to then decide how much to spend on extras such as the day trip or conference dinner, and how to sponsor those, if possible.

Debian (and thus DebConf) has money held in trust in many currencies in different accounts. Different sponsors will pay to different currencies, depending on what is convenient for them. This means that we need to consider fluctuating currency conversion rates, and decide if and when to transfer money. In general, DebConf hasn't transfer money just to make sure the DebConf-tagged money gets spent first. Some surpluses are best left in other countries to help pay future travel sponsorship since it is expensive to move money out of the country. Some conferences may result in a net movement of money from USA to Europe (more donors in one, more expenses in the other), some the other way around.

Travel sponsorship is in the form of reimbursement. These can take many months to have the documentation received from attendees and the reimbursements all sent out, and thus finalizing the budget and surplus for next year.

The overall principle we've tried to stick to is plan for a balanced budget in the worst case scenario, and then be happy when it ends up better than that.

At the DebConf&Debian BOF, someone mentioned how budgeting for any (free software) conference is hard. I think that's certainly true. Some of the registration fluctuations could be made easier by being less flexible, but DebConf wants to serve our attendees even if it is a bit of extra work for us. Each DebConf will have its own ways budgeting is difficult, but things have always work out, and usually with a bigger surplus than we were expecting.

One of the most debated points at the DebConf&Debian BOF was money management. Let's talk about how it works in an ideal world, and then how it tends to work in practice. This post only talks about year-to-year management, I hope for another post talking about the complexities of budgeting within a single year.

In an ideal world, DebConf fundraises all the money it needs to go on. There is a DebConf sub-team for fundraising, since Debian doesn't have its own fundraising team. This team make brochures and solicits sponsors - there will be another post about this by someone on the fundraising team.

We do our best to raise enough money to cover the conference, but it's long and hard work. In the months leading up to the conference, we are almost always running short. However, in the end, somehow, it comes through by a combination of cutting costs and continued fundraising work.

The money is held by various nonprofits like SPI in the USA and FFIS in Europe. They hold it in trust for Debian. I think most people on the DebConf team agree that this money belongs to Debian, but is earmarked for DebConf since it was fundraised for DebConf. In the past, the DPL has not been asked for permission to use DebConf-fundraised money to put on a DebConf, since that's always been kind of obvious that it's for DebConf.

Planning how much it will cost is hard. Venue costs aren't always known in advance, and we don't know our number of attendees until late. There are many uncertainties, which will be described later. These questions are hard to answer, but not impossible. Most of they time things work out in our favor.

At the end of the conference, we tally everything up. Usually(=always, as far as I know), there is a surplus. This surplus is important, since DebConfN+1 usually needs a little seed money to get started before the new funds start rolling in. Historically, this seed money has been used for DebConfN+1, since it was raised earmarked for DebConf.

In practice, it works out mostly like this. We keep track of the money, and try to stay within our budget, and cut things when we need to.

For the last two years (coinciding with the recession), we have expected a deficit in the months and weeks leading up to DebConf. In these cases, we asked the DPL for some money to be given from Debian general funds for DebConf, and we provide background on our fundraising and budget status for use in making that decision. Both times, the Debian funds went to ensure that we could get travel sponsorship out. Debian general funds are not used without DPL approval.

Also, keeping all the paperwork straight is a hard task. We have limited people, and the budget-trackers are always doing many other jobs, too. Personally, I'm not convinced that we always know how much the exact post-DebConf surplus is and where it is (SPI, FFIS, ...) each year. It sort of gets morphed into the general Debian money, and then we know "we have (about) XXX surplus" and then use that amount as our starting seed for the next year, taken from wherever is convenient.

If Debian gives money to help make DebConf happen, it's usually as a loan. However, this loan isn't tracked carefully year to year. Someone looked up numbers during the BOF and reported that Debian has given/loaned 50,000 USD to DebConf over the years, but it's hard to know just how accurate that is. For comparison, the total DebConf budget over those years has been close to 1,000,000 USD, as best I can figure.

We've tried various types of accounting software with mixed success. They are a lot of overhead, and we usually revert to keeping track of things in spreadsheets.

Our goals for budgeting (being self-sustaining) are good and well agreed on, but the implementation is hard.

However, it's a place where it is easy for dedicated volunteers to get involved. If you wanted to help to make this better, you could do a lot of good by watching #debconf-team and lists, making careful records of our cash flow and where it comes from and goes to. All money we spend is announced and documented on the lists, so the information is there. To really do a complete job, this person would need to remain motivated in the months after DebConf and wrap up all of the final payments. Preferably, we'd have the same person year after year.

There are many more suggestions that both others and I could make, but I'll save those for later.

Selecting a DebConf location hard, and can certainly get intense at times. This is an area where the DebConf team and the Debian project can work to improve our processes. There is a wiki page to collect our thoughts in preparation for a discussion later, as planned during the DebConf&Debian BOF.

First off, there is a time at DebConfN-2 for interested localteams to describe their rough plans. These are videoed, and you can view the events online if you would like: for dc11 at dc9, for dc12 at dc10 .

There has been a nominal deadline of December 31, 20XX-2 for submitting a bid (not finalizing), but this has been bent in the past.

While teams are preparing their bids, they should look at the location checklist. This summarize what past organizers know to look for in a location. There are questions sorted by category and priority.

To organize their information so that people can understand, teams prepare bid documents on the wiki (DC10, DC11, here are the winning bid documents: DC10-New York City, DC11-Banja Luka). These start off by just answering all of the questions in the location checklist, but then get a lot of work to make the pages clear and complete. Anyone can browse the pages and ask questions of the teams anytime.

There are several mini-meetings where teams describe their progress, and organizers and other interested people can ask questions. In these meetings, the channel is not moderated. Questions tend to be about the location checklist criteria related things.

In February/March, there is a big selection meeting. This is the only DebConf meeting where the channel is moderated and only voiced people can speak. The voiced people historically are two moderators who keep things moving, two other past DebConf organizers to ask questions and relay questions from the audience discussion channel. (These facilitators have been self-selected in the past, usually in the minutes leading up to the meeting.) Then, there are two people per location whom are voiced. There is a audience channel for everyone else to discuss, and the moderators/helpers will look there for questions and relay them to the main channel. There have been unvoiced Q&A periods and periods which are designated for relaying questions from the discussion channel.

These meetings are logged (dc10 selection, dc11 selection)

Teams are rated based on the priority list. There has been a simple point list the last two years, -1 to +1 for each point on that list. For each item, there are debates on how many points each location should get. Points are added up, and a result appears. In the past, this has been a simple arithmetic sum, so all items are weighted the same (despite nominally having different weights). In the case of a tie or close call, there is more discussion. For DC10, there was a tie, and NYC won after opening the meeting to the audience and getting their opinions. I didn't pay enough attention to the DC11 selection process to be able to say how that close call was resolved.

While this isn't really part of the selection process, local teams can give presentations at DebConfN-1 about their location and encourage attendance: dc10 at dc9, dc11 at dc10

So, there it is. Overall, there is a lot of openness in the process, but the exact rating schemes in the decision meeting could use discussion. The criteria are established, but can be refined each year based on what we learn.

If you would like to comment on how to improve this in the future, please use the selection process wiki page (first person create it). We can follow up with a list discussion after our ideas have been fleshed out.

Now that I've mentioned the general timeline of a DebConf, let's talk about the "global team", "local team", and decision processes.

Who is the "global team"? Basically, it is the active people on the debconf-team IRC channel and mailing list. Anyone can contribute, but we know who is who. Those with the most moral authority tend to be those who have organized a past DebConf or been involved for many years, and their opinions always have a high weight. Many of them are still around.

So then how are decisions made? It's a combination of consensus-based and "whoever want to, do it". We discuss ideas based on what experienced people have seen work/not work, what new people want to try, and perhaps most importantly, who can make it happen. (this is where you fit in). There aren't necessarily leaders picked beforehand, instead leaders develop themselves. Overall, this is similar to any other team in Debian.

There aren't formal gatekeepers who can veto anything, but if someone sees a problem, they should speak up and get critical mass of people to fix things. Those who hold the money (SPI, FFIS, the DPL) of course will monitor our processes and would intervene if someone started going off course.

Typical global team tasks are fundraising, travel sponsorship selection, talks, registration.

The local team starts out as the winning bid team. They started out figuring out local logistics for their venue, and up until arrival, they are the ones who are handling the local tasks (venue, food, accommodation, entertainment, day trip, Debian Day outreach). They should keep the global team updated on their status and what they are arranging, so that the experienced ones on the global team can give feedback. Global people will, of course, get involved here where they see fit and can help.

The local team shouldn't exist in isolation though, anyone local is highly encouraged to get involved in "global team" tasks. The more coordination and bi-directional help we have, the better.

It isn't the job of the local team to put on all of DebConf themselves. They aren't selected and left with free reign, they should integrate with and understand the history of DebConf, and then work on whatever improvements they want, whether they are local or global.

So in short, there are the names "global team" and "local team", but really, it's all one big Debian team. Those who are interested work and make things happen through a consensus-driven process. Things aren't always perfect: we have conflict, disorganization, leadership turn-over, lack of volunteers, lack of time, all the usual things that happen in volunteer organizations. I think most people want to work towards this ideal, and we hope that this series of posts will help us to improve. Most importantly, when you see something you'd like to work on, you can get involved.

A DebConf doesn't just happen in a few months. It's not even a year, it's closer to two or two and a half. I've only been through two cycles, and I think this process has happened for the last three or four DebConfs. This post will talk about a "brief" summary of the general DebConf timeline, with elaboration on all the bits later. This post describes the preparation of DebConfN in year 20XX.

At DebConfN-2 (mid 20XX-2), there is a talk where interested groups can describe their location and how it would be suitable for a DebConf. This consists of a short presentation and discussion, but not many details by this point. No decision is made here.

Throughout late 20XX-2, teams develop their bid as best they can. The last two years there has been a nominal deadline of December 31 20XX-2 for submitting a bid, but like all DebConf deadlines it's more for guidance than a real deadline. There are various checklists and templates to provide guidance here, which I'll describe later.

Early 20XX-1 brings a lot of work to finalize bids, and then the actual selection process. There is a burst of mailing list traffic where people ask questions and help each other refine their bids. There are several meetings where bid teams give their status and people can ask questions. In February or March, there is a selection meeting.

After the decision meeting, there is a big round of cheers but people soon refocus on DebConf N-1 since it is more urgent. Ideally, most of the people involved in DebConfN help with DebConfN-1 both because DebConfN-1 needs help, but also to learn how to make DebConfN go well. The DebConfN local team keeps working in the background doing whatever is needed to prepare for their conference.

At DebConfN-1, there is a talk where the DebConfN team presents their progress to the DebConf attendees and tries to build support.

Late 20XX-1 brings the end of the previous conference and time for N's localteam to really start getting stuff done. Throughout the last part of the year, we try to work out enough details for registration to begin: final conference dates, locations, accommodation, etc.

Registration opens in early 20XX. The exact dates for opening/sponsorship deadline/reconfirmation/etc all depend on how early in the year the conference will be. There are nominal deadlines published, but they usually slip. With our limited volunteer base, it's hard to make things go according to schedule, but things always work out.

Around this time, the fundraising team really starts working hard. Also, the travel sponsorship team needs to meet to decide who gets funded. The talks team needs to issue a call for events, read, and select them. The video team needs to make sure that they will be ready for the DebCamp setup period. There are many more things I'm forgetting, too.

In the months before arrival, it becomes kind of crazy from a local perspective. There are many things to get organized before people arrive, mainly focusing on food, accommodation, and venue space logistics.

Once DebCamp starts, things get even more complicated, but we have a flood of experienced DebConfers from around the world come in, and they all know a bit and can help out. DebCamp is effectively the DebConf preparation week to the organizers. DebCamp becomes DebConf, and much bigger, once all attendees arrive.

Eventually, people leave and everyone goes home. This doesn't mean local stuff is over - I'm still engaged in DebConf10 wrap-up, making sure everyone gets paid and everything is returned.

Mid to late 20XX brings a brief period of rest for most people.

There is one last thing to do, though: the DebConf final report. This describes the events of DebConf, and is very useful for getting sponsors. It is also a valuable reference for future years looking back on the lessons learned. You can browse past final reports in our archive . Because everyone is tired, this too frequently gets pushed off until early 20XX+1, when DebConfN+1's fundraising team needs it. A frantic rush finishes up the missing pieces and it's done.

So, there you have it: a rough outline of the timeline of a DebConf. It extends from mid 20XX-2 to early 20XX+1, more than two and a half years. This post nowhere near describes all the details that go into DebConf, almost any of the paragraphs above could be made it's own post. Stay tuned for them.

At DebConf10, there was a BOF entitled "DebConf & Debian", discussing about the similarities and differences of Debian and DebConf. At times this became a little bit heated as people wanted more integration and transparency.

I don't think the differences are that great. I don't even see them as separate. I see DebConf as a Debian team, one that has to release every year on a short time frame. Things are rushed, things are not perfect, but we welcome anyone who wants to help.

It's my goal to start a series of posts on DebConf, in the spirit of other teams documenting themselves and calling for contributors. I hope to let people know what's the current state of things, how you can get involved.

If you want to get involved, join #debconf-team on OFTC, or subscribe to the debconf-team mailing list at http://lists.debconf.org/ . There are many people who would like to help you get involved. Right now (post-debconf) is a bit of an idle time, but one of the few times that big changes can be made. DebConf is a do-ocracy, if you'd like there to be a change, the best way is to help implement it. There may be some resistance, but we (at least I) will help to find a solution.

These posts are my take on things, I can't claim to speak for the DebConf team. I don't know all of the history of DebConf, and I may get things wrong. I'll run these posts by the rest of the DebConf team for suggestions/corrections, but there may still be things wrong. You should consider anything useful to be thanks to the DebConf team, and anything wrong to be my mistake.

I've only been involved in DebConf for two years. I first got involved as part of DebConf10, but spent most of 2009 working on global management things for DebConf9. This year, I spent more time with local on-the-ground tasks. I'd like to keep being involved next year - and hopefully keep improving, with your help.