What do you want to see from a roadmap?

[mikeal]

As we continue to gather feedback in the hopes of producing a public roadmap I'd like to get input from the community about what they want to get out of the roadmap.

• Is it enough just to have a prioritized list of features?
• Do we need some target dates for roadmap items to be released?

What do people want to get out of the roadmap?

[YurySolovyov]

I think list should also be categorized, to show what should be done in terms of performance, features, APIs etc.

[YurySolovyov]

I think list should also be categorized, to show what should be done in terms of performance, features, APIs etc.

[eafelix]

+1 @YuriSolovyov

[eafelix]

+1 @YuriSolovyov

[zdychacek]

+1 @YuriSolovyov

[zdychacek]

+1 @YuriSolovyov

[jesstelford]

I'd love to see a well prioritised and groomed backlog of tasks. One that starts highly specific at the top ("fix bug #xyz", "refactor Y ready for feature X", etc), but gets less specific toward the bottom ("ES6", "Reintegrate with node.js", etc).

Somewhere I, as a consumer of the product, can look to see where in the priority list my desired feature sits.

As lower tasks move up the priority line, make them more specific (split them into multiple smaller tasks for instance)

Note that I have purposefully not mentioned anything about dates or times - they slip, and often become meaningless.

This also allows folks to contribute with task prioritization, and even working on something they know the core team has put lower in the priority list.

At any rate, you folks are nailing it! Keep up the excellent work :D

[jesstelford]

I'd love to see a well prioritised and groomed backlog of tasks. One that starts highly specific at the top ("fix bug #xyz", "refactor Y ready for feature X", etc), but gets less specific toward the bottom ("ES6", "Reintegrate with node.js", etc).

Somewhere I, as a consumer of the product, can look to see where in the priority list my desired feature sits.

As lower tasks move up the priority line, make them more specific (split them into multiple smaller tasks for instance)

Note that I have purposefully not mentioned anything about dates or times - they slip, and often become meaningless.

This also allows folks to contribute with task prioritization, and even working on something they know the core team has put lower in the priority list.

At any rate, you folks are nailing it! Keep up the excellent work :D

[aheckmann]

The value for me is knowledge into the orgs mind; what it thinks is most important: what is receiving attention and in what likely order. It should be kept up to date so the community can use it as a guide for decision making and contribution guidance.

[aheckmann]

The value for me is knowledge into the orgs mind; what it thinks is most important: what is receiving attention and in what likely order. It should be kept up to date so the community can use it as a guide for decision making and contribution guidance.

[whitfin]

I think that were a date to be provided, it would be provided as a tentative date with some form of disclaimer that it could easily slip. It's always a pain to provide a date and then have to explain why it was missed, but likewise it sucks to simply say "Summer 2015" due to the ambiguity.

I think the most important factor is that people can quickly see where something is scheduled (even a rough estimate) so they can make decisions accordingly as @aheckmann says.

[whitfin]

I think that were a date to be provided, it would be provided as a tentative date with some form of disclaimer that it could easily slip. It's always a pain to provide a date and then have to explain why it was missed, but likewise it sucks to simply say "Summer 2015" due to the ambiguity.

I think the most important factor is that people can quickly see where something is scheduled (even a rough estimate) so they can make decisions accordingly as @aheckmann says.

[jesstelford]

@iwhitfield

"Summer 2015" due to the ambiguity.

Not to mention the hemisphere-based ambiguity of when is "summer"?

[jesstelford]

@iwhitfield

"Summer 2015" due to the ambiguity.

Not to mention the hemisphere-based ambiguity of when is "summer"?

[duluca]

Rough dates like Q1, Q2, etc would be very helpful to define some releases around and pinning rough themes to those releases about a year out. As @jesstelford mentions solidifying what does releases are, and what the exact dates are as they come closer.

[duluca]

Rough dates like Q1, Q2, etc would be very helpful to define some releases around and pinning rough themes to those releases about a year out. As @jesstelford mentions solidifying what does releases are, and what the exact dates are as they come closer.

[taoeffect]

I would like to see a clear answer to this question:

what happens when nodejs 0.13, 0.14 and 0.15 are released with features and/or API changes that don't exist in iojs?

See that thread for full discussion.

[taoeffect]

I would like to see a clear answer to this question:

what happens when nodejs 0.13, 0.14 and 0.15 are released with features and/or API changes that don't exist in iojs?

