Task workflow in the forum

As one more step towards turning this space into our focal point for conversations around the snap world, we’re retiring our long-running Trello board used for tracking pending and in-progress tasks, and moving that information here as well.

For the basics this is already a much better platform to outline work and discuss it. For the remaining tracking workflow we should be able to establish a few simple conventions that solve the problem. With that purpose I’ll outline below a proposal for how to map each aspect that is part of our use cases.

If you’re not somehow involved in the development process, please feel free to ignore those details, although understanding them may give you a hint of the status of something you care about.

Flagging a conversation as a pending task

Many of the conversations that will evolve here will eventually reach an agreement that requires work to be done. When that happens and the work isn’t performed immediately, the task should be tagged with one of these:

  • backlog - It will get done, but there’s no sense of urgency around it yet.
  • upcoming - The work is in progress or is planned for the following weeks.
  • critical - We need to start working on it as soon as time permits.

Once the task is completed, the tag should be removed.

The conversation only is tracked as a task once there’s comprehension and agreement by the team, so these tags should be assigned by somebody in the team that is able to articulate the rationale for the change.

Some topics will cover large features which will take a long while to get finished and will spawn many PRs and potentially many related bugs in the tracker. It’s okay to keep all of these as a single topic here and simply continue the conversation until the feature is deemed completed. In others cases the agreement will be part of a larger and not quite related conversation and creating a new topic is recommended to better organize and clarify the two conversations.

Adding the work to someone's pipeline

We also need to be able to have a quick view of our own pending work and that of others as well. This is mainly useful for tasks in the upcoming or critical situation described above, although those will not necessarily be in anyone’s list yet.

That will be handled with a tag matching the username of the person that will likely be taking care of the task. Going to the respective tag page will show what this person is up to.

Once the task is completed, the tag should be removed.

As an example, that’s how the topic about improving aliases looks right now:


Managing checklists

Non-trivial tasks are often formed of multiple steps, and it’s good for personal and general awareness to track progress along the way.

Here is the proposed convention for those:

This shows at a glance quite a bit of useful information: what is done and what is pending, which PRs need review, and which tasks still don’t have any code associated with them.

Associating tasks with releases

In addition to using the conventions described above, much of the work in preparing releases consists in tracking other work that is also in progress.

The proposed convention for that is to:

  1. Create a topic specific for the release
  2. Create a milestone in GitHub to track the PRs associated with the release
  3. Create a list with links to topics related to relevant changes performed in the release.

The actual excerpt from the release topic would look similar to:

The following changes were performed in this release:

For the individual code changes, please refer to the GitHub milestone.

Note that the text in the link doesn’t have to match the title of the topic linked to. As described above, in many cases smaller changes will land as part of a larger feature being developed.


So if snapcraft uses those tags as well, won’t we have some noise conflict? I just wanted to mention the tags do have generic names, maybe a $project-$tag might be better?

EDIT: I see now that the tasks are cross project (e2e) and multiple tasks have to take place. There are still tasks that are very specific, like lifecycle internals to each project. I haven’t seen historicals on how much one versus the other exist so that tags don’t become noise for other teams.

Tags are global, but you can search for tags inside a specific category if that’s what you’re looking for.

In terms of lifecycle, it’s not entirely clear what you’re referring to. If it’s about the development routine, then there’s no reason to track that as a specific task since you’re on it all the time. If it is about specific goals that need to be performed, then there’s no great difference from any other workload it seems.

Ah, I made the wrong assumption that categrory == tag

Nothing to see here, carry on :slight_smile:

This looks very nice! I start converting the existing release page(s) now.

1 Like