On Thu, May 19, 2011 at 10:35 AM, Simon Peyton-Jones
| > So if someone actually follows through with this as an official | > libraries submission (with a patch, deadline, etc.), the odds seem in | > favor of it. | | I'll try to see it through, although the process seems rather daunting. | It has annoyed me for too long.
I think there is general agreement that * The library submission process is too daunting, especially because you have to come up with a complete implementation of a proposal before you even know whether it's going to fly. * The process gets stuck because achieving universal consensus is too difficult * The maintainer "libraries@haskell.org" means that no individual feels responsible for making a decision on a proposal.
What we need is something to put in its place. Simon and I have been cooking up a proposal. Here it is:
http://www.haskell.org/haskellwiki/Library_submissions/NewDraft
It is aimed just at libraries whose maintainer is listed as libraries@haskell.org. (The thousands of other libraries with named maintainers can obviously do whatever their maintainer wants, although perhaps this new draft may be useful for them too.)
It's a draft. What do you think of it? Do you think it would be better than the status quo? Can you suggest any improvements?
Thanks for brining this issue up again. The draft is an improvement over status quo and making some progress on this issue is important. Some specific comments: Section 2: "widespread support" is a bit of a wishy-washy phrase. If 7 people want it, is that widespread support? What I've seen happen quite a number of times in the past is that some person who uses a particular function composition a lot suggests that it should be added to some core library. A few more people (say 7) chime in and say that that they also have used this particular composition a lot and that it therefore should be added. We might say that 7 people is a lot (you rarely see many mother than that in any email thread on haskell-cafe) and therefore the function should be added. However, there's a strong selection bias here and most likely the hundred (or whatever number) of other users of the API, who will now have a slightly more complicated API, can't be bothered to chime in on every request to add a function. This is one of the places where having a real maintainer is crucial. Because the maintainer is more likely to take the design of the whole library into account when making decisions, while the (well meaning) proposer is trying to address a particular pain point he/she is experiencing. If the maintainer is "required" to accept such changes, I'm afraid the overall quality (and simplicity) of our APIs will suffer in the long run. Section 3: It's not clear when the "deadline for discussion" should be used. Does it apply to any change or only public API changes? Does it apply even if it's the maintainer that making the change? Having to spent two weeks (even though most of the time is spent waiting) to make a single change is too high an overhead for me. I suspect I would just not bother making the change. To make things more concrete, what steps are required of the (future) maintainer of containers who wants to add a strict version of some function (many functions are missing a strict version at the moment)?
ALSO: does anyone (or two or three people) want to volunteer to act as maintainer for any of the "Volunteer needed" packages? Johan, I was thinking you might serve for 'containers', perhaps in harness with someone else since it is such a crucial package.
Depends entirely on what the process ends up being. If I end up maintaining it I'd ask Milan Straka to co-maintain it as he's probably the one person that understands the code the best at the moment. Johan