Everything’s a bug (or an issue)
bozemanpass.com63 points by dboreham 5 days ago
63 points by dboreham 5 days ago
Loved Bugzilla back in the '00s. Used it just as the author described: everything was a bug. New features, enhancements, actual bugs/problems. Worked very well.
I would differ from the author on the need for tight coupling to source control. There could be any number of folks who want to see what's going on with an item but have no interest in or even understanding of the actual related code. It's easy enough to include a bug number in commit messages to tie the two together.
> It's easy enough to include a bug number in commit messages to tie the two together.
No. This is absolutely not enough. Does the commit resolve the issue? Does it add a test to the issue? Does it disable the buggy feature?
Also, I'm of an opinion that if you are hired to work in software development company, you need to learn how to use version control. Just suck it up, if you don't like it. No excuses. Version control is the protocol for sharing information, especially useful because it's understood by the "grunts" actually creating the product. If a manger doesn't understand this language he or she will be as useless as a manager who doesn't speak any natural language his or her team speaks.
In general, from the QA perspective, QA wants to know a lot more about the connection between the bug and the source code. It may ask questions s.a. "What general group of issues is affected by the change?" or "Is this a work-in-progress kind of change?" or "Does this change affect the performance of the system?" or "Is this change known to affect another change, perhaps these changes are mutually exclusive?" or "Is this change intended for a particular release of the product?". This and similar information is necessary for QA to minimize the number of useless tests to run, to minimize the number of pointless alerts, to have a hope of producing reliable metrics that show overall product quality level increase / decrease.
> > It's easy enough to include a bug number in commit messages to tie the two together.
> No. This is absolutely not enough. Does the commit resolve the issue? Does it add a test to the issue? Does it disable the buggy feature?
They just said that the bug number was enough to "to tie the two together". They didn't claim that was all that the commit message can or should say. For example, "added tests for #24" (followed by some details) would follow that template.
> Also, I'm of an opinion that if you are hired to work in software development company, you need to learn how to use version control. Just suck it up, if you don't like it. No excuses. Version control is the protocol for sharing information, especially useful because it's understood by the "grunts" actually creating the product. If a manger doesn't understand this language he or she will be as useless as a manager who doesn't speak any natural language his or her team speaks.
This is ludicrous. The point of version control is to understand the way that the source code changes. Managers do not need to understand the software at that level of granularity, that is our job as software developers. Issue trackers are a much better fit for that.
> They just said that the bug number was enough to "to tie the two together".
What's the other one they are tying together? Presumably the first one is the commit...
> This is ludicrous. The point of version control is to understand the way that the source code changes.
No it's not. This is why version control exists in programs that generally don't deal with code, s.a. Microsoft Word for example.
And the other is the bug, whose number is being include in the commit message. So the commit is tied to the bug it addresses (whatever "addresses" may mean) by including the ID of that bug in the commit message.
Also, just to clarify, you can have several commits that refer to the same bug, and also commit message may (and likely should) contain some other text in addition to the bug number.
I'd go a step further. Sometimes as a dev, there's no need to even understand the whole app. A Front-end dev doesn't need to know how the API level works and the API dev's don't need to know how the Dev-opts work. I mean it's not a NEED..
All the FE dev need to know is that the API returns the data. Extended.. all a dev of one microservice need to know is that micro-service-x returns..
> Error establishing a database connection
Simply poetry
Regarding priorities, a manager from my past used a system that I liked: Each person had a set of tickets assigned to them, but there was always an unambiguous priority order. At any given time, a given worker would work on their highest-priority ticket that progress could be made on at that time. If anyone wanted to shift that worker to another ticket, then the priorities needed to be adjusted, and the worker would be notified (if they didn't do it themselves). This helped make it clear what people were expected to be working on, and made it easy to see what people were currently working on.
> to see what an individual is working on, what they’ll be working on next, *and what they done recently.*
This last bit is useful, but tricky to get reports on in a single assignee system. Say it’s the end of the week and I want to show off myself or my team. The system would need to track assignee at resolution or at re-assignment, or let me filter all of one user’s activities down.
Does any single-assignee system handle this well? I’ve always had to manually take note of bug IDs mentioned in standups to achieve a good list of who did what when only using one assignee at a time.
I'm always interested in hearing how folks manage these kinds of things hoping to find some clarity, but by the end of reading I'm always thinking "this is all just an organizational preference / horse trading one issue for another".
Still, good read none the less.
I believe the principles the article author is looking for are core to Pivotal Tracker. I've often tried to persuade teams to use Tracker, but everyone sure loves the whiteboard metaphor!
Unfortunately, Pivotal Tracker was decommissioned on April 30, 2025. It's dead and gone.
Related HackerNews discussion: https://news.ycombinator.com/item?id=41591622
I used to use PT for years. Nowadays I use Linear instead for project management and love it.
In true pivotal tracker spirit their mobile apps are terrible, but perhaps that’s for the best.
While we've only used it for a small size greenfield project with 5-6 developers, we have been very happy with the user experience of Linear [1]. It ties reasonably well into GitHub and have plenty other useful integrations. Notion among others. I imagine this would cover many of the author's needs, and I think it also support GitHub as IDP.
I've been forced to use linear a fair bit recently and I have to say it's a mess of client-side javascript that often gets itself into a weird state.
For example open five tabs, each pointing to a new issue. Then clicking on an issue in the current cycle will just show a blank page.
Or when accepting an issue from triage you might find it defaults to "subscribe to updates", randomly. Or you might find you're the owner of a new story for no reason.
The number of times I have to force-reload the website to "fix" things is uncountable. And the whole forced-workflow is unpleasant compared to how I prefer to work. I mean it's better than Jira, in most ways, but .. sometimes I wish to go back to server-rendered stuff even if it is Atlassian-speed, where it felt like your server literally was in Australia the amount of time page-fetches took to complete.
I like that the author distinguishes priority and severity, something rarely appreciated in my experience. Many teams conflate them, spending time working on severe bugs simply because they are severe, when there are important and essential fixes in the queue for the next release.
“badly broken but doesn’t matter”?
A totally broken function that a single person uses once a month to save five minutes isn't nearly as valuable as a well-designed feature that 5,000 users rely on daily to save just one minute each session.
In my experience it depends on who the single person is in the pecking order.
Well, yes. The point is, just because a toaster has rusted through because you've left it on your apartment's balcony for 6 years (because you don't make toasts) — which is pretty severe — it doesn't make it your top priority to fix it. Until, of course, you mother-in-law arrives and throws a spectacular tantrum about the lack of fresh toasts, or something.
That's the thing though, there's always going to be the mother-in-law tantrum that pops up to totally wreck anyone's priorities. Best laid plans will always be tossed out the window because some favored user/client contacts someone high enough that everything you were doing is now put on hold to address something that was already evaluated as a lower priority task be all stake holders involved.
It makes priority lists a joke to me. I've been in meetings where every single new action item became the highest priority, where at the end of the meeting everyone is confused on what the priorities are. It's bad management, and it is utterly demoralizing.
If I'm understanding correctly GitHub Projects solve your concerns with using GitHub Issues
I’m sorry but that system (bug council) sure seems like it’s being viewed through rose-colored glasses and/or I don’t know how well it could work today in a remote environment. Even when I was in an office, if you have a meeting with more than 3 people at least 1 person is not paying attention.
Bug council seems like a huge waste of time (I manage 9 developers but sub-groups are working on completely different projects (which is why it’s broken into 3 teams). Bringing in another team to hear about bugs from a different team almost guarantees zoning out even if there is valuable info being shared.
Also, I don’t see how this process works with general project management. Are there no sprints? How do you track what people are working on and if it’s too much? How do you track that people are completing tasks in a reasonable time? A single-assignee system doesn’t solve that. Powerful queries don’t solve that.
I’ve used bugzilla before, it’s the same as any other ticketing system at the end of the day and no ticketing system can solve project management for you. The things this author is focusing on confuse me and those have never been problems I’ve run into with managing projects/teams.
This article is a lot of ado and pretty shallow understanding of how various departments in software company utilize bug trackers to promote some changes the author added to Gitea project.
In not so many words: Gitea bug tracking ability is poor. The author improved it a little bit, but still not enough for it to be good.
With popularity of myriad of development methodologies there was DDD, Debug Driven Development. You start a project by filing the first bug: "The app shouldn't be blank."
How would you debug that, tho?
There seems to be the source code missing. No worries, you just start writing it. After this is done with, you end up with an empty project/app/web-page/executable/whatever that, however, builds, launches, and runs. Second bug: "the application is just a blank page/screen that doesn't really do anything". And so on.