Contribution vs quality, and a few notes on the Platform process

Duncan Coutts duncan.coutts at googlemail.com
Mon Nov 8 10:04:29 EST 2010


On the process points...

On 8 November 2010 08:06, Bryan O'Sullivan <bos at serpentine.com> wrote:

> Now that I've gotten that off my chest, I have some specific proposals to
> fix aspects of the Platform inclusion process that I found most painful. I
> would be most grateful to see these receive consideration.

> To begin with, active participation, moderation, and collation of data is
> important. The text proposal spawned some huge threads, but I felt that the
> HP team was largely absent through the many discussions, and after a while I
> had to simply give up tracking stuff by eyeball. Maybe I missed some things
> as a result; I don't know.
>
> There must be a place for people to record issues, so we know which ones
> matter enough to track. Trac would work perfectly well for this. The order
> of operations should probably be for objectors to record their thoughts
> there, then for a moderator or the proposer to sort them out after a
> discussion period. (Obviously, in the case of text, naming looked like the
> squeaky wheel, but Ian raised a number of issues with bits of the internals,
> and I'm not sure I caught them all amid the torrent of email. And those were
> the ones that were actually unequivocally valuable, too!)

> A moderator should keep the discussion from wandering too far off track.
> Things that I'd like to see as off limits would include discussion of
> whether some third party library needs tweaking, or an attempt to revive a
> contentious topic of discussion that has been resolved and should stay that
> way.

On the first two, I'm going to propose to the other steering committee
members that for future proposals, a steering committee member is
assigned for each proposal when it is first made. The purpose is to
make clear which individual member is responsible for guiding each
proposal and to stop us all from hiding behind "oh I thought you were
going to do it" and "ah sorry I've been a bit busy". We would assign
in a round-robin fashion (with the ability to skip over if someone is
temporarily very busy or if the person is actually one of the
proposers).

> An Apache-style vote system for resolving points of disagreement, so that we
> can move past them reasonably swiftly instead of going in endless
> morale-sapping circles. This is particularly important to me. I'd really
> have liked to be able to say "we discussed this, it's over" about naming,
> but instead I feel that objectors held, in effect, a veto. The current
> consensus system seems to require complete agreement from all parties, which
> seems perverse.

I'll raise this with the steering committee. Voting is something we
tried to avoid in the process when we first designed it, but the
intention was always to see how things went and review. Voting may be
a useful thing to bring in at some points if there's a clear case that
some decision is better than no decision. If we decide to add this to
the process my view would be that it should be only used occasionally
for specific issues, perhaps issues of general principle rather than
specific issues in a proposal (obviously Text brought up a couple of
those).

Duncan


More information about the Libraries mailing list