A while ago (early 2009), I created whiteboard.debian.net as a way to do real-time editing collaboration. While working for DebConf, I really wanted to be able to collaboratively edit text with people, and all of the web-based solutions I found at the time were non-free. Thus, I took mobwrite and wrote a very thin wrapper around it. Mobwrite is where all the cleverness is (and mobwrite is way beyond my expertise, by the way). Mobwrite is Apache licensed, so you can use it in other places, too.

Thus, whiteboard.debian.net was begun. It was never publicized very much. It has no authentication required and no history (the "static link" does provide limited recovery for mistakes, though). Here is a test whiteboard; open it in two tabs and watch the text areas sync. Any whiteboard is created if you go to a valid URL.

I just deployed a slightly newer version of whiteboard. You can now see an options page for each whiteboard, and it can render in several lightweight markup languages (good for drafting+previewing things). If you have other options to add there, let me know.

If you are interested in collaborative text editing, there are some other options. There is a Debian titanpad, an "open" instance of now-open-sourced Etherpad, and it has history support. Use titanpad.com and you don't have to log in. Here is a test pad. For a non-web application, Gobby exists. Use gobby-0.5 for smart undo history if everyone uses squeeze or above.

Is whiteboard still relevant in light of the options above that store history? I'm sure it depends, but for now, whiteboard works well for a low-overhead scratch space and for cases where you don't want to have a history trail. I also tend to use it as a simple pastebin or a personal notepad when I don't want to worry about having traces left behind. In short, it is so minimal you don't have to think about starting one up for something. I have found that collaborative writing really helps to get things done, thus, I hope that whiteboard (or a similar tool) can be useful to you.

A while ago, I gave a presentation on Debian, and made a latex-beamer color scheme for it. Over time I improved it some. Eventually, I grabbed the colors from the new debian website, since they are much nicer (lighter) than the old colors, and thus fit in a presentation better. Last year, I wanted to write this up so that others could use the scheme.

The theme can be found here, and there are examples in this gallery. This is distributed as a few color lines you need to copy and paste into your presentation (it is not much, and I thought that was better than an external dependency). You need to select your own layout theme from those included in beamer, for examples see the gallery. The theme page lists many credits for ideas, in particular zack for the idea of the logo on the background, and some other useful links. I would welcome others to improve this theme and make it more distributable.

As a reminder, there is another Debian wiki page for collecting presentations people have given, and it has some other useful links on it.

DebianNYC is having a Squeeze release/super bowl party this Sunday. It is in Park Slope, Brooklyn, and there will be both super bowl watchers and Debian installers/hackers who didn't know the super bowl was this weekend. For more information and to RSVP, see the wiki.

Someone in IRC had the bright idea to have a "upgrade to half-broken testing" party in a few weeks. This sounds a lot more fun - and educational. We have been having so many events lately that I am a bit worried about having things too close together, so I guess we'll take it as it comes and people want to organize things. In the near future, we could have a Novice Night in Brooklyn, a Novice Night in the Bronx, a workshop on configuration management of clusters, and now this testing upgrade party.

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.

As I just announced, the DebConf team will have an "organizational meeting". Every year, many teams need new people, since it is such a intense job for a few months. This year, I'm trying to get people who have not previously been involved in DebConf organization to help with these jobs.

The meeting will be held on #debconf-team on irc.debian.org at 20:00 UTC on 25th January 2011. The main point of the meeting is to go through and fill out the teams list. This doesn't mean talking about how jobs should be done this year, just figuring out who is interested, sign a team up, and let the team start thinking about the details. The team can discuss details among themselves, and with the larger DebConf team on the lists and in future meetings.

In past years, this meeting has helped to kickstart the teams and really began the DebConf cycle. This year, I am hoping to also make it a volunteer recruitment meeting. The DebConf team works hard, often to the point of burn-out, and thus would love new people. We need new people.

In the next few days, I'll try to make more posts in my DebConf series to help make people familiar with the way DebConf works. You could consider this meeting to be the ultimate goal of the DebConf article series: helping to recruit new people at this meeting.

Of course, if you want to join the DebConf team any other time, just drop by and offer a hand.

The DebConf talk selection process is in charge of selecting the talks at DebConf. Some of the reasons for having a talks team are to help ensure a high quality of talks, maintain a somewhat academic feeling for the conference, and to let attendees know what talks can be expected to be good.

Even though there is a big talk selection process in advance, DebConf has always allowed attendees to schedule new talks during the conference - at DebConf10, these were called "ad-hoc" talks. At DC10, attendees could sign up for a room+time slot on a wiki page, and each night they would be added to the main schedule. In past years, this distinction had been called "official" (pre-selected) vs "non-official" (new ideas during DebConf) talks, which was extremely confusing to people. "Ad-hoc" talks are a very important part of DebConf: not all development meetings are pre-planned.

Since we pretty much always surplus of talk rooms and times and we let people schedule talks during DebConf, people have asked: what is the purpose of talk selection? Are we going to let all talks be given? Are we going to reject talks just to say we selected them? When talks were "rejected" in the past, the speakers were told to just ask for a room during DebConf if they still wanted to give it. This question was raised on our mailing list. Even if there is a surplus of talk rooms, there are reasons for talk selection: it allows attendees to know what is most prepared, helps the video team to capture the best talks, lets talks be scheduled in the best room. You could also say it helps to organize talks into tracks and to collect abstracts for proceedings.

