Everything’s a bug (or an issue)

5/22/2025 at 3:17:21 PM

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.

by SoftTalker

5/22/2025 at 4:21:01 PM

> 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.

by crabbone

5/22/2025 at 4:28:34 PM

> > 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.

by quietbritishjim

5/22/2025 at 4:41:33 PM

> 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.

by crabbone

5/22/2025 at 5:41:47 PM

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.

by Joker_vD

5/26/2025 at 4:55:03 PM

But, like I mentioned above: bugs have many properties, can be grouped permanently or ad hoc... you either need to label the connection you make between the commit and the bug, or have bug modalities, otherwise these connections become meaningless / useless.

To flesh it out, let's suppose this (uninvented scenario, I literally opened JIRA on the last ticket I worked on, it's called "Jupyter wizard" and has to do with a TUI utility that allows one to configure Jupyter installation). There are multiple people interested in this ticket who work on the source code:

* QA tester (needs to verify multiple features of the wizard). * QA manager (needs to know the status of testing / communicate to the tester). * R&D programmer (needs to write the code for TUI). * R&D manager (needs to supervise the programmer).

Optionally, of course, the head of the R&D department and anyone under him / her might want to look at the issue and contribute as well as release manager, product manager, customer support...

All the people involved have a reason to tie different commits to this issue. The tester may add a new test checking whether users can install VNC for Jupyter. The QA manager may annotate the added test to be included in nightly CI runs. The programmer may add code that breaks the test and the programming manager may add code to hide the newly added feature behind a feature flag in order to prepare the code for the upcoming release.

If all these people will only be able to say "commit" x "ticket", then for everyone involved there will be a lot of white noise when they try to discover the relevant work done on the feature. In fact, it will be so much, that such pairing will become meaningless because the team across the hall will also refer to this issue because they are writing the TUI library to be used in wizards, the customer support will request documentation for the feature and documentation writer will have to add more commits, again, referring to the ticket, producing multiple versions of the said documentation conditioned on release version...

In the same way how JIRA asks users when linking tickets together: how they should be linked, the commits and tickets also need to be linked in different ways to explain the nature of the relationship.

by crabbone

5/23/2025 at 9:53:56 AM

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..

by john_the_writer

5/22/2025 at 1:41:58 PM

> Error establishing a database connection

Simply poetry

by teeray

5/22/2025 at 2:30:48 PM

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.

by cratermoon

5/22/2025 at 2:43:15 PM

“badly broken but doesn’t matter”?

by jes5199

5/22/2025 at 2:56:46 PM

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.

by sixtram

5/22/2025 at 3:19:56 PM

In my experience it depends on who the single person is in the pecking order.

by djeastm

5/22/2025 at 5:47:22 PM

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.

by Joker_vD

5/22/2025 at 6:56:14 PM

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.

by dylan604

5/22/2025 at 4:13:31 PM

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.

by oftenwrong

5/22/2025 at 5:44:50 PM

> 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.

by robertpateii

5/22/2025 at 4:44:24 PM

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.

by crabbone

5/22/2025 at 5:21:47 PM

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.

by duxup

5/22/2025 at 2:28:32 PM

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!

by 0atman

5/22/2025 at 2:34:03 PM

Unfortunately, Pivotal Tracker was decommissioned on April 30, 2025. It's dead and gone.

Related HackerNews discussion: https://news.ycombinator.com/item?id=41591622

by queezey

5/22/2025 at 3:28:11 PM

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.

by vinnymac

5/22/2025 at 5:05:41 PM

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.

[1] https://linear.app

by arzmir

5/22/2025 at 5:36:45 PM

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.

by stevekemp

5/22/2025 at 2:46:18 PM

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."

by scotty79

5/22/2025 at 3:02:33 PM

How would you debug that, tho?

by bdhcuidbebe

5/22/2025 at 3:30:39 PM

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.

by Joker_vD

5/22/2025 at 2:06:48 PM

If I'm understanding correctly GitHub Projects solve your concerns with using GitHub Issues

by codydkdc

5/22/2025 at 9:14:27 PM

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.

by joshstrange