"I'd love to see that more unified." -- Linus Torvalds
In this interview about Git, Linus Torvalds is asked what areas of the tool still need to evolve. He answers as follows:
I'd love to see more bug tracking stuff. [...] I'd love to see that more unified. -- Linus Torvalds
I do too! Let's be honest, the field of bug tracking can be chaotic. When you start working in a new environment, you often have to learn a new issue tracker on top of the new workflows and responsibilities.
What are the issues with most issue trackers?
I will spare you a rant, but here are some reasons why I don't like most issue trackers:
- Most issue trackers I know require you to create an account.
- Most issue trackers are web interfaces.
- Most issue trackers are separate from where developers talk.
- Issue trackers often have to reimplement (informal) discussions.
- Issue trackers tend to evolve into project management tools.
- Issue trackers don't make it easy to reuse their data.
The promise is to make handling issues easier: perhaps for the product manager, but what about for developers? Or for a distributed set of Free Software contributors who work on many projects? How do you keep track of all the GitHub/GitLab issues you're involved in?
Two streams: code and feedback
Let's take a step back.
Software development involves combining two "streams": code and feedback. The code stream can have "tributaries" in the form of tests, CI/CD and so on, but the main source is the code. Feedback can come from your brain, a discussion list, a Slack channel, a meeting room or an HN discussion, but ultimately, it's just feedback.
Bug trackers promise to solve the problem of organising feedback.
Informal feedback tends to be kept in informal communication channels, whereas formal bug tracking takes place on a dedicated tool intended to help maintainers organise themselves. Using a dedicated tool is supposed to improve the quality of bug reports by forcing reporters to provide more detailed information. This is how we got into the habit of splitting feedback into informal and formal, one outside the bug tracker and the other inside it.
I would argue that the split is damaging for most Free Software projects. Most of the time, it is just "premature optimisation" of the feedback stream.
An attempt at not splitting the feedback stream
What if you were not forced to split feedback?
One important idea behind Org mode is that to-do items and free-form notes should live in the same space. You write and brainstorm, and suddenly your notes turn into tasks. Add a heading and press C-c C-t, and you've created a new task.
The venerable Org mode mailing list uses the same trick: everyone is welcome to ask a question, even informally. How do the maintainers search for bug reports? Well, a simple [BUG] in the subject would do. Same for patches ([PATCH] or [PATCH 0/n]) or feature requests ([FR]). And when there are many reports? Well, this is when maintainers need a tool — but an observation tool, not a data-entry one: something that watches the existing feedback stream and surfaces what matters, instead of asking contributors to refile their thoughts somewhere else.
This is what BARK does and you can see it in action for Org mode.
BARK: Another Report Keeper
One part of BARK monitors a mailbox and detects emails that follow certain conventions. Another part exports these reports as data. The HTML website is just one option: you can also fetch reports as JSON or Org files, or subscribe to them as RSS feeds.
If you want to explore BARK reports in your terminal, go get bone.
What if several projects use BARK? Don't worry, you can subscribe to all the JSON files and use bone to display the reports: the data comes to you, you don't have to switch between various bug tracking web interfaces.
If you want to learn more about BARK, please read the manual.
Let's make bug tracking more distributed
Patchwork and the way SourceHut treats patches are steps in the right direction: they don't split the feedback stream. However, once bug tracking becomes read-only, we can take it further by making this information available as data (not just via a web interface) and enabling local subscription (rather than having to check the tool).
Imagine if you could locally keep track of all the issues that are assigned to you? Or if, as aa a11y-oriented community, you could share a BARK instance for a11y-related bugs to fix in various projects?
So yes, I'd love to see "that" more unified too.
Let's explore!
BARK is the successor of Woof! which I prototyped in 2020, after thinking quite a long time on how to help Org mode maintainers (I was one of them at the time).
BARK won't suit every project: teams with formal triage and SLAs may require a different tracker. However, for most free software projects that already use email as their main feedback channel, the design of BARK is appropriate: our tools should observe the feedback stream where it already flows, rather than forcing contributors to pour it into a second container.
The feedback is already there in the mailing lists and discussions; we just need to find better ways to listen to it.