Shields: Roadmap for 2019

[paulmelnikow]

I’d like to make an effort to align on a roadmap for Shields.

We have a big backlog which documents many of the pieces of work we want to do, though it’s hard to see the forest for the trees. The issues list doesn't convey ordering or priority. Some of the issues go back many years. And we have a lot of major efforts going on in parallel.

The advantages of organizing the work into a roadmap:

• It help us align and move faster. 🚀
• It helps maintainers take responsibility for larger projects and areas of the codebase (e.g. self hosting, the badge renderer, developer experience). 🤔💪
• It helps us interact with our developer communities, both understanding needs and helping them find opportunities to plug in. 💬
• It helps create a feeling of progress. 🏆

The disadvantages:

• It's one more place to follow and check, for an already very active project.

The roadmap could be a place to define and articular high-level goals, design and discuss solutions, and prioritize. We could reach consensus on pieces of work there, and link to related issues which provide background and detail. The roadmap would provide a view of what’s currently being targeted, and why, while the issues would become a catalog of the backlog.

I’ve started synthesizing the issue backlog and making some notes:

https://docs.google.com/document/d/1awkf14GL0PYNC7Nv0lup4sPyphNCIrV7bIJx5awlfpc/edit

Some thoughts on how to move forward:

1. We could schedule a call for maintainers and anyone else who wants to join, and take some time to walk through this.
2. We could experiment with a community-driven roadmapping tool. Roadmap looks nice, though there are a few others that seem like they could be helpful such as Taiga, Craft, Roadmap Planner, and ProductPlan. Trello could also be a decent option. Also Google Docs. And GitHub Projects gets an honorable mention (while it seems like it would be good, it's never taken off when I've tried to use it in the past.) I think the most successful tool is one that we use, so whatever tool folks are willing to spend a little time with, reflecting on the project, is probably going to be best.

[paulmelnikow]

On second thought, maybe the google doc or a maintainer-editable wiki page is enough.

[chris48s]

GitHub Projects gets an honorable mention

I've used GitHub projects a bit for this sort of thing. It works quite well when a project can be described _exactly_ as a bag of related GitHub issues, but breaks down as soon as that stops being the case. I also find that not terribly useful for communicating to a wider audience.

I guess it depends a bit how much you want to organise a group of related _tasks_ (in which case something like Trello or GH projects is great) vs how much you want to explain higher level objectives or a narrative (in which case a document or wiki is more suitable)

Taiga, Craft, Roadmap Planner, and ProductPlan.

I have never used any of these things, so can't really say anything useful :D

[paulmelnikow]

It works quite well when a project can be described _exactly_ as a bag of related GitHub issues, but breaks down as soon as that stops being the case. I also find that not terribly useful for communicating to a wider audience.

That's well articulated and matches my experience.

vs how much you want to explain higher level objectives or a narrative (in which case a document or wiki is more suitable)

I think it's much more this ^^

[chris48s]

Maybe a wiki is a good choice then. If its helpful as a point of inspiration, I have seen other projects manage roadmap using a GH wiki e.g: https://github.com/cakephp/cakephp/wiki/4.0-Roadmap

[paulmelnikow]

That's helpful to see, thanks!

[paulmelnikow]

We seem to have a number of things in this project which will be helpful to deal with in Google Docs. How about we use that to supplement the code? I've used it a lot. Editing is fast, it works awesomely in remote meetings, and permissions are really easy to manage if you put documents in a folder. I created a folder for Shields and added the docs I know about to it, and shared it with the maintainers.

How about keeping the backlog in there?

[calebcartwright]

I'm open to anything. My experience with roadmaps/planning/tracking has always either been in a corporate environment where we needed a bunch of things (financials, auditability, etc.) that aren't necessary here, or small projects on GH.

If Google docs seems like a good fit so far then I'd vote we go ahead and start there. Can always re-evaluate down the road if need be

[PyvesB]

I would more be in favour of using some of the tools GitHub provides, as @chris48s mentioned the Wiki and possibly projects if need-be. They're nicely integrated with the GitHub platform and people who aren't familiar with the project will naturally go there to find information. Even as a maintainer I find it more practical compared to having yet another means of communication/organisation such as Google Docs. We experimented listing service tests and migrations in one of them, and on several occasions I had to search through our forest of issues to find the link to the Doc in question.

[paulmelnikow]

Yea, the overhead of an extra tool is definitely a downside of using Google Docs. Though it's not too hard to bookmark a link to the folder: https://drive.google.com/drive/folders/1vZXc-YwGBp0m2-fCHk0wcBlGF2gZ5vVT.

[paulmelnikow]

I haven't updated this document in a while, so just took a second to go through and highlight all the things we've completed in this time. There are probably some big things we've accomplished that aren't represented in there, so if you see any feel free to point them out.

It could be cool to refresh this for 2020. Looking at the unhighlighted parts, maybe 2020 should be the year of building out some structure, governance, and hosting improvements to support us as we continue to grow.