For DebConf10, we introduced a "conference track" concept, a set of related talks which would be scheduled in the same room in sequence. This allowed a more structured conference for attendees, and perhaps recruiting speakers to fill in requested talks for the tracks. Example tracks from DebConf10 are Science, Enterprise, and Community Outreach. I would have liked to see some tracks more Debian related, such as: project infrastructure, project communication, project social issues, ..., but what we had was a good start that can be improved on, if the new team desires to.

As for scheduling, there are two main parts: one phase before DebConf, assigning the selected talks to rooms and making the advance schedule. The other phase happens during DebConf and handles assigning rooms to people who want to do "ad-hoc" talks. The two phases aren't always done by the same person. The schedulers need to balance the expected audience and room capacity, need for video coverage, BOF vs auditorium style seating, not making talks overlap that are likely to appeal to the same audience, ... . The scheduling team works with the talk team, but doesn't necessarily have to be the same people.

I'm very happy that there was good discussion about the selection and scheduling process for DebConf10. In the end, a talk selection and scheduling wiki page was created. This page had two main purposes. First, it discussed and documented the selection and scheduling process, so that it was transparent to people that year and provides a reference for future teams. Secondly, other people have added their proposed talks workflows, that they can be considered in future years.

Talk selection has many competing demands - because of the completeness of the wiki page, I'll just refer you there. The rest of this post mainly frames the types of questions the talks team has to face. If you have thoughts on the DebConf talk selection process, feel free to add your ideas to the talk selection process wiki page, or better yet, help out with the team this year.

The next DebianNYC Novice Night is this Tuesday, January 18th from 18:30 -- ??. Last time was a great success, with a wide variety of people attending. This one should be even better.

If you want to come, all information is at that link. Come to get help installing Debian, using it, or even just to talk. Everyone who comes will help teach and learn things. If you are a current user, come out to give us a hand!

The first Debian-NYC Novice Night was a great success. We had about 25 people, about fifteen of which we had never seen before. We've been trying hard to reach out to new groups, and it seems to have worked even though we have a lot yet to do. One idea we'll probably use in the future is Novice Nights targeted to specific groups. A group of tech teachers in NYC has already contacted us and we will probably do a night in conjunction with them in the near future.

People came for all sorts of reasons. We had a lot of installations, some people came for help configuration or upgrading, and some people came just to talk and learn more. Those who came to help learned a lot, too. Most everyone wants to come back.

As with all Debian-NYC's activities, our plans and what we have learned are online so that anyone can adapt and reproduce what we do.

We have a social event on December 10th, and will have another workshop, and another Novice Night, early next year.

Debian-NYC is having it's first Novice Night this Wednesday, December 1st, hosted at Eyebeam. It will run from about 18:30 until 22:00, but people can come and go.

What are Novice Nights? They are a time for people to come and informally get help with Debian and derivatives. It's like an "installfest", but not just about installing. It's about getting help with what you already have installed. It's about helping to solve little problems. It's about meeting the community, and learning what resources are available, so that you can help yourself in the future.

We'll see how the first one goes, and improve from there. I'm looking forward to it, and seeing how this series evolves.

If you know anyone in the NYC area, point them to the Novice Night announcement and planning page and encourage them to come. Groups are welcome. There is also lots of other Debian-NYC events that happen, too.

This is a guest post by Michael Schultheiss, DebConf10 travel sponsorship team lead.

DebConf doesn't just provide sponsored food and accommodation to attendees, it can also provide travel reimbursement to 20-30 attendees each year, from all over the world.

The travel sponsorship team has historically been formed by a call to debian-devel-announce for developers to review sponsorship requests. This has resulted in one of the most transparent review teams of DebConf, which is by design since this is one of the hardest decisions to make. A team of about ten people will review applications. The travel sponsorship team is typically comprised of both people with past travel sponsorship team experience as well as new members to help make the process as fair as possible. The team will consider the listed workplans, the answer to the question "what do you do for Debian", their general knowledge of Debian contributors, and web searches of Debian lists, debian.org, and the web in general, looking for Debian and free software related activities.

Applicants are rated on a 1-5 scale of contributor level and amount requested. These are averaged and sorted, and this is used as the basis of travel sponsorship - but is subject to human review for special cases. The team will then decide the cutoffs for the different queues - for example, DebConf10 used queue A which had money released first, queue B which was released after more fundraising, and queue C which was told "no". After these queues are decided, most of the selection team doesn't need to be as active, but anyone from that team can work with the organizers to decide percentages of funding of the queues and when to commit money to them, based on our budget.

Attendees submit documentation for actual flight costs after the conference, and can be reimbursed for min(actual_costs, amount_requested).

There are various problems with this system, which are pretty well known but not so easy to fix:

• Attendees are supposed to put the amounts they can't afford to pay themselves, but we have no way of checking this (and probably wouldn't want to pry so much to be able to...)
• Historically, money has been budgeted for travel sponsorship last, thus travel sponsorship usually isn't confirmed until late in the process. This means that flight prices have constantly gone up, and some people may be unable to attend DebConf due to uncertainty over travel sponsorship.
• Attendees have a dilemma: They are supposed to enter only the amount they cannot fund themselves. But if there is a chance of fares being reimbursed at less the requested amount, then entering the amount absolutely required to attend results in a disadvantage.
• Invariably, people get confuse "amount I am unable to afford" as "amount I am able to afford"
• For some years, entering too high a requested sponsorship amount could result in a lower priority - instead of the selection team adjusting the amount downward. Thus, attendees have another dilemma about what to request.

These questions are hard to answer. I'm encouraged that there are some discussions on debconf-team which are working towards a better system. Most importantly, these people want to start early, which is almost guaranteed to result in a better outcome for everyone. If you are interested in working to improve the travel sponsorship process, I encourage you to get involved in the team and start early.