See that thread for full discussion.

[taoeffect]

what happens when nodejs 0.13, 0.14 and 0.15 are released with features and/or API changes that don't exist in iojs?

Let me offer some possible answers to kick things off.

Should Joyent reinvest in nodejs and proceed to make changes that cause it to diverse from iojs, the iojs core team plans to:

• (A) Call Joyent mean names and blame them for the community frustration that arises (divergence continues, community keeps fracturing, sysadmins and developers upset as they try to maintain compatibility across multiple platforms)
• (B) Politely pretend they don't exist (divergence increases, community fractures, sysadmins and developers upset and confused.) Eventually forced to choose one of the other options.
• (C) Deal with the concern proactively by keeping an eye on all changes, merging them back into iojs to maintain compatibility before a stable release is announced (divergence decreases, community happy for the most part)
• (D) Deal with the problems reactively as they arise, say by scrambling to merge changes from stable 0.13 announcement (divergence goes up or down depending on how core devs feal at the time, community seasick and forced to pick sides, developers upset as they try to maintain compatibility across multiple platforms)
• EDIT: (E) Embrace divergence. See comment below.

I recognize that none of these options represent unchangeable courses of action. iojs could choose (D) and later on switch to (C).

However, not having an official stance on this places the community in the uncomfortable position of having to guess what's going on, and could lead to increased divergence (meaning more broken software, upset sysadmins & developers).

[taoeffect]

what happens when nodejs 0.13, 0.14 and 0.15 are released with features and/or API changes that don't exist in iojs?

Let me offer some possible answers to kick things off.

Should Joyent reinvest in nodejs and proceed to make changes that cause it to diverse from iojs, the iojs core team plans to:

• (A) Call Joyent mean names and blame them for the community frustration that arises (divergence continues, community keeps fracturing, sysadmins and developers upset as they try to maintain compatibility across multiple platforms)
• (B) Politely pretend they don't exist (divergence increases, community fractures, sysadmins and developers upset and confused.) Eventually forced to choose one of the other options.
• (C) Deal with the concern proactively by keeping an eye on all changes, merging them back into iojs to maintain compatibility before a stable release is announced (divergence decreases, community happy for the most part)
• (D) Deal with the problems reactively as they arise, say by scrambling to merge changes from stable 0.13 announcement (divergence goes up or down depending on how core devs feal at the time, community seasick and forced to pick sides, developers upset as they try to maintain compatibility across multiple platforms)
• EDIT: (E) Embrace divergence. See comment below.

I recognize that none of these options represent unchangeable courses of action. iojs could choose (D) and later on switch to (C).

However, not having an official stance on this places the community in the uncomfortable position of having to guess what's going on, and could lead to increased divergence (meaning more broken software, upset sysadmins & developers).

[taoeffect]

One more insight:

If I were to know that iojs's official stance is to ensure compatibility with nodejs (as part of being consistent with the story that this project is "really a PR to nodejs"), I would choose to use iojs and recommend it to others, because I will be safe in knowing that my software won't suddenly break in the future for my users.

[taoeffect]

One more insight:

If I were to know that iojs's official stance is to ensure compatibility with nodejs (as part of being consistent with the story that this project is "really a PR to nodejs"), I would choose to use iojs and recommend it to others, because I will be safe in knowing that my software won't suddenly break in the future for my users.

[ghost]

@taoeffect Regardless if you know that it wouldn't be compatible but io.js would still be maintained your users wouldn't suddenly break.

[ghost]

@taoeffect Regardless if you know that it wouldn't be compatible but io.js would still be maintained your users wouldn't suddenly break.

[mikeal]

@taoeffect if accepted, this document sets a pretty good standard for not breaking any backwards compatibility, and that applies to being backwards compatible with both io.js and node.js. In the event that node.js adds API, there would have to be a very good reason for us not to also adopt that API and keep the name/signature of that API. However, it is possible that node.js could, in the future, break backwards compat or alter API that we've adopted. In that situation our choice would be to either maintain compatibility with io.js or node.js and in that situation we would probably stay compatible with ourselves because of this commitment.

As of today, there is not divergence in API between node.js and io.js and going forward io.js won't be breaking that on purpose.

[mikeal]

