Q3.1 Roadmap Planning [5m / 25m]

At most, this should take 5 minutes to read/understand, and then 25 minutes to process/reply/act on.


We’ve finished the previous phase of our roadmap, so we need to plan the next one, in order to keep our efforts focused and hold ourselves accountable.

Last meeting we decided to try this async[1] on the forum. We also decided to try a shorter, half-quarter phase, so we can iterate more quickly. That means the next phase, Q3.1, ends 2020-08-15T00:00:00Z. We didn’t decide how we would do this update. I propose:

  • Use this etherpad for drafting: https://snowdrift.sylphs.net/pad/p/roadmap
  • Add anything you think ought to happen this phase to the “Current phase” section
    • If you are up for personally committing to doing it, put (your name) after it.
    • Feel free to also add anything you think is missing in the section below, with tasks required for beta launch, or mark any items you feel are not necessary.
  • When everyone @team has done this, or in the 2020-07-17T00:00:00Z meeting, we’ll see if we can find anyone willing to commit to the unclaimed items and, if needed, discuss any additions/removals.

If this process works for you, go ahead and do it! If not, reply here and we’ll figure out something better.


  1. If you need time-boxing (@msiep) and/or would prefer realtime, ping me here/matrix/signal/etc and we'll find a time to quickly discuss 1-on-1. ↩︎

3 Likes

Just to clarify something discussed in coworking yesterday: the overall idea is good, but we want this to be a bit more about charting a plan in general and less about personal commitment. It’s nice to have that sense anyway, and having people who can do something is valuable for putting it on the roadmap. But we want org-wide focus rather than this being personal.

1 Like

Almost done with this, and learned a lot about the process; I expect it to go much more smoothly next time.

I was planning to remove the information about who was taking the lead on each goal (the “point person”). However, now I wonder if it would be useful to leave it on the roadmap. In particular, knowing who’s point on a goal lets anyone interesting in helping know who to contact. Both new volunteers — “I’m interested in helping with X, who do I talk to?” — and us, when reviewing our progress at the end of the period.

If every goal had a corresponding gitlab issue or something, that would serve the same purpose, but that would require making sure there is an open gitlab issue for each goal, which is more process than I want to require at this point in time.

@team Should I keep or remove names from the roadmap?

  • Keep point person and helpers
  • Keep point person only
  • Remove both
  • No opinion

0 voters

Longer/nuanced feedback welcome but not required :slight_smile:

2 Likes

I don’t understand the argument for removing either. After we’ve gone through the process and have a quarter plan nailed down, it is nice to reference back and search your own name to see which things you were supposed to be working on. Also for future accountability, knowing who the fallback is if a point person has to step back, etc. etc.

Clutter mostly — names make it less skimmable, and it is public-facing

edit: if you plan to use it for tracking what you’re working on, that’s reason enough for me to keep it.

I think tracking names in a etherpad document isn’t lending itself to remain in control of how and where you are assigned and visible for others. An issue tracker seems like the natural tool for that – maybe that is more process, but skimming over an extra etherpad is, too.

To me it raises basic questions like Who is supposed to update the pad? Who can look at it? How do I get displayed? … questions that are more easily answered in an issue tracker I guess.

But I have no hard feelings either way right now – I see we are testing waters in many ways, and this is subject to change anyway.

Thanks for taking care @smichel17 :slight_smile:

2 Likes

I don’t think the proposal is to keep the etherpad as anything we formally reference, that was just for drafting. The proposal is to keep the names on the published wiki page.

I happen to agree with the concern of the roadmap getting too much overlap with GitLab. The roadmap is not an issue tracker and shouldn’t be used like one.

But I’m willing to maintain some note about what people said they could work on. I think this goes to the idea of team coach / volunteer coordinator role and in general more clarity about knowing the status and goals on a per-team-member basis. I think it would be that role’s job to work with the team on that. So, if I held that role, I might have chats with everyone here and there and keep notes about how everyone is doing, what issues / needs there are etc. Not sure the balance of public/private there.

I’m okay with some minimal bit of that on the roadmap for now. I’m also okay leaving it off the roadmap. Perhaps for now @smichel17 could note to himself (maybe just via the etherpad) who is doing what. That would be like filling in that missing role to that degree for now.

I decided on point person only.

It’s important to keep the point person because they’re the one to check in with about progress at the end of the phase. Also, any volunteer (team or otherwise) interested in helping with a certain goal will know who to contact (we can link from the roadmap to forum profiles or something later).

If you want to keep track of all the things you’re working on, GitLab is really the place to do that. It allows multiple assignments, so both the point person and helpers can be assigned, as needed. As a stop-gap measure in order to get that info entered in to GitLab (if you don’t remember what you said you wanted to help with, for example), I’ve left the helper names intact in the etherpad we used for updating the roadmap (linked in the top post) — I don’t plan on doing this in the future, though, because differences between it and the published version quickly become hard to manage.

1 Like