Add information on process for roadmap

[agjohnson]

We've formalized how we are prioritizing work, but don't currently have resources for contributors that communicates how to work on features that are on our roadmap.

The simple version is:

• Core team works on issues that are Accepted, which implies they are somewhere on our roadmap
• Versioned milestones are our current roadmap
• Named milestones include issues that we aren't yet actively working on. Eventually, these issues will make their way onto a versioned milestone
• Named milestones have priority themselves. We aren't actively working on anything in Cleanup or Refactor -- these aren't priorities. Our current roadmap today dictates that Admin UX features are a high priority.

[RichardLitt]

I'd also like to know the process for how the roadmap is formed, and where contributors can get involved with that (if they can!).

[agjohnson]

Good idea. This is sort of tricky for us as we have found we have multiple roadmaps essentially -- one for community focus, one for our commercial hosting focus, and another for our ad initiative.

I'd like to have a better story for new contributors. One thing we found during GSOC application period was that we had a lot of issues labeld Good First Bug, but these issues, while they were smaller chunks of work that would be easy for new contributors, were also 100% off our roadmap. Therefore, it was really hard to justify the work on reviewing them and guiding contributors.

I almost feel like new contributors should go for easier bugs on our current/upcoming roadmap, or they should be pushed towards milestones we are not going to be able to address anytime soon. Things in Cleanup and Refactor are some of the easiest bits of code, and core will not be focusing on these at any point soon. Similar story for our sprints probably too.

[RichardLitt]

I think that a reframing of what Good First Bug does may help. You're not taking time away from other, mission-critical tags. Instead, you're actively developing the community for the sake of building a better one. Ultimately, the roadmaps matter less than the strength of the open source community. Without the community, the code collapses; with it, you end up having people who are interested in getting involved, rolling up their sleeves, and helping with the good work of making great code.

What I don't know is the percentage of contributors who are keen to get started and who eventually convert into maintainers. However, I think that the amount may actually be nontrivial. If that's the case, then the work training others isn't wasted. It's work which is directly related to the core goal of any open source project, which is building a community of people who are interested in using, and improving, a tool.

Taking a bit of time to make sure that there are easier bugs on the roadmap may help make these efforts less sapping in the short term, but I'm not sure that the short term for a single developer is as important as the long term goal of having two. I may be wrong here!