@taoeffect if accepted, this document sets a pretty good standard for not breaking any backwards compatibility, and that applies to being backwards compatible with both io.js and node.js. In the event that node.js adds API, there would have to be a very good reason for us not to also adopt that API and keep the name/signature of that API. However, it is possible that node.js could, in the future, break backwards compat or alter API that we've adopted. In that situation our choice would be to either maintain compatibility with io.js or node.js and in that situation we would probably stay compatible with ourselves because of this commitment.

As of today, there is not divergence in API between node.js and io.js and going forward io.js won't be breaking that on purpose.

[taoeffect]

@mikeal wrote:

However, it is possible that node.js could, in the future, break backwards compat or alter API that we've adopted. In that situation our choice would be to either maintain compatibility with io.js or node.js and in that situation we would probably stay compatible with ourselves because of this commitment.

OK, thanks for that answer. Sounds like the two projects are committed to what may well be inevitable divergence then. That's good to know though, as it informs how people should document their software.

For my case, it means being clear as to whether our software is designed to run on nodejs or iojs.

@BenjaminProgram wrote:

@taoeffect Regardless if you know that it wouldn't be compatible but io.js would still be maintained your users wouldn't suddenly break.

The software could break for our users. The situation I had in mind is where they decide to run our software with either iojs or nodejs and a compatibility breaking change is introduced in a new version. In that situation, unless they are following our recommendations, the software could break if they upgrade their version of iojs, nodejs, or our software if (1) either introduces breaking changes (i.e. by deprecating something), or (2) we decide to take advantage of some new feature/API that's introduced in one platform that's not available in the other.

I still hope that Joyent and the iojs team figure something out. The longer it takes you guys to do that, the less likely a merge is to ever happen.

[taoeffect]

@mikeal wrote:

However, it is possible that node.js could, in the future, break backwards compat or alter API that we've adopted. In that situation our choice would be to either maintain compatibility with io.js or node.js and in that situation we would probably stay compatible with ourselves because of this commitment.

OK, thanks for that answer. Sounds like the two projects are committed to what may well be inevitable divergence then. That's good to know though, as it informs how people should document their software.

For my case, it means being clear as to whether our software is designed to run on nodejs or iojs.

@BenjaminProgram wrote:

@taoeffect Regardless if you know that it wouldn't be compatible but io.js would still be maintained your users wouldn't suddenly break.

The software could break for our users. The situation I had in mind is where they decide to run our software with either iojs or nodejs and a compatibility breaking change is introduced in a new version. In that situation, unless they are following our recommendations, the software could break if they upgrade their version of iojs, nodejs, or our software if (1) either introduces breaking changes (i.e. by deprecating something), or (2) we decide to take advantage of some new feature/API that's introduced in one platform that's not available in the other.

I still hope that Joyent and the iojs team figure something out. The longer it takes you guys to do that, the less likely a merge is to ever happen.

[taoeffect]

On the topic of a roadmap, for us a debian package is probably the number one thing preventing iojs adoption. What's the roadmap on that?

[taoeffect]

On the topic of a roadmap, for us a debian package is probably the number one thing preventing iojs adoption. What's the roadmap on that?

[mikeal]

OK, thanks for that answer. Sounds like the two projects are committed to what may well be inevitable divergence then.

I don't think you understand my answer. We won't be intentionally breaking compatibility. The possibility exists that node.js might but we have no reason to think they will at this point.

[mikeal]

OK, thanks for that answer. Sounds like the two projects are committed to what may well be inevitable divergence then.

I don't think you understand my answer. We won't be intentionally breaking compatibility. The possibility exists that node.js might but we have no reason to think they will at this point.

[ghost]

@mikeal I think that the roadmap should include features and dates.

[ghost]

@mikeal I think that the roadmap should include features and dates.

[taoeffect]

@mikeal wrote:

I don't think you understand my answer.

I'm pretty sure I did... it might be that you might not be seeing the implications of your answer, or are focusing on something I am not talking about, like:

We won't be intentionally breaking compatibility.

That I always understood and therefore was not the concern.

The concern was what would happen if nodejs made a breaking change. Your answer was:

in that situation we would probably stay compatible with ourselves because of this commitment.

That is called divergence.

[taoeffect]

@mikeal wrote:

I don't think you understand my answer.

I'm pretty sure I did... it might be that you might not be seeing the implications of your answer, or are focusing on something I am not talking about, like:

We won't be intentionally breaking compatibility.

