zack's home page/ blog/ posts/ 2010/ 06/ debian meeting guidelines RFC

How to have a (Debian) summit without turning into a secret cabal

It seems rather uncontroversial that sponsoring various kinds of Debian meetings (conferences, sprints, BSPs, etc.) is a good way to spend, actually invest, Debian money.

Historically, that has not always saved the Debian community from muttering about "cabal-ish" meetings in very few specific occasions. (No, there is no cabal, in case you wonder.) I've always believed in the good faith of people and I don't think that we have ever had "secret meetings" on purpose. Nevertheless the question of how to have meetings in a community-compatible way is a sound one. Answering properly to such a question is something that it's harder than what it might seem at first sight (at least for me).

In particular, organizers have to carefully balance the high efficiency that meetings offer (e.g.: communication bandwidth is higher than when working remotely, people have less distractions, more enthusiasm, more fun!, etc.) with the risk of cutting out the rest of the community which cannot attend the meeting, for whatever reason. Note also that since Debian is not a company, we cannot just require that everybody who is interested attend the meeting.

As DPL, I'm starting to get quite some requests for meeting sponsorship, and that's just wonderful: it means that we have thrilling groups of people that are eager to get together and hack to improve Debian! Still, in doing so, we should all try to minimize the above risk; that's why I've started to apply the following Debian meeting guidelines, as a kind of prerequisite for sponsoring.

  1. Before the meeting: the meeting should be announced to the most relevant public mailing list(s); ideally, the tentative agenda of the meeting should be included in the announcement.
    That will enable people interested in the meeting topics to provide their inputs and more generally to know what is going on.

  2. During the meeting (preparation): expenses should be minimized, as a form of respect for all people that donate to Debian. Since we value their contributions, we do our best not to waste them. (TTBOMK, we've always done that, but making it explicit won't hurt.)

  3. After the meeting: meeting minutes should be sent to the most relevant public mailing list(s), usually to d-d-a for meetings that cover topics of general development interest.
    As an obvious consequence, minutes should be taken during the meeting; it is a bit of extra burden, but the risk of leaving the rest of the community in the dark is just not acceptable a community as wide and diverse as ours.

  4. In general, think about communication, e.g.: (micro)blog about the meeting, contact press/-publicity to prepare a news item about it, enable others to attend virtually on IRC or other media, etc.

For now, the above is just a brain dump.
Now, what do you think? Are the above reasonable demands? What else should we ask for?
Feel free to leave a comment or mail me about that.

Leave a comment
Announce to d-project
I think these are reasonable guidelines (and should probably be added to some organisational page at some point); I think it would be nice if in addition to the "most relevant mailing list" meetings where Debian money is spent to help people attend would also be announced as a matter of principle on d-project.
Comment by cmot — Mon Jun 21 07:18:34 2010
comment 2
Again fairly obvious, but nevertheless needs stating: meeting minutes should include a list of attendees.
Comment by Anonymous — Mon Jun 21 09:21:55 2010
meeting guidelines comments

Hi Zack

Just two comments about the meeting guidelines RFC in your blog:

  • minimizing expenses: I would rather phrase this as "optimizing" expenses. As it is now it sounds a bit like minimizing expenses at all costs. I think we should allow expenses to be made for example to improve the work atmosphere of a BSP by renting a better suited location which is a bit more expensive. Or by renting cheap accomodation where people can sleep in real beds and don't have to sleep on the floor.

  • My other point is a bit delicate. You might make it a bit more clear, that these are guidelines for the general case and not a fixed rules for every case. I think there are valid reasons to do closed meetings which not everyone can attend. For example to discuss interpersonal problems in core teams.

Best, Gaudenz

[ posted by Zack, with Gaudenz permission ]

Comment by Gaudenz Steinlin — Mon Jun 21 11:48:00 2010
Re: meeting guidelines comments
  • minimizing expenses: I would rather phrase this as "optimizing" expenses. As it is now it sounds a bit like minimizing expenses at all

Agreed, I'll use a better wording in the forthcoming proper draft.

  • My other point is a bit delicate. You might make it a bit more clear, that these are guidelines for the general case and not a fixed rules for every case. I think there are valid reasons to do closed meetings which not everyone can attend. For example to discuss interpersonal problems in core teams.

With my wording I didn't mean to imply that everyone should always be able to attend every meeting. For once, there might be space constraints on specific venues; additionally, we clearly want to keep the ability to decide who gets sponsored and who don't (that is tricky and not fun to do, but it's something we already do as we unfortunately have to: either via the DPL or via specific teams such as the DebConf sponsoring team).

Then, of course, there are the delicate cases you mention above. Also in those cases, and assuming Debian money are used, I believe we should have some trace of the meeting at least in the form of a wrap up a posteriori, posted for instance on -private.

All in all, I agree with your suggestion of stressing that the guidelines are meant to be general and not bureaucratic ropes to which hang ourselves. (In fact, I thought that the "guidelines" name already implied that, oh well.)

Thanks for your feedback, Cheers.

Comment by zack — Mon Jun 21 13:23:36 2010
Re: meeting guideline comments
Even in those sensitive cases, what's wrong with offering a summary to the public? In the example mentioned, you could just summarize it as "resolving interpersonal differences in the core team" or the like without going into gossip territory.
Comment by Anonymous — Sun Jun 27 20:00:03 2010