<div dir="ltr">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.<div><br></div><div>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.<br><div><br></div><div>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.</div><div><br></div><div>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.</div></div><div><br></div><div>My concrete, though very broad proposal, with lots of details to be filled in yet, is that we need:</div><div><br></div><div>1) A wiki page that lists all proposals being considered, along with their current status and other relevant information.</div><div><br></div><div>2) A set of requirements a proposal must meet in order to be listed on that page.</div><div><br></div><div>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.</div><div><br></div><div>4) An editorial group responsible for maintaining the list and providing guidance on meeting the requirements to get on it.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div>