What are some communities that got their roadmap right?
-
I need your help, everyone.
I've previously thought that our GitHub milestones and project board were enough to say what we're targeting for the next couple of releases. However, we're still getting questions like "when will you create a development roadmap?"
Obviously, GitHub milestones aren't enough.
I've read a lot of differing thoughts on the process of creating a roadmap document, but ultimately it's a document from and for the community. I'd like to know what people requesting a roadmap in our community want to see from us. Do you have any examples of "Roadmaps done right" in other communities? Please, post some links and say why those roadmaps are "better" in your mind.
In the end, I know that the process of developing and getting feedback will be more important than the final document itself. For that reason, please share your thoughts on the process of developing a roadmap as well.
-
@unisuperbox I wonder if it's not really about a roadmap, but more about the excitement around the project (and creating more excitement), wanting to know what the latest developments are, and wanting to feel part of the community by being part of the conversation.
All too often, in "communities" there can be a sense that the individual is not really an important functioning part. It's always reassuring to hear that people are listening and wanting feedback.
EDIT
Anyone who has read any of this forum, knows what the developers are working on, and knows the priorities. I guess they could be formally written down somewhere. Coloured in, even. What does concern me however, is the use of a roadmap to put unnecessary pressure on developers by setting deadlines and expecting them to be kept. Oftentimes, creative work happens out of order and in unexpected timeframes. -
@unisuperbox in my opinion the nicest roadmaps are those Gantt charts but I don't know if that would be enough for the people asking for a roadmap.
I think @3arn0wl has a point when he suspects that all those demanding a roadmap what they really are asking for is we want more buzz (and more devices, more apps, and more whatever). Probably the same people that think hundreds of developers are working for UT
Anyway, even if a Gantt chart isn't enough for some, I think it's the best way to quickly see where we are, where we're going, and the time we're going to spend doing it.
-
I believe UBports project two main meta goals are:
A. Developing Ubuntu Touch (for many reasons, privacy, security, need of free software,...),
B Growing the community strengthSo an useful (meta) roadmap (for me) could be like that:
Roadmap of UBports project (20180521)
A. Developing Ubuntu Touch
A1. Releasing 16.04 update --> end of June 2018
A2. Releasing OPO3 and OPO5 ports --> 3 months after A1
A3. Releasing UT for librem 5 --> January 2019B. Growing UBports community strength
B1. Releasing accurate and updated statistics about (growing
number of users, by countries, devices --> September 2018
B2. Launching a donation campaign to achieve a goal of 100 K€ for 2018 --> September 2018
B3. Releasing UBports websites versions in Chinese, Deutsch, French, Portuguese, Spanish --> end of 2018 -
Yes, perhaps the actual question is, why they want to have a roadmap. But we also had the discussion upon how decisions are made and development is prioritized (somewhen, didn't we?). So what I would be interested in, is a bit more formal way of getting to know what the community really wants (and what people don't want on the other hand). I would think of the followings steps in order to get a roadmap:
- Proposing features. (To some degree everyone should be able to propose stuff)
- Maintaining features: Discussing, detailing and developing different "versions" of them.
- Finally deciding what the community wants by voting (who is allowed to vote?)
I think, its not a bad idea having more transparency here... So at least for me I can say, I don't know what the community wants except for scopes...
Just having a vague feeling about the rest.
As a first step I could imagine the community asking for features in an informal way in the forum (as we do it already) and the developers proposing solutions (perhaps in another separate forum) and the community voting for and commenting on the proposals?
Unfortunately I don't know any examples - just my thoughts on that.@libremax Whats about Anbox, Unity8 on the desktop and fixing Bluetooth for example?
-
I don't know what the community wants except for scopes...
@hummlbach do you think there's a majority of users wanting them or a very vocal minority? I don't know the answer myself, that's why I'm asking.
-
@advocatux Yes just kidding, for sure we don't know that either...(?)
-
@hummlbach said :
@libremax Whats about Anbox, Unity8 on the desktop and fixing Bluetooth for example?
The core team is in the best position to know what goals are achievable. The objectives that I have mentioned in the Developing Ubuntu Touch" section of my roadmap are only examples and because they have been announced by the core team, (but without timeframe).
Anyway Anbox is secondary to "Releasing 16.04" (and many UT users don't care).
For Unity8 on the desktop, it's different because I believe it's a side project but important to retain and attract developers and to expand the community. Could be a B4. point in my roadmap. -
Thanks everyone for your input.
@3arn0wl I believe there is an understanding in any project (by company, community, or nonprofit) that task deadlines need to be set (and malleable) to account for extenuating circumstances and new information. For example, at one point we thought we needed to update Oxide to its newest version (an error-prone and difficult process), but now we've determined that QtWebEngine both uses a newer version of Chromium and is easier to integrate than we expected. So, the "point on our roadmap" to upgrade Oxide would be removed and replaced. No big deal.
@advocatux I'm not sure a Gantt chart really fits into my way of thinking, but I could do it. A PERT (aka network) chart might be a better match for our diverse and interdependent project.
Either way, the chart or other visual aid is secondary to the process of creating and maintaining it.
@libremax, I like the breakdown of "big ideas" into smaller tasks. That would make for some great content for rationalizing the decisions we make at the end of this process.
@hummlbach, I always have to take pause when we talk about allowing everyone to request features at will. I go back to the example of Ubuntu trying the same. Canonical created a website where users could propose and upvote different features. Some extremely difficult to implement features became highly upvoted, but the community didn't have any interested developers to work on them. This led to the feature voters becoming very disillusioned with the Ubuntu project and community. "No one is listening!" they cried.
So, my default reaction to "Who is allowed to vote?" is "The people who are moving the project forward", meaning those who are donating their time or money. I think that the process of proposing, discussing, and implementing features will always roll back to what most communities have now: a group of interested users come together, one or more of them is a developer, so the feature gets developed and implemented. We're seeing this process of "little groups" popping up a lot, most recently with people interested in running UT on the Raspberry Pi.
The big point
What I can take away from this discussion so far is this: the real problem that people are using "roadmap" to solve (at least in their mind) is transparency of decisions, visualized and rationalized in a way that our community can consume. What do you all think of this conclusion?
-
I'm with Douglas Adams on the subject of deadlines, @unisuperbox: "I love deadlines. I like the whooshing sound they make as they fly by."
But I think your conclusion is probably right: a document, front and centre, setting out the work to be done in logical order - a scope and sequence, in educational parlance. You could also initial tasks, if you wanted to go that far.
-
@unisuperbox using PERT is okay for me too, use the tool you're more comfortably with.
About the conclusion, I agree with what you say basically. In my opinion the majority of users want to know at least the goals for the current year and where they can follow the progress. A minority of them are also interested in who is doing what.
That information is available already but users want to get the full picture at a glance, not spending time digging Github repos and the like
