No subject

mocracy.html#electorate
"The voting system itself should be used to choose new committers, both ful=
l and partial. But here is one of the rare instances where secrecy is appro=
priate. You can't have votes about potential committers posted to a public =
mailing list, because the candidate's feelings (and reputation) could be hu=
rt. Instead, the usual way is that an existing committer posts to a private=
 mailing list consisting only of the other committers, proposing that someo=
ne be granted commit access. The other committers speak their minds freely,=
 knowing the discussion is private. Often there will be no disagreement, an=
d therefore no vote necessary. After waiting a few days to make sure every =
committer has had a chance to respond, the proposer mails the candidate and=
 offers him commit access. If there is disagreement, discussion ensues as f=
or any other question, possibly resulting in a vote. For this process to be=
 open and frank, the mere fact that the discussion is taking place at all s=
hould be secret. If the person under consideration knew it was going on, an=
d then were never offered commit access, he could conclude that he had lost=
 the vote, and would likely feel hurt. Of course, if someone explicitly ask=
s for commit access, then there is no choice but to consider the proposal a=
nd explicitly accept or reject him. If the latter, then it should be done a=
s politely as possible, with a clear explanation: "We liked your patches, b=
ut haven't seen enough of them yet," or "We appreciate all your patches, bu=
t they required considerable adjustments before they could be applied, so w=
e don't feel comfortable giving you commit access yet. We hope that this wi=
ll change over time, though." Remember, what you're saying could come as a =
blow, depending on the person's level of confidence. Try to see it from the=
ir point of view as you write the mail."
---

I personally suggest reading that whole chapter (#4) for reasons why a lot =
of projects have a committers mailing list (and yes it is a standard practi=
ce.)

Adam

> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
> bounces at lists.berlios.de] On Behalf Of Ryan McDougall
> Sent: Monday, 19 October 2009 9:33 PM
> To: opensim-dev at lists.berlios.de
> Subject: [Opensim-dev] The notion of "core"
>=20
> On Tue, Oct 20, 2009 at 2:49 AM, Frisby, Adam <adam at deepthink.com.au>
> wrote:
> > Ter pretty much summed it up - both it and the irc channel are fairly
> low-volume, and the 'topic' is restricted to only 'personal' or 'meta'
> matters; such as discussion of approval of commit rights.
> >
> > It's pretty standard practice across open source projects with more
> than 5 committers for the committers to have a mailing list for these
> purposes, since realtime chats aren't practical across timezones.
> >
> > Adam
> >
>=20
> I am not sure I'd agree just how standard a process it is.
>=20
> The one's I've been involved with or otherwise have some detailed
> knowledge of, have never had them; including such big names as GNOME,
> Fedora, and Linux. For example the GNOME foundation list is not only
> world-readable, but anyone can join:
> http://mail.gnome.org/mailman/listinfo/foundation-list . Actual
> foundation members are voted by the community at large.
>=20
> Basically the way they are able to operate is, they don't distribute
> commit access according to monolithic vote of knighted members; they
> have a system of maintainership, and each maintainer gives access
> rights to his module/repo as she sees fit, in a web of trust.
>=20
> One of the complaints one sometimes hears is how monolithic the
> project is (even if the code-base is modular). Maybe the move to git,
> and the maturation of the code allows more distribution and
> specialization of responsibility?
>=20
> My concerns with core mailing list are:
>=20
> 1. It's "secret", ie. not world readable. I can understand limiting
> membership to voting partners to avoid bikeshedding, but I can't
> understand secrecy of any kind in an open source project.
>=20
> 2. Decisions made there (aside from commit rights) affect other
> people, and they not only have no voice to represent themselves, they
> don't even get to know what is being said about them. That doesn't
> seem fair somehow.
>=20
> The knowledge that someone can read what you write makes you think
> harder about what you say. Maybe a private list makes the problem of
> disagreement within core worse rather than better? I haven't the
> faintest idea who this snowcrash guy is, but when I was a topic of
> discussion on -core, I remember not liking it at all.
>=20
> As for the issue of timezones, I understand that completely! Which is
> why I wish you guys used ML more frequently! :)
>=20
> My intention is not to bike-shed, but to be productive. Either opensim
> core is open to this point of view or it's not, and we move on from
> there.
>=20
> Cheers, and much love!
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev