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

[Simon Peyton-Jones]

As a spectator to this process, here are a few thoughts

·        Bryan deserves a huge vote of thanks for his work on the text library.  Thank you Bryan!

·        The Haskell Platform group also deserve our thanks.  Having a quality-controlled, consistent, easy-to-install bunch of libraries and tools is hugely important to the Haskell community.  It’s also a bit of a thankless task, and we MUST NOT take their work for granted.  Thank you HP team!

·        The fact that Bryan (and he is an easy-going man) feels bruised by the process is a clear sign that we need to fix something.  We want library authors to feel affirmed, not hurt, by having their package in the HP

·        Happily, the something is quite fixable.  It’s not as if there was a fundamental underlying divergence of goals.  We all want the same thing – well-engineered libraries in the platform – and I think everyone involved in the discussion has been seeking that goal, even if it has not been experienced in that way.

·        As Don has said more than once, we don’t need perfection; indeed the best is the enemy of the good.  We just need a process that reflects that belief.

·        We need to recognise and honour the fact that the author’s investment in the package (in terms of time and commitment) is two to four orders of magnitude larger than that of the reviewers.

·        Nevertheless, we also need a way in which people can make modest, constructive suggestions, such as naming issues, without that seeming trivial or critical, and without it derailing the whole exercise.

So here are some suggestions.  They are just my personal thoughts.  I suggest dividing the process in two:

·        Step 1:is the package going in?  And under what conditions?

o   The idea here is that the HP committee decides whether they want the package. But the decision should be of the form “Yes, if you change the exceptions to use the new exception API, no otherwise”.

o   That is, identify what concerns are sufficiently serious to keep the package out, and otherwise accept the package as-is, subject to Step 2.

o   This decision needs to be taken by a date that leaves enough time for Step 2 to take place.

o   In controversial cases this discussion might need a moderator, but I’m guessing that consensus would be the common case.

·        Step 2: refinement.

o   In Step 2 the HP committee, and anyone else, makes respectful suggestion to the author about things s/he might consider improving.

o   The author is in control of the debate.  S/he may choose to adopt the suggestions or not.  It’s a matter of honour that the author takes suggestions seriously, and responds thoughtfully even if s/he decides not to adopt them.

o   Moreover, the outcome of the discussion doesn’t affect the prior decision to accept.  (Unless, I suppose, some major new issue comes to light.)

o   This provides a way for small constructive suggestions to be made, but still to have a way for the discussion to be brought to a conclusion, by the author.  (Yes, that might lead to a package that not everyone is perfectly content with, because not all suggestions will be adopted.  But it’s a million times better than no package.  The best is the enemy of the good!)
I think this kind of process would have made the text package much easier.  As I read the discussion, Step 1 was  slam-dunk (“yes, please”), and Bryan would have been happy to entertain suggestions. The bruising thing was, I believe, the element of conditionality -- unless we can agree on the name of this function, the package won’t be accepted – something no one really intended.
Bryan: would this kind of two-step process have been easier for you?
Simon

From: libraries-bounces at haskell.org [mailto:libraries-bounces at haskell.org] On Behalf Of Bryan O'Sullivan
Sent: 08 November 2010 08:07
To: libraries at haskell.org
Subject: Contribution vs quality, and a few notes on the Platform process

Folks,

I'm going to change the naming of functions in the text API to match base within the next few days, but for me this has been a close-run decision: I've come very nearly as close to simply asking for the text proposal to be withdrawn. This has been the first time in my many years of participation in the Haskell community of finding the experience thoroughly and persistently unpleasant.

My reason for choosing to change the names is in part a nod of respect to Ian and Ross, whose opinions and contributions I value. I continue to disagree with their conclusion about naming, but I understand their reasoning behind it. I also want to make the volunteering jobs of Duncan, Don, and the other HP folks less onerous, as the success of their work is very important to me, and we owe them a debt of gratitude for their work. I feel a strong sense of obligation to all of these people.

Now why, with all that noble sentiment expressed, would I have so strongly considered walking away over such an apparently minor point as the names of a few functions? Put it down to a matter of pride and proportion.

Tom's original text library was about 1,700 lines in length. When Duncan handed it over to me, it was 2,200. It's now 12,300 lines long. I also spent three months writing a random number generator, a statistics library, and a benchmarking library in order to ensure the code was fast. And then there are the ICU bindings, for all the extra Unicode work that's simply too much to reimplement in native Haskell. Together, those libraries amount to an additional 11,300 lines of code.

So. 23,600 lines of code, six BSD-licensed libraries, and months of work later, to be told repeatedly that my taste in function naming for a small portion of the API, no matter how clearly articulated, wasn't good enough has, well, not sat well with me. Sad to say, it is only by a hair's breadth that I feel like enough of a bigger man to push ahead. It has at times been difficult not to feel like I've laboured mightily over a large gift, only to have it shoved back in my face because the ribbons simply don't capture quite the right curl.

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.
  *   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 am sad to say that I feel somewhat ill done by and upset as a result of this process, and it's not an experience I would rush to repeat. I wish you the best in improving it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20101108/4f639981/attachment-0001.html