For the sake of requiring less manual maintenance, I believe the roadmap should not require duplicating information elsewhere than what's already available in Issues and Pull requests. With that in mind, I have recently cleaned up all outdated opened Issues and Pull requests and I have updated the label information of the existing open ones.

Easy roadmap link from README?

• jQuery UI points to its wiki, which has a Roadmap.

Is there a roadmap?

• jQuery roadmap is available on its gh wiki.
• jQuery UI has a roadmap in its wiki.
• Esprima uses milestones and a main track issue for some topics (link shows one for ES6). I didn't find anything else.
• Npm roadmap is available on its gh wiki.
• React.js - An idea of what they are working on could be seen from the meeting minutes.

What's available on the Roadmap?

• jQuery Core - Ongoing work and refactoring efforts.
• jQuery UI - List of milestones (the versions) and a subset of issues for each.
• Esprima - List of milestones (the versions) and a subset of issues for each.
• Npm - Areas of focus. Difference between v2 and v3. Focus of the week.
• React - Found none. Weekly minutes.

PR #528

How about using GitHub's Milestones feature? Not practical enough/anymore?

What value does the Milestones have in your opinion?

@rxaviers
The approach used by mozilla/togetherjs can be helpful to you, they use milestones this way (copied from Ian Bicking's blog, see ref bellow):

Milestones

We decided there was only a couple things we actually wanted to track:

• What are we doing right now?
• What aren’t we doing right now?
• What aren’t we sure about?

We have to regularly reevaluate where issues fit into these categories, so we break category 2 into:

• 2a. Stuff we’ll probably do soon
• 2b. Stuff we probably won’t do soon

We tried using labels for this but it was no good. There’s only a small number of queries you can do with labels, foiling any clever ideas. Instead we have milestones:

Stuff we are doing right now: this is the “main” milestone. We give it a name (like Alpha 2 or Strawberry Rhubarb Pie) and we write down what we are trying to accomplish with the milestone. We create a new milestone when we are ready for the next iteration.

Stuff we’ll probably do soon: this is a standing “Next Tasks” milestone. We never change or rename this milestone.

Stuff we probably won’t do soon: this is a standing “Blue Sky” milestone. We refer to these tickets and sometimes look through them, but they are easy to ignore, somewhat intentionally ignored.

What aren’t we sure about?: issues with no milestone.

We use a permanent “Next Tasks” milestone (as opposed to renaming it to “Alpha 3” or actual-next-iteration milestone) because we don’t want to presume or default to including something in the real next iteration. When we’re ready to start planning the next iteration we’ll create a new milestone, and only deliberately move things into that milestone.

for example, see open and closed milestones.

Ref:

• http://www.ianbicking.org/blog/2014/03/use-github-issues-to-organize-a-project.html

@Arkni thanks for the info. It has been quite helpful.

What I liked a lot about mozilla/togetherjs milestones is that they are semantic, opposed to rigid version numbers and that they answer relevant questions users and contributors have. Although, something I am trying to fix on Globalize is who determines the next tasks: "we" the core team opposed to "we" the whole community.

Trying to guess the subset of tasks that are going to be worked on next was something that our-just-deleted-milestones always tried to do but rarely did right. To give an example, currency parsing #364 was set to 1.0.0, then postponed to 1.1.0, then postponed again simply because other tasks just happened to pop up as more important given the active Globalize community needs.

I'm trying to avoid the useless guessing and instead trying to give community tools to weigh in. Either to express their thoughts or to put hands on and actually do stuff.

I am completely open to ideas on how to improve this. With that in mind, what I have done so far on the WIP PR #528 was to make it clear where the current activity was (the issues in current spotlight that are being worked on) plus to help new contributors to find stuff to work on (some enjoy improving the documentation, some enjoy tackling quick changes, some enjoy tackling a completely new feature). Ideas?

Thanks for the help.

PS: Ian says labels for this was no good because there’s only a small number of queries you can do with them. I'm intrigued with this because what I like about using labels is especially the opposite (the big number of queries you can do with them) 😄. To be honest, I think current gh interface allows one to do virtually the same kind of queries either using labels or milestones as filters (you can use them as ORs, NOTs, etc). I'm still intrigued and open to change if I knew the actual constrains.

cc @ianb ☝️ FYI

Thanks for the help.

You're welcome!

I am completely open to ideas on how to improve this. With that in mind, what I have done so far on the WIP PR #528 was to make it clear where the current activity was (the issues in current spotlight that are being worked on) plus to help new contributors to find stuff to work on (some enjoy improving the documentation, some enjoy tackling quick changes, some enjoy tackling a completely new feature). Ideas?

You could either use both labels and milestones or just one of them, it depends on how you use them.
For example, use labels only to filter issues based on which module of this project the issue describe more (Dates, 'Numbers,Currency, ...), and named milestones (Next work,Current sprint` ...) to tell when these issues or pull requests can be fixed/landed.