Issue tracking in the forum vs GitLab

Clearing the Path
1

GitLab issue: Decide how we use GitLab issues vs the forum (#614) · Issues · Snowdrift.coop / snowdrift · GitLab

In our last meeting, I brought up a vague tension around Launch re-done website ASAP, marking under construction? and issue tracking here vs GitLab. Afterward, @Salt and I talked and clarified it: It’s time- and energy-consuming to move between platforms.

After opening the forum thread, it would take a few minutes poking around GitLab to figure out which issue(s) were about the same topic. It also added lots of time switching between tabs, to find which one has the relevant information.

In the meeting I proposed that we should use GitLab to discuss actionable work, instead of #shoveling. However, the forum has better moderation tools and discussion can clog up issues, getting in the way of actually doing the work. So instead, we propose:

  • When it’s clear we want to track something, create a GitLab issue for it.
  • Any related forum topics should link to the issue.
  • If a forum topic leads to a decision, it should be captured in the linked GitLab issue, including a link back to the forum topic.

(I’ve done that for this topic)

I have a closely related concern about how much time we spend summarizing our discussions.

Right now we might discuss in a meeting (and take notes), then summarize the outcome here and on GitLab, then update the original issue on GitLab to reflect the changes… This is a whole lot of extra work spent documenting what we decided, instead of just doing it.

It’s not a problem when it comes to the “think tank” side of things. The work there is mostly promoting our ideas, and a well-documented decision making process helps with that; the documentation is part of the actual work. And we expect it to be read by others many times over, so it’s worth a little polish.

On the website side, I think we’re spending more time keeping old comments up to date than we save by not having to read out-of-date stuff — if any, since frequent editing means I have to go back and re-read old stuff, instead of just reading the latest addition to the conversation.

So, I hope linking more creates room for less summarizing & editing.

2 Appreciations
2

I applaud any efforts made to battle this! One area of concern I had relates to all of the work we did sifting through links for Roles and for the Mechanism Proposals recently. Do we have any standard way to indicate that a thread was reviewed in that process so that someone reading back won’t add it to a future sifting?

3

This helps me recognize a core tension:

I’m concerned about noise generated for others when there’s feedback about a GitLab issue.

When I believe some significant changes should be made to the structure of an issue and its scope, it probably makes sense for me to discuss it just with the person who opened it. If I comment on the issue itself in the GitLab discussions, I am concerned about the noise that makes for anyone looking at the issue. But the same applies to creating noise on the forum.

Perhaps the best way to deal with such a situation is a forum PM or Matrix chat rather than being more public. The forum is a bit like a group meeting. I don’t want to be talking half the time, I want to leave space for others.

What’s the right way to balance (A) discussing in public so that others can read the whole thing and can participate versus (B) discussing privately so that the public space has a greater signal-to-noise ratio of meaningful topics where it makes sense to engage more people?

4

Matrix is nice! Still no threaded messaging which can be annoying. Mattermost might also be worth a look.

5

I think probably folks should make sure they are not subscribed to every issue. Now, the large-scale goals are all in epics, and the team should probably be watching those by default, but issues should be more opt-in (unless you can handle the notification load).

That said, I also like the idea of feedback/discussion happening mostly here rather than GitLab. Drop a link to the forum thread in the issue, and vice versa (like this one), and then we can have more open-ended discussion.

That said, while GitHub issues can get flooded with discussion sometimes, GitLab is a bit better in this regard, because there’s one level of nesting available. So if someone posts a tangential comment or feedback, you can have that conversation in the reply and folks reading later can collapse it. It’s still noise in the moment, but it’s not quite as bad as GitHub issues can become.

2 Appreciations