Roadmapping
If you don’t know where you’re going, you’ll end up someplace else.
In the Sustainability Workshop Survey, held in preparation for the 2018 NumFOCUS Summit, less than 30% of NumFOCUS-sponsored projects affirmed to having an up-to-date roadmap.
A roadmap is extremely important for attracting supporters and contributors. This is especially true for corporate stakeholders that can afford to think (and pay) long-term. In this post, I will briefly talk about what goes into a roadmap and illustrate how various projects within the NumFOCUS ecosystem have successfully gone about drafting theirs.
Vision, Strategy, and Objectives
A roadmap worth reading is more than just a timeline or list of tasks to be completed. In the open source context of unpredictable resources and ephemeral volunteer commitments, a strict timeline (with dates and all) is likely doomed to fail and may even prove demoralizing.
Within a roadmap document, you’ll normally have a vision that preemptively answers yes, no, or not now to any and all new issues or requests that inevitably surface in the day-to-day of a project.
For example, Bokeh’s 2017 roadmap vision was modest but unambiguous — “move towards a 1.0 release.”
Often, projects have multiple roadmaps tailored to specific audiences. It’s not uncommon for the product roadmap and the technical roadmap to be slightly different, nonetheless, both visions must always be in alignment. Whereas the product roadmap may be slow to change, the technical roadmap should be constantly updated to reflect recent technical progress, setbacks, or learnings.
SciPy publishes both a high-level product roadmap and a detailed technical roadmap with module-level resolution.
Strategy can be broadly set upfront or mixed within the various objectives that help move towards the vision.
Advancing toward the vision of “any form of purely symbolic mathematical computation,” each objective within the SymPy roadmap broadly outlines a strategy for implementing and achieving the objective.
Questions do not belong in a roadmap document. Questions ideally belong in planning, notes, or draft documents.
Lead the Road
Don’t be afraid of prioritizing one objective above another as to not discourage specific types of contributions. Earnest contributors are happy to contribute and often come to learn. They will most likely work on whatever is personally interesting, not what seems most important.
If you have guaranteed resources and can plan long-term, then synchronous objectives should be mapped by sequential priorities.
If you’re not sure, mapping by implicit priorities helps when it comes to allocating resources.
Priority and sequence should not be neglected. Sequential priorities means some objectives are higher priority because they must be completed before others can start, finish, or best be implemented. Implicit prioritization, done simply by listing one objective before another, focuses attention on where you need help the most. The SciPy Roadmap is an excellent example.
Don’t be concerned about seeming biased or favoring one type of contribution over another. Do what’s best for the sustainability of the project. In the long term, this ensures that your contributors’ efforts (big and small) are not done in vain. It’s infinitely better to have a controversial and clear roadmap than a neutral and questionable roadmap.
Maybe in error. Never in doubt.
More…
For more on roadmapping, check out the NumFOCUS Summit slides for Roadmaps Session (by Ralf Gommers) and Beyond the Technical Roadmap (by Brian Granger).
