Process considerations, 3rd party inspiration #8
Description
There are some interesting examples in the wild of how some well established projects move forward around larger project/API changes. I thought it might be useful to collect some links and open the discussion around process. (Perhaps this could have instead been an iojs/io.js issue.)
- Bitcoin Improvement Proposals (BIPs) exist in their own repo with the README being a simple introduction followed by an index of the proposals. BIPs are numbered and are often referred to the community in this way. ("When will X wallet support BIP 10".) Various community efforts also categorize ongoing/accepted proposals via the wiki, etc.
- Rust RFCs and Ember RFCs also are repos with their READMEs being a more step-by-step overview of the RFC process. Rust is the better example here as the Ember effort is only a few months old.
What I like in both cases is that it separates the concept of release roadmaps from feature evolution, API design/discussion, research, etc. Once an RFC/BIP is considered well flushed out (and conditionally or fully approved) it can begin to be developed with some community consensus already behind it.
Experimental features (when hidden behind flags or which just generate warnings) could still be documented as part of their bundled releases, linking back to the open proposal/RFC within the documentation itself. That could help late-stage reviewers know more about the history of the feature and what to look for.
Eventually late-stage BIPs (err, IIPs?) / RFCs could be targeted towards specific release versions as part of a broader "roadmap".
For now, I'll leave it here. These two examples came to mind as part of opening the discussion, but I'll try to dig up some more. What has everyone else seen work well in the wild?