Differences between revisions 1 and 2
Revision 1 as of 2010-06-21 09:45:54
Size: 225
Comment:
Revision 2 as of 2010-07-26 09:54:52
Size: 3086
Comment: just check-in the original blog post, to start working on it
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Forthcoming. '''''How to have a Debian meeting without turning into a secret cabal'''''
Line 5: Line 5:
In the meantime, check [[http://upsilon.cc/~zack/blog/posts/2010/06/debian_meeting_guidelines_RFC/|some preliminary thoughts]] on the topic. '''WORK IN PROGRESS'''

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.

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.

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.)

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.

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.

== References ==

 * [[http://upsilon.cc/~zack/blog/posts/2010/06/debian_meeting_guidelines_RFC/|preliminary thoughts / RFC]] on the matter, as a blog post

Debian Meeting Sponsoring Guidelines

How to have a Debian meeting without turning into a secret cabal

WORK IN PROGRESS

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.

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.

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.)

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.

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.

References


?CategoryDPL