Differences between revisions 2 and 3
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
Revision 3 as of 2010-07-26 10:17:53
Size: 2133
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
'''WORK IN PROGRESS'''
Line 5: Line 7:
'''WORK IN PROGRESS''' Sponsoring various kinds of Debian meetings (conferences, sprints, BSPs, etc.)
is a good way to spend, actually invest, Debian money.
Line 7: Line 10:
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.
Nonetheless, Debian is a community of volunteers and we cannot rely on the fact
that people will be able to attend meetings as they were "work" meetings. That
is why organizers have to carefully balance the high efficiency that meetings
offer (higher communication bandwidth than remote work, more focused people,
more enthusiasm, more fun, etc.) with ''the risk of cutting out the rest of the
community'' which cannot attend the meeting, for whatever reason.
Line 10: Line 17:
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).
'''Debian is very happy to sponsor developer meetings''', but requests that the
following '''sponsoring guidelines''' are respected, in order to minimize the
risks outlined above.
Line 17: Line 21:
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.
Line 23: Line 22:
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.
== The Guidelines ===
Line 28: Line 24:
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.
 * '''before the meeting'''
   * announce the meeting to the most relevant public list / forum
   * ideally, include a tentative agenda of the meeting in the announcement
     <<BR>>
     That will enable people interested in the meeting topics to provide their
     inputs and more generally to know what is going on
Line 33: Line 31:
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.)
 * '''during the meeting''' / meeting preparation
   * minimize expenses <<BR>>
     it is a way to show respect for all people that generously donate to Debian
   * keep track of what's happening, in preparation of the overall meeting report
   * consider giving periodic updates on how the meeting is going <<BR>>
     e.g. blog about what's happening day-by-day
   * think about remote participation <<BR>>
     e.g. stay on a specific IRC channel and announce it
Line 37: Line 40:
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.
 * '''after the meeting'''
   * post meeting minutes / report to the most relevant public list / forum
     <<BR>> e.g. `d-d-a` for meetings of general development interest
Line 43: Line 44:
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.

WORK IN PROGRESS

Debian Meeting Sponsoring Guidelines

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

Sponsoring various kinds of Debian meetings (conferences, sprints, BSPs, etc.) is a good way to spend, actually invest, Debian money.

Nonetheless, Debian is a community of volunteers and we cannot rely on the fact that people will be able to attend meetings as they were "work" meetings. That is why organizers have to carefully balance the high efficiency that meetings offer (higher communication bandwidth than remote work, more focused people, more enthusiasm, more fun, etc.) with the risk of cutting out the rest of the community which cannot attend the meeting, for whatever reason.

Debian is very happy to sponsor developer meetings, but requests that the following sponsoring guidelines are respected, in order to minimize the risks outlined above.

== The Guidelines ===

  • before the meeting

    • announce the meeting to the most relevant public list / forum
    • ideally, include a tentative agenda of the meeting 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 / meeting preparation

    • minimize expenses

      • it is a way to show respect for all people that generously donate to Debian
    • keep track of what's happening, in preparation of the overall meeting report
    • consider giving periodic updates on how the meeting is going

      • e.g. blog about what's happening day-by-day
    • think about remote participation

      • e.g. stay on a specific IRC channel and announce it
  • after the meeting

    • post meeting minutes / report to the most relevant public list / forum

      • e.g. d-d-a for meetings of general development interest

References


?CategoryDPL