nodejs / roadmap

This repository and working group has been retired.
135 stars 42 forks source link

Process considerations, 3rd party inspiration #8

Closed snostorm closed 2 years ago

snostorm commented 9 years ago

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.)

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 commented 9 years ago

I'd like to get your input on the WG process I've just proposed. https://github.com/iojs/io.js/pull/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 commented 2 years ago

Closing all issues in this archived repository.