That I always understood and therefore was not the concern.

The concern was what would happen if nodejs made a breaking change. Your answer was:

in that situation we would probably stay compatible with ourselves because of this commitment.

That is called divergence.

[mikeal]

On the topic of a roadmap, for us a debian package is probably the number one thing preventing iojs adoption. What's the roadmap on that?

That's being done here nodejs/node#640

[mikeal]

On the topic of a roadmap, for us a debian package is probably the number one thing preventing iojs adoption. What's the roadmap on that?

That's being done here nodejs/node#640

[mikeal]

That is called divergence.

Sure, divergence is possible but is it likely? No, especially since we won't be doing it intentionally and Joyent shows no signs of doing it intentionally either.

[mikeal]

That is called divergence.

Sure, divergence is possible but is it likely? No, especially since we won't be doing it intentionally and Joyent shows no signs of doing it intentionally either.

[taoeffect]

Sure, divergence is possible but is it likely? No, especially since we won't be doing it intentionally and Joyent shows no signs of doing it intentionally either.

Excellent. I'm happy to hear that, and hope it stays that way. Playing nicely with everyone is worth a smile. 😄 👍

Edit: just remember that choosing to not merge changes they make in nodejs is also choosing to diverge.

[taoeffect]

Sure, divergence is possible but is it likely? No, especially since we won't be doing it intentionally and Joyent shows no signs of doing it intentionally either.

Excellent. I'm happy to hear that, and hope it stays that way. Playing nicely with everyone is worth a smile. 😄 👍

Edit: just remember that choosing to not merge changes they make in nodejs is also choosing to diverge.

[ghost]

@taoeffect @mikeal

Your edit signifies a very important point because it is necessary to include the recent changes to nodejs. Also a divergence could be avoided by maintaining the nodejs features alongside iojs features.

[ghost]

@taoeffect @mikeal

Your edit signifies a very important point because it is necessary to include the recent changes to nodejs. Also a divergence could be avoided by maintaining the nodejs features alongside iojs features.

[taoeffect]

For completeness sake, I should add option (E):

• (E) Embrace, accept, and expect divergence. Community fractures, developers & sysadmins may or may not be upset, depending on what you tell them.

It should be noted that choosing (E) means being clear on your message and dropping the story of "this is just a PR to nodejs". If you do it right, there's nothing inherently wrong with this choice. Damage can result only if the message that you send is "this is a PR to node, we don't expect divergence", when the reality turns out to be the opposite.

[taoeffect]

For completeness sake, I should add option (E):

• (E) Embrace, accept, and expect divergence. Community fractures, developers & sysadmins may or may not be upset, depending on what you tell them.

It should be noted that choosing (E) means being clear on your message and dropping the story of "this is just a PR to nodejs". If you do it right, there's nothing inherently wrong with this choice. Damage can result only if the message that you send is "this is a PR to node, we don't expect divergence", when the reality turns out to be the opposite.

[dotnetCarpenter]

I am seeking info about the time frame for the http2 project. Just a Q date would be nice. I volunteer for firefund.net and we're constantly growing. I have very little time for the project but need to plan our very limited resources for the next 6-12 months (tech wise).
An example could be: *Should we work on npm modues for our backend, focus on web components in the front end or perhaps we need a GUI for our non tech volunteers (the bulk of us).
Ideally a roadmap would provide me with all the information I need to do that.

I don't need the nitty-gritty details - I can get that from the issue tracker. But an overview of where the developer resources are spent the next 6 months. A list like Microsoft's https://status.microsoftedge.com (although it seems to be down right now) would be great but isn't required.

[dotnetCarpenter]

I am seeking info about the time frame for the http2 project. Just a Q date would be nice. I volunteer for firefund.net and we're constantly growing. I have very little time for the project but need to plan our very limited resources for the next 6-12 months (tech wise).
An example could be: *Should we work on npm modues for our backend, focus on web components in the front end or perhaps we need a GUI for our non tech volunteers (the bulk of us).
Ideally a roadmap would provide me with all the information I need to do that.

I don't need the nitty-gritty details - I can get that from the issue tracker. But an overview of where the developer resources are spent the next 6 months. A list like Microsoft's https://status.microsoftedge.com (although it seems to be down right now) would be great but isn't required.

[mikeal]

/cc @jasnell

[mikeal]

/cc @jasnell