Making it easier to contribute non-functional changes

Simon Peyton-Jones simonpj at
Tue Oct 5 07:05:07 EDT 2010

| > commit access.  I agree that the libraries submission process is too
| > heavyweight in such cases.  But contributors without commit access need
| > to persuade someone who does to commit for them, e.g. by posting on
| > the libraries list.	

*  I think it's very important to make the barrier to entry as low as possible, to encourage contributions.  Having the procedure written down is a big help

*  I think it's a good idea to create a ticket, to save the proposal getting lost.  (The above link suggests creating the ticket in the GHC Trac for any library, which is fine with me so long as its clear.)  But it would be a good idea to have some Trac links on the above page that show all open library proposals, so its easy to see all the pending ones.

*  I'd suggest adding a note to the above page saying how to find out who the maintainer is.  Yes, I know, look at the .cabal file.  But that may not be obvious to the uninitiated, and even if you know about the field you may not know that it is regarded as the Actual Truth.

* The page says "This page documents the mechanism by which new code for libraries maintained by the community may be proposed".  Just which libraries are those?  I imagine that we mean "exactly those libraries whose maintainer is "libraries at"."  But we should say so!

* And then what is the procedure for other libraries?  Re-reading the page, it's not really clear whether its scope is "all libraries" or just "libraries at libraries".

*  I think it's unsatisfactory having any libraries whose maintainer is solely "libraries at". If I was contributing I'd find that much less motivating (like emails that say "contact at"; probably a no-op).  I'd much prefer a list of names for each library.  Otherwise it all devolves to Ian or Simon somehow.  Something like "libraries at [Simon Marlow, Johan Tibell]".  The list isn't immutable, of course, but it'd make it clear which libraries lack love, and who holds the token for progressing a proposal against that library. And who has commit access.  I suppose this is the biggest change I'm suggesting.

*  I'd like the above page to write down the procedure for transferring maintainership, to handle maintainers who have gone AWOL.  Something like "if no reply, send an email to libraries@ and haskell@, saying that you propose to take over maintainership.  If no reply in 2 weeks, you can take over."  Or whatever.  Again this suggestion amounts to widening the scope of the libraries-submission page.

*  This thread started with discussion about "obvious" changes. I suggest it should be up to the maintainer. The submitter should say whether or not an API change is involved (another thing to add to the submissions page); and the maintainer can decide whether to apply immediately or wait for comment.


More information about the Libraries mailing list