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

Sittampalam, Ganesh ganesh.sittampalam at
Tue Nov 9 08:21:31 EST 2010

Sterling Clover wrote:
> On Nov 9, 2010, at 7:02 AM, Gregory Collins wrote:
>> Hi all,
>> Personally I would be fine with that, providing there was a plan
>> towards a community effort to improve the libraries we've *already
>> approved*. To subject maintainers of candidate libraries to the
>> "scanning tunneling electron microscope" while remaining oblivious to
>> the huge usability/documentation problems in our grandfathered
>> libraries --- I'm looking at you, regex-*, HTTP, old-*, QuickCheck,
>> OpenGL, html, xhtml, pretty, etc --- isn't fair in the slightest and
>> is going to discourage people from submitting libraries in the first
>> place. 
> ...
>> Maybe we should assemble a posse of volunteers, divide up the
>> libraries, and spend a few hours each adding this kind of documentary
>> material to try to make a real impact on the average quality level in
>> the platform. The cynic in me, however, suspects that the willingness
>> to do this kind of grunt work is greatly overshadowed by the appetite
>> to engage in endless rounds of mailing list bickering.
> That sounds like a great idea! A weeklong(ish?) "documentation strike
> force". 
> Step one, a good strong motivation, like here, but a bit more fleshed
> out, and sent to -cafe, via reddit as well, etc. 
> Step two, clearance from maintainers of various packages for their
> willingness to accept and review significant documentation patches.
> (I'm sure it will be forthcoming, but it should help momentum to say
> that authors x, y, and z all give approval and support.)   

I'm the current maintainer of HTTP essentially by accident (previous
maintainer dropped it, urgent changes needed for GHC compatibility), and
I would like to get rid of it if anyone with more time and interest
comes along. As such, I can't commit to properly reviewing documentation
patches, but I would be happy to accept them without review in that

However it seems to me that with all these grandfathered packages, the
API is potentially rather more of an issue than the documentation, and
updating that could be rather more disruptive and painful.


Please access the attached hyperlink for an important electronic communications disclaimer: 

More information about the Libraries mailing list