Process considerations, 3rd party inspiration

[snostorm]

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?

[mikeal]

I'd like to get your input on the WG process I've just proposed. nodejs/node#599

Right now that most obvious work that would fall in to this kind of RFC process would be Streams which we are doing as a Working Group. The thing I prefer about a WG over these RFC processes is that it offers autonomy to the people taking on a particular area rather than continuing to push all the changes and process in to the same funnel (in our case the TC).

[Trott]

Closing all issues in this archived repository.