Q3 2020 and, thus, our current previous phase, is over. Here’s my reflection on the current format and process for updating it:
I like:
Time-based progress/priority check-ins
High-level categories
Explicit priorities
Public visibility of priorities
Breaking things down into smaller goals
I don’t like:
A lengthy update process / how much “history” is generated.
Especially, re-brainstorming-and-pruning when circumstances haven’t appreciably changed.
How much text we need to update on the actual roadmap page each time (especially if a goal is not reached in one phase and ends up being listed many times).
Committing to arbitrary deadlines farther away than a week or so
I do have an idea of a modified format. But the details aren’t ironed out and thus it will take too much time to type up, respective to how late I am up already. So, another day.
I think a public roadmap is primarely for potential users that want to know when they actually can use it. Getting this information should be easy.
Right now the roadmap is a huge wall of text that don’t help to get that information! That’s probably the reason why it’s not on the website, but in the wiki.
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.[1]
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.[2]
Stories within a milestone are ordered based on priority, by team consensus.[3]
As a team, we should work on only one story at a time.[4]
Each story should correspond with a gitlab milestone.[5]
Each gitlab issue should be assigned to a story.[6]
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
This lead me to re-read (much of) the issue-tracking blog post that I linked a month or so ago and @chreekat spoke highly of; I picked up on a few things I missed the first time around, and will probably re-read it a third time at some point in the future. ↩︎
Stories are just user-facing features; they don’t have to be written in agile’s “user story” format. The post describes its stories’ length as “At least days, maybe weeks or even months.” Given our team’s output, I expect more weeks-months ↩︎
Actually, this is the only order that matters; the milestones are just more-or-less arbitrary cutoff points to use as anchors / publicity generators. Later we may want to add points-estimation so we can estimate the effort required more reliably, to aid prioritization. But not to start. ↩︎
With notable exceptions, which I will discuss later. ↩︎
I will keep calling them stories to avoid confusion with roadmap milestones. ↩︎
Including things like refactoring — it’s on whoever is doing dev work to decide what code quality improvements are needed to keep things maintainable as we add each feature. ↩︎
Final thing to clarify: I do not propose we switch to stories all at once. For the immediate update, I just want to
Sort what’s currently on the roadmap into alpha, beta, or later
Create one story to prioritize first, “We are able to accept design/code contributions again”
Looking for a short name for this. “Unblocked development”?
Okay, here’s the main one: stratified by skill set. Eg: coding the website is probably not the best use of @wolftune’s time given his skill set. So it makes sense to have a parallel story of getting the bylaws in place / actually functioning as a coop.
Similarly, it’s okay[1] for the design team to be working on a separate story from the development team (who are working on a story that was designed earlier). But note: the design team should never be more than one story ahead of development. Put differently: design should also only work on one story at a time, and the only way they can finish the story is handing it off to development.
(fixed)
Actually, design/development is right on the line of whether they’re separate enough to take on different stories. When development is more active, I’d say yes, but currently I feel like that would result in design getting too far ahead of development. ↩︎
I’m open to approach things differently! But it’s hard to optimize and evaluate things when the “machinery” is basically not turned on. I don’t have the feeling of getting into any groove of workflow inside Gitlab as things are hardly moving on without active developers.
There were no negative initial impressions, either here or when I brought up these ideas in a meeting, I’m going to go ahead and update the roadmap soon, and will consolidate issues into the two repos gradually over time.
