Everything’s a bug (or an issue)
bozemanpass.com
bozemanpass.com
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.
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.
> 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.
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.
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.
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.
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..
Simply poetry
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.
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.
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.
Still, good read none the less.
Related HackerNews discussion: https://news.ycombinator.com/item?id=41591622
In true pivotal tracker spirit their mobile apps are terrible, but perhaps that’s for the best.
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.
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.