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.
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.
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.
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.
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.
Still, good read none the less.
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.
teeray•6h ago
Simply poetry