GOP-PROP 6: private mailing lists

[Graham Percival]

We've had almost a day to recover from the C++ formatting issue,
so let's dive into the next massively contentious issue.

http://lilypond.org/~graham/gop/gop_6.html


** Proposal summary

What should we do with potentially sensitive or private matters in
lilypond? I see two possible solutions:

   1. Pick one person to manage private discussions. Whenever
there is a potentially sensitive topic, send an email to that
person. He will then decide who should discuss the issue on an
ad-hoc basis, and forward or CC them on future emails.
   2. Have a private mailing list with a known list of people who
will discuss such matters. That list may still have a single
“secretary” who receives initial emails, but that person will then
have a set list of people to discuss such topics with. 

In general, I favor the second option – but at the moment, I’m so
fed up with the topic that I have no objection to the first option
if that’s preferred.


** Status quo

At the moment, our custom seems to be the first option. Whenever
something comes up, somebody sends me a private email, and I pick
an ad-hoc collection of people to discuss it with. Always Han-Wen
and Jan, but often Carl, Trevor, and others.

Other than the obvious “giving git push ability”, recent questions
included a university project who wanted to have a focus group to
discuss development. I thought we could just discuss it on -devel,
but the university group wanted to keep it private. I didn’t see
any harm in that, so we arranged something privately with an
ad-hoc collection of lilypond developers.


** Rationale

As LilyPond becomes more widely used+known, we can expect more
requests for private communication. In many cases these requests
are a bit silly but harmless – sometimes external groups are shy
to have public archived discussions, even if there’s nothing of
real importance being discussed. We could tell those people “get
lost, we’ll only talk to you if it’s public”, but I think we lose
nothing by allowing a trusted group of people to have a private
discussion with those people.

The key is “a trusted group of people”. At the moment, it appears
that I am a single point of failure for this. I’m not convinced
that this is healthy for the project, so I’d like to have a wider
group of people for this task.

There is some unhappy history about this idea in our development
community:
        
http://lists.gnu.org/archive/html/lilypond-devel/2010-09/msg00178.html
http://news.lilynet.net/spip.php?article121
http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00076.html


** Other projects

The idea of private mailing lists is hardly uncommon in
open-source software. For example,

http://lwn.net/Articles/394660/   about debian-private
http://subversion.apache.org/mailing-lists.html  private@
http://www.freebsd.org/administration.html#t-core
http://foundation.gnome.org/legal/   board members pledge
to keep certain matters confidential

every security team of every linux distribution and OS

In fact, Karl Fogel’s “Producing Open Source Software” explicitly
suggests a private mailing list for some circumstances:
        
  [on granting commit/push access to a contributor]

  But here is one of the rare instances where secrecy is
  appropriate. You can't have votes about potential committers
  posted to a public mailing list, because the candidate's feelings
  (and reputation) could be hurt.

  http://producingoss.com/en/consensus-democracy.html#electorate


** Private list membership?

If we want to pursue a private mailing list, rather than “whoever
Graham thinks/remembers to cc”, then the obvious question is “who
should be on it?”.

My initial thought is to keep it small – say, 5 people. Other than
me, Han-Wen, and Jan, I have no firm ideas about who else.

The list of members should be public.


** Board of governers, voting, etc?

Many projects have an official board of directors, or a list of
“core developers”, with set term limits and elections and stuff.

I don’t think that we’re that big. I think we’re still small
enough, and there’s enough trust and consensus decisions, that we
can avoid that. I would rather that we kept on going with
trust+consensus for at least the next 2-3 years, and spent more
time+energy on bug fixes and new features instead of
administrative stuff.


** Implementation notes

None yet. 


Cheers,
- Graham