Hacker News Reader

Comment by runarberg | Hacker News Reader

A git commit is a process document. Developers don’t like JIRA. I’ve already left traces of my process when I pushed the code. Developers love GitHub. A robot will associate my git commit with the ticket and mark the ticket accordingly. As a developer I don’t like repeating my self. A robot should be able to catalog my process documents. If middle management wants to use JIRA it needs to be set up so that a developer never has to write to it. The only JIRA a developer will be happy using is a JIRA they don’t have to work with.

View on HN

No, a git commit is not transparent to product, QA, devops, infosec teams.

Opening a jira issue to document a change that everyone should be aware of can take me literally one minute, and I've even assigned it to the sprint and version.

"Developers don't like JIRA, they love GitHub": these are some generalizations that can often be true. However, you can also automate JIRA using your VCS of choice. You somehow make the assumption that only GitHub git + GitHub issues can be automated.

See a nibling comment. In short: GitHub is developer friendly by default whereas JIRA is not. Ideally automation is set up in a way that QA, devops, infosec, customer service etc. get all the documents they need generated and cataloged automatically. It a) saves headaches from the developer and—more importantly— b) prevents pesky developers from making mistakes during the process (e.g. mis-categorize, etc.).

You can automate the same thing with JIRA if you use bitbucket. I even saw process automation with Github and JIRA. This is just an excuse I heard from devs 100 times.

If you use Atlassian's git-based Bitbucket you get the same thing. It's very much like what gitub would be if you asked a project manager to design it. But that's very much an IBM-like approach, where they entice you into buying additional software because of their walled garden.

You can complete JIRA tickets just by using a commit title format, and I don’t buy that there is a better system for QA to report the bugs or feedback themselves...

QA can be automated in the same way using CI/CD. A QA engineer should be able to read the existing process documents from the git history and have confidence in the CI/CD. In fact a QA engineer’s job is made easier if a robot is cataloging the process (as human developers are prone to errors and sloppy work).

Regarding feedback, a developers dream is to never have to ask for one or give one. Tickets should be well formed and ready for the developer to start work efficiently. A customer service engineer is in the perfect spot to ease the work of the developer. If a developer has question they can ask the customer service engineer which in effect is responsible to document the process.

Note that I pick JIRA apart here for no specific reason, it is possible to use GitHub as inefficiently as JIRA and vise versa. However GitHub has developer friendly workflow set up by default, whereas JIRA does not. In fact I’ve never seen a JIRA workflow that is developer friendly.

The real disease is everyone having this separate QA step. QA is part of developing a feature. Do it yourself.

A git commit is a "how," not a "what" or a "why." That's where JIRA comes in (if used properly). I don't love JIRA, but (IMHO) when it's used properly, it's a great tool.

A proper commit message should always have the ”why” (and, if necessary, the ”what”).

And even if it isn’t, how is it a developers job to explain why when there is a linked ticket in the commit message from product explaining it.

Reply on news.ycombinator.com