As a community, I want a roadmap.

[rickmanelius]

What happened (or feature request):

• Feature request

What you expected to happen:

• Users evaluating ddev should see not only the current feature set, but the defined roadmap that is ready for public consumption.
• As features are completed, the roadmap is updated alongside tests and documentation.

Anything else do we need to know:

There will likely need to be short and long term solutions to this. Short term, we have an internal document that is useful to generate and prioritize tickets.

Long term ideas on how/where to track:

• Use wiki that github provides. The roadmap could be a simple markdown file with milestone label and feature list showing checkmarks for each github issue that is linked to it.
• Include a roadmap.md file in the ddev repo that can be updated via PRs alongside code, tests, and documentation that delivers the feature. Similar to the wiki, this would be a simple markdown file with milestone label and feature list showing checkmarks for each github issue that is linked to it.
• Submit github meta issues. Essentially each milestone would have a all encompassing meta issue.

Related source links or issues (like source JIRA issue):

[cyberswat]

Here are some links worth considering:

• https://github.com/eBay/Kubernetes/blob/master/docs/roadmap.md
• https://github.com/kubernetes/helm/wiki/Roadmap

[rickmanelius]

Moving forward with github meta issue. Also link this to the release strategy tickets.

[rickmanelius]

Another link to surface. Kevin had references this before as something worth considering. https://deis.com/docs/workflow/roadmap/roadmap/

[rickmanelius]

Thanks, @cyberswat for the links. Rather than re-invent the wheel, it would make sense to draw from the strategies presented in more established open source projects that have fully embraced Github as their primary platform of communication and interaction. It dovetails nicely with some of the ideas we've already discussed above (meta issues, milestones, and/or a wiki). The Kubernetes community appears to adopt both for different subsets of its projects, so I'll proceed with the following combination:

Roadmap Document

• Location: https://github.com/drud/ddev/wiki
• Detail Level: High-level overivew
• Audience: End-users
• Focus: Intentionality
• Update Frequency: Each release

Milestones

• Location: https://github.com/drud/ddev/milestones
• Detail Level: Every tagged issue
• Audience: Developers
• Focus: Details to done
• Update Frequency: Each release

Release Issue

• Location: A Github issue per milestone.
• Audience: Product owner and DRUD maintainers.
• Focus: QA/QC and administrative items.
• Update Frequency: At the end of each release.

This sounds like a lot. In practical terms, there is a roadmap document that highlights key features and intentionality, the milestones show all the detail to achieve each release, and the release issue ensures that we've met the acceptance criteria and finish all wrap-up items.

Next Actions

• Create the Roadmap wiki page.
• Populate the Roadmap wiki page with known milestones and high level features.
• Create release issues for the next two milestones.
• Create punch list for release issues. (See proposed here https://github.com/drud/general/issues/3#issuecomment-291197831)
• Summarize this overview more succinctly in the Roadmap file.
• Review with the project maintainers.

[rickmanelius]

Pulling known milestones and information from https://docs.google.com/document/d/1qr4F6-ajwZUTP1kJZIAJfIYGmANNccO6SSJ7lTGhloI/edit#heading=h.ai20puz8ndwk so that we have this information in the public issue queues.

[rickmanelius]

Updated the Roadmap wiki to include information from v0.2, v0.3, and v0.4 https://github.com/drud/ddev/wiki/Roadmap.

[rfay]

@rickmanelius after long and unhappy usage of github's wikis, I recommend using a normal markdown file in the repo instead. We could all agree that editing it by you didn't require PR approvals... And you can edit inline just like on the wiki.

[rickmanelius]

@rfay While I'm a markdown purist as well, I'm attempting to be pragmatic in the very short term to get this moving and not be a blocker. If by the next milestone we're ok with finding a home within the repo, I'm happy to move at that time and forward the link from the Github wiki to a new home.

[rfay]

I'm fine with it any way we do it. My problem isn't about markdown, it's about Github's oddities about how the wiki works. It does have a (separate) repo backing it, but anybody can change anything any time and nobody will know the difference unless they look really carefully. And a page like this is often not discoverable. You won't find many repos on github that use wiki I don't think.

Again, just saying it's one of the github features that ought to be useful but causes more trouble than it solves.

[rickmanelius]

Yeah I'm not a fan of the separate repo (I surfaced that when discussing w/Brad as well). And in terms of access/version control, that is something I hadn't reviewed as closely). So for the immediate future, I'm going to chug on it but look to move over when we can square away the details you've mentioned above (editing protocol, location within the repo, etc.).

[rickmanelius]

Related https://github.com/drud/general/issues/3 (release and pre-release strategy).

[rickmanelius]

Added a proposed release checklist in the related issue https://github.com/drud/general/issues/3#issuecomment-291197831. I'll not consider this done until we have that one documented. That said, moving on the creation of the release issues because they will be a significant improvement of our release processes.

[rickmanelius]

Once this is reviewed/approved (https://github.com/drud/general/issues/3), then I'm unblocked to carry this to the finish line.

[rickmanelius]

Considering this closed!