Haskell ecosystem improvements meta-propsal

[Mike Meyer]

There's been a lot of complaints about the way things have worked in the
past, with things going to fast, or to slow, or the right people not being
heard, or notices not going to the right places, etc.

As far as I can tell, the current process is that someone make a proposal
on some mailing list, that gets debated by those who find out about it,
maybe a wiki page gets set up and announced to those who already know about
the proposal, and then it either happens or not.

There's actually quite a bit of experience with dealing with such. I've
dealt with the IETF RFC process and the Python PEP process, and both of
them worked better than that. So I think we can do better.

I'd like to suggest we adapt something a bit more formal that any process
that changes a developer-visible API should have to go through. Note that
bug fixes, most security fixes, and other things that don't change the API
wouldn't be subject to this requirement. However, any change in an API,
even one that's 100% backward compatible, not possibly breaking any code,
would be. Initial thoughts on scope are anything in the Haskell Platform,
as that seems to be a minimal definition of "Haskell ecosystem". Further,
anything on hackage should be able to avail itself of the process.

My concrete, though very broad proposal, with lots of details to be filled
in yet, is that we need:

1) A wiki page that lists all proposals being considered, along with their
current status and other relevant information.

2) A set of requirements a proposal must meet in order to be listed on that
page.

3) An announcements list that only has announcements of things being added
to the list. Anybody who has time to vote on a proposal should have time to
be on this list.

4) An editorial group responsible for maintaining the list and providing
guidance on meeting the requirements to get on it.

The first three are easy. The fourth one is the killer. Somebody to do the
work is the stumbling block for most proposals. This doesn't require deep
technical knowledge of Haskell or the current ecosystem, but the ability to
implement a process and judge things based on form and not content, Since
it's my proposal, I'll volunteer as the first editor. Hopefully, others
with better reputation will alsob e available.

If adopted, the first two things on the list need to be a description of
the process, followed shortly by a description of the requirements to be
met.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151007/4a22263b/attachment.html>