Repository navigation
Roadmap development #231
Description
Activity
Hey @rvagg I think my new issue "Process considerations, 3rd party inspiration" nodejs/roadmap#8 might be relevant to this discussion. At least in terms of how we help people organize and contribute their individual ideas/proposals/"roadmap items".
Edit: fixed the external issue reference.
@snostorm yes, interesting indeed, thanks for the links to the resources.
Something I'm personally interested in is scope and how to restrain it. One of the strong points of Node is that it's got a very small core. How can we open up the roadmap process to greater input from outside while not making it a feature-fest? How do we keep core small and not a slowly bloating beast like most other OSS projects?
I guess we need a rough list that outlines the feature scope of core (for now). That way it will be easier to defer suggestions falling outside of that remit to the "Great Idea - Create an NPM Module" page.
Even if it does fall on the boundaries; IMO it's always better for an idea to be developed as a module, so we should find a way to encourage it more obviously.
It's always possible to pull good ideas into core if it is decided later that it would be a good idea. We could also have 'core' blessed packages for particular use-cases on the wiki.
If we had a repo / thread (or forum) for features and ideas (could directed to node-forward?), where people can discuss and collaborate on those ideas away from the main io.js repo.
That way issues posted can be directed in the "Feature / Idea" section and good ideas from them can inevitably be pulled back.
It is also probably worth noting that it is wiser to discuss ideas with one of the core contributors / TC members, before creating pull requests for core (even if it does end ip being an issue in the the io.js repo).
Sorry if these suggestions seem obvious, I just thought i'd bounce some ideas 😄
We could also have 'core' blessed packages for particular use-cases on the wiki.
No one is going to actually maintain the "blessed by core" packages....
IMO it's always better for an idea to be developed as a module
Also not necessarily good, because it won't be optimized like modules here in core are, it won't be supported forever (Passport died, connect-mongo died and came back after a while)...sole developers run out of time, so core things should really be handled by core because new contributors will always join if it's an active community and language...Obviously things like Passport and connect-mongo should be in userland, but they are just an example.
@rvagg Say I want to nominate nodejs/roadmap#9, how do I go about that?
@ilanbiala by "blessed" i just meant like what npm does where it displays popular well tested modules. This information could even be sourced from npm via their API.
-btw the above were suggestions.
No one is going to actually maintain the "blessed by core" packages....
It's kind of a pessimistic view point don't you think?
That is like saying "No one will maintain any package". There is no guarantee that anyone will maintain any package they create anyway, the beauty of open source is that modules can be forked, etc. Growing the community and getting more people involved in the responsibilities helps further expansion and reincarnation.
IMO it's always better for an idea to be developed as a module
Also not necessarily good, because it won't be optimized like modules here in core are, it won't be supported forever...
A lot of things in core have been developed outside of core initially, i.e. readable-streams.
There is really no reason why something can't be optimised in for core outside of core, if the developer is serious about making something super optimised.
And as I also said you can test something in the wild and see if it is actually a good idea or not. Because once something is in core, it is very difficult to remove (e.g. domains).
io.js and node would be hugely losing focus by accepting or implementing every feature anybody ever asked for inevitably becoming some kind of standard library.
It's just not practical. So there has to be a point to draw a line.
By having a roadmap, everyone sees the direction, and can help to achieve a common goal. What that goal is and the milestones involved with that should also a collaborative process.
This is underway now in the roadmap repo. Closing here :)
Nice 👍
As part of the 2014-12-17 TC meeting, there's a desire to start pulling together a roadmap of sorts to guide the direction of the project.
The first step is to seek input from the community and this has been happening somewhat in the roadmap repo but it's become a little too bunched up in the "pain points" issue so it's hard to pull apart.
Somebody, at some stage, will start to pull together a roadmap proposal to take to the TC for discussion and possible acceptance, but first it needs ideas enumerated as issues in the roadmap issue.
How to contribute
Create an issue for each discrete idea or roadmap item in the roadmaps repo with the intent to start discussion and get greater feedback. Please be aware that proposing something doesn't guarantee acceptance or even any sort of discussion beyond yourself so be prepared for that.
Somebody needs to start pulling together roadmap-suitable items from the repo that are practical and don't conflict with the broader goals of the project into a roadmap document. What form this takes and the timeframes involved is intentionally vague and open to interpretation; and indeed the "goals" are not clearly defined beyond a stated desire to remain compatible with Node.js releases. Ideally the person would already be a committer or a TC member and be fully aware of the practicalities and goals and not likely to propose something too far from what the TC is likely to accept. This would also be a good case for collaboration amongst multiple people, e.g. propose a skeleton via PR and allow discussion to shape it. At some point I'll probably step in and start this process if nobody else does. I'll probably step in at some point and make a start on this if nobody else does.