Creating a ordered plan with all these issues/proposals?
q2dg opened this issue · comments
If issues of this repository are considered as proposals for NG, maybe doing a list showing rejected proposals (and the reason), deferred proposals, still discussing proposals and already approved proposals (with a flexible roadmap) would be interesting. I say this because here are very very good ideas but there's no plan to implement them. If here is not the place for that, I apologize.
This would be nice for the developer community to get a clear picture of where node is headed and allow them to prepare better for the future. Preferably I'd like this to be in the repo so we could discuss modifications over concrete PRs, maybe in the readme or add a roadmap file?
👍 for putting it in the repo. We should do RFC-style PRs, like rust.
So, there are several problems with turning this into a roadmap but I'm going to try and focus on the one I believe to be the most important.
Historically Node.js had a roadmap, although it wasn't at all documented and lived mostly in recorded presentations given by whoever was the BDFL at the time. At some point the requirements in the roadmap for 0.12 became a blocker to ever getting it released and contributions and contributors dwindled over the course of a year.
You can't say that a long/mid-term roadmap was the cause of this problem but the roadmap was a symptom of the development philosophy of the time. The belief being that Node.js was built by a "team" of mostly full time contributors and that bugs and features could be prioritized and built into a pipeline to achieve the goals of a roadmap. This approach slowly failed and what we replaced it with is almost the exact opposite:
- The development pipeline is optimized for accepting contributions (with review) and releasing them.
- There is no "roadmap" reason a particular change is accepted or rejected. Whatever is ready and appropriate for Node.js is merged and released.
- Stability is gained through review and through Long Term Support release lines that have a higher bar for changes that can effect stability.
- The community and the Evangelism WG promote the work being done and encourage new contributors to go after known problem areas.
The "io.js Roadmap" was more a series of obvious short term goals, the goal of the roadmap wasn't to define those goals so much as it was to evangelize them to new contributors and get them involved, which worked.
This repo has actually been hugely informative. In many cases ideas that begin as "core features" end up being obvious candidates for the ecosystem and identifying areas that we need to cut down and better abstract in core. If something under discussion here seems like it is ready to be part of core, send a Pull Request. There is no necessary step between deciding there is something you would like to see and it going into core that isn't within that pull request. In fact, core contributors have a pretty hard time determining if a feature fits without at least the beginning of an implementation -- it doesn't have to be finished, we have long running PRs that go through phases of implementation and review, that's expected.
Long term roadmaps and RFCs are a barrier to getting what they contain actually in the code base. For one thing, abstract ideas tend to get more negative attention than even the beginning of an implementation, so if you don't want your feature brought down by endless bikeshedding it's best to bring it to core as an implementation rather than an idea.
Long term roadmaps and RFCs also send the wrong message about who is responsible for code and how things work in Node.js. What makes it into Node.js is what you contributors write. There is no team waiting to implement the thing that you think should go it, that team is you. If a feature goes in that you wanted in Node.js it's because the person who wrote it wanted it, they wrote it up, and they went through the review and iterations necessary to make it happen. Hell, we've even had really big PRs started by one person and finished by another who got excited about it enough to finish it up.
To summarize, -1.
There are several problems with the "one big PR" approach:
- Anything that feels too controversial is unlikely to ever have any code written
- Some things are too far-future to make a PR, but still need discussion (whatwg streams, promisified core, etc)
- Some things are simply too big for a single PR and need some deliberate direction to make the smaller changes required to work toward it. (workers are a good example.)
As long as we continue with the issue-based structure of NG, these sort of issues will forever remain ambiguous as to the approval level of the concept. I think we need a mechanism of messaging: "Yes, we will are willing to move in this direction." That is what the RFC-style PR is good at.
I'm certainly not proposing all new changes need to be an RFC, just that if someone requests something we aren't ready for, we can direct them here and tell them to make a PR describing the thing and eventually the concept may be approved for smaller PRs to work toward.
All that having been said, I don't think either way is really ideal. Communication and collaboration is hard, it takes some extra work to be effective at it.
@mikeal I think I agree with you, but I still fear for node.js developers who can't (or think they can't) contribute to core. Their eyeballs (and contribution) to the topics discussed in NG is critical, but when it is in the form of issues alone it is hard for non-core developers to follow. The issues are not organized by priority, and for those with many comments is difficult for people in the future to divine a valuable summary.
So maybe here is a compromise for NG to be more readable and to not limit node development with a roadmap: instead of issues we use PRs tha at will never be merged. The PR author has the responsibility to keep the RFC-style proposal current. Modifications to the proposal can be submit with a pull request to the author's branch.
That way proposals are never approved/rejected as they are not an implementation spec but a brainstorm.
@calebmer so, at some point someone will need to write some code that makes it into core. There's really only two things the rest of us can do to help them.
- Provide feedback through discussion here and engagement in an eventual pull request.
- Evangelize the feature you want to see in order to find someone who might author it.
On the second point the Evangelism WG can help. If there's a discussion about a feature you think is ready for implementation pull in that WG to get the word out on twitter and elsewhere and hopefully we can pull in a contributor to work on it.