As Salt and I were working on the concrete roadmap updates, we started thinking about the next stage: moving excess detail out of the roadmap and into gitlab issues, where it belongs — and particularly about the relationship between those two places.
Long story (pun not intended) short, I think we should:
- Have 3+1 milestones: alpha, closed beta, open beta, and “later”
- Each milestone should contain stories, which take days/weeks/months of work.
- Stories within a milestone are ordered based on priority, by team consensus.
- As a team, we should work on only one story at a time.
- Each story should correspond with a gitlab milestone.
- Each gitlab issue should be assigned to a story.
But here’s the actual reason I’m writing this: I think we should drastically cut the number of gitlab repos we use for issue tracking.
To two: Code and Governance. Everything else can become a label.
My thoughts were already trending in this direction when I came across this paragraph in the aforementioned article:
Second, a huge surprise that I didn’t realize until I started asking around to the teams that were using bug trackers effectively. Bug tracker “components” (aka dividing by “project” or “area”) are almost useless! They are only good for one thing: helping your end users point your bug at the right triage team. Each triage team triages one or more components. Each component is triaged by exactly one triage team. If you only have one triage team, there’s no real reason to have a dozen sub-components, no matter how much sense that seems to make, because it will just confuse your end users (they won’t know which component to use when filing a new bug).
“End users” here including myself and I’m one the people who understands it best. Additionally, there’s a bunch of tools that just don’t work great across multiple repos. Repeatedly moving issues between the code and design repo is tedious and confusing. And most important of all, we have 269 open issues across all projects. Gitlab themselves has two orders of magnitude more open issues (34k) in a single project and they’re doing fine. Us using 7 repos is an absurd over-optimization for breaking things down into meaningful categories. (Aside, there are a few repos themselves that I think are redundant, but that doesn’t matter so much.)
I would propose just one repo, but Governance as a second location makes sense as a place for all the stuff that’s about building snowdrift as an organization. The technical endeavor, and the political one.
- Not counting “Projects” in here since those aren’t really “issues” (and if there are any real issues there, we should move them to either Code or Governance as appropriate.
- A third repo would be okay iff we decide we need something more private than regular ol’ confidential issues.
There’s probably more I could say here, but this is long enough.
After I’ve got initial buy-in from @Salt and @wolftune, I will add @mray to this message, and then share more widely (hopefully by or in next week’s meeting; I added roadmap updates to the agenda). done