6 ms·

I personally find that the more I have to use JIRA, and the more magical ephemeral rules that are set up in it to take actions in response to my actions with it

I personally find that the more I have to use JIRA, and the more magical ephemeral rules that are set up in it to take actions in response to my actions with it, the more terrible it is to use. I've worked on teams where I just threw info into a card, and it was acceptable to use, and I've worked on teams where commits had to have a JIRA tag associated or the commit got rejected, including in instances where bitbucket was timing out it's call to JIRA. In the latter cases, I prayed for Atlassian's swift destruction, but alas, was never answered. So like a lot of tools, it's how you use it, mostly. That said, as far as universal problems, cloning cards has to be one of the worst UX experiences I run into on the job with any frequency that I can't just fix myself. If the web app needs to await a successful or failed clone of a record (or series of them), I'm not sure why they can't implement a modal or a spinner or other component to tell the user that something is happening, then either navigate the user to the new card, or ask the user if they would like to view the new card. Shooting off a process that you say could take an indeterminate amount of time then dropping eventually a completion notification and link in the bottom left panel is just about the least helpful way to communicate that information. edit: unrelated meta comment, but it's funny as hell to me that this question got 4 replies in the few minutes it took me to write this reply, all within 10 minutes of the original. People are really out here just waiting for a chance to complain about JIRA. Myself included it seems. Makes me feel a bit bad, hate to pile on to popular sentiment when others have already commented in a similar direction.

rjsw 4y ago
I'm trying to cleanup a Git tree right now where people haven't put JIRA tags in their commit comments, it is impossible to find out why a change was made, it isn't a totally stupid requirement.
- origin_path 4y ago
  This assumes that writing a ticket causes people to explain their rationale better than a commit comment does. That might be the case, but it often isn't because tickets are filed by developers themselves, or by PMs who just write tickets like: "A system requirement is that users be able to do X" without further explanation.
- jupp0r 4y ago
  So people put the ticket number in the message and then don't write a useful commit message. Congratulations, you just added one roundtrip per commit to the slowest website in existence to every single time you want to look at git history. Did I mention that you can't look at JIRA from a mobile phone?
- coldtea 4y ago
  Yes, "let's tie our codebase to the choice of ticket system forever as a means to commit documentation"
  - yurishimo 4y ago
    You can have both. Also, let's not pretend developers are wholly committed to writing comprehensive commit messages. A ticket number is useful if the change was relatively recent. If the organization moves to a different tool, chances are they are well aware of the potential history they are leaving behind.
    - mgkimsal 4y ago
      and... I've never yet been in a team/project where being able to track/view/find issue/code pairings from years ago was ever remotely useful or helpful. If it was something in the last few months, sometimes people could dig in and try to understand a bit more by asking relevant people. Finding a 'bug' introduced by someone from 4 years ago who doesn't work there any more, then finding the particular ticket that spawned it... this has never been high on the priority list of anyone I've ever worked with.
      - twhitmore 4y ago
        As an architect working on maintenance & refactoring, I find regular value in being able to understand the context (issue tracker ticket) in which a commit was made. Also more than mildly useful for devs doing porting work. Commit comments are rarely substantive enough, and "asking relevant people" is nice but not an actual substitute for keeping meaningful records.
        wizofaus 4y ago
        I can recall multiple times I've determined why the current logic in the code should be not simplified as part of refactoring or fixing a bug after tracking down the original ticket associated with a commit. That original ticket is quite often a bug report, and sure enough, there was actually a good explanation for why the code is written the way it is, which is almost never going to be captured in commit or inline comments. While having an associated unit test is arguably a better way to capture the reason for such code changes, there are many reasons that's far less likely to exist than a JIRA ticket or equivalent.
- pc86 4y ago
  "It's impossible to find out why a change was made" is a completely separate issue. Either the code is documented or it's not, completely polluting your history with JIRA tags isn't the answer - not least of all because like a sibling commenter said you're now forever tied to JIRA, or if you ever move off of JIRA, now get to choose between bringing JIRA tag information into the new ticketing system, or rewriting your entire git history again.
  - rjsw 4y ago
    The project has just moved to JIRA from Bugzilla. The original convention was to put the Bugzilla issue ID in commit comments, these IDs were carried forward when moving to JIRA so people can still search for them.
  - gregmac 4y ago
    It's definitely a concern to rely on the ticket system, but the commit message and the comment can't (and shouldn't) contain every bit of info about a change. Commit message: "Improved clarity and detail in error message" Ok, that's obvious what's happening, and as a standalone change that's absolutely fine. But the question it doesn't answer is why did someone actually put that effort in? If the commit message mentions a ticket, then you can go look that up, and now you can find out, for example: it was a ticket that was an unknown bug being experienced by one specific customer, and so the error message was being improved as part of tracking down the bug. You also see who the customer was, internally who reported/escalated it, how long this has been an issue for, and if the bug was found and eventually fixed or not. I'd argue absolutely none of that belongs in comments in the code, and it's way too onerous for a dev to constantly put that level of detail into every commit message. It's a balance: it's only useful to lookup that info on a small fraction of commits; it takes a lot of time to figure it out when missing (especially if it was many months ago); and putting a ticket number in each commit message is very low effort.
- rowanG077 4y ago
  Or you just write sensible commit messages. Commits together with the messages should require as little out of band information as possible.
  - entropyie 4y ago
    Bullshit. "Fix performance issue in listing page for customer support". Which customer? Is it the same issue as the one this other customer is reporting? How does the support person know the fix has been released? Unless you are expecting devs to copy paste a tonne of info into commit messages, it's way easier to just put the god damn ticket number in the commit title. If you really need to commit something with no ticket, just have a dummy ticket placeholder like DEV-0000. 99/100 it's just laziness on the devs part... It's way easier to add a ticket number than write super detailed commit messages, and every case of missing Jira numbers of seen, there has never been a detailed commit message in its place... /Rant over
    - rowanG077 4y ago
      > Unless you are expecting devs to copy paste a tonne of info into commit messages, it's way easier to just put the god damn ticket number in the commit title. Yes, that's what devs should do. Or link to an issue from the git provider. Commit messages shouldn't contain customer information, they should contain fine grained information why the change fixes a particular issue and other technical minutae. What you doing here is conflating business information and technical information. Business knowledge has no reason to be in commit messages. The code base should be 100% understandable without specific knowledge about what customer wanted what. It would be a huge red flag for me to see those things talked about in the context of the commit messages as a regular thing.
      - entropyie 4y ago
        I hate to break it to you, but code is usually written in support of a business objective and does not exist in a vacuum of technological purity... I say this as someone who's written everything from x86asm to python and everything in between for decades. If it really upsets your sensibilities to insert a reference to that business objective in a commit message then I don't know what to tell you...

rjsw 4y ago

I'm trying to cleanup a Git tree right now where people haven't put JIRA tags in their commit comments, it is impossible to find out why a change was made, it isn't a totally stupid requirement.

origin_path 4y ago
This assumes that writing a ticket causes people to explain their rationale better than a commit comment does. That might be the case, but it often isn't because tickets are filed by developers themselves, or by PMs who just write tickets like: "A system requirement is that users be able to do X" without further explanation.
jupp0r 4y ago
So people put the ticket number in the message and then don't write a useful commit message. Congratulations, you just added one roundtrip per commit to the slowest website in existence to every single time you want to look at git history. Did I mention that you can't look at JIRA from a mobile phone?
coldtea 4y ago
Yes, "let's tie our codebase to the choice of ticket system forever as a means to commit documentation"
- yurishimo 4y ago
  You can have both. Also, let's not pretend developers are wholly committed to writing comprehensive commit messages. A ticket number is useful if the change was relatively recent. If the organization moves to a different tool, chances are they are well aware of the potential history they are leaving behind.
  - mgkimsal 4y ago
    and... I've never yet been in a team/project where being able to track/view/find issue/code pairings from years ago was ever remotely useful or helpful. If it was something in the last few months, sometimes people could dig in and try to understand a bit more by asking relevant people. Finding a 'bug' introduced by someone from 4 years ago who doesn't work there any more, then finding the particular ticket that spawned it... this has never been high on the priority list of anyone I've ever worked with.
    - twhitmore 4y ago
      As an architect working on maintenance & refactoring, I find regular value in being able to understand the context (issue tracker ticket) in which a commit was made. Also more than mildly useful for devs doing porting work. Commit comments are rarely substantive enough, and "asking relevant people" is nice but not an actual substitute for keeping meaningful records.
      - wizofaus 4y ago
        I can recall multiple times I've determined why the current logic in the code should be not simplified as part of refactoring or fixing a bug after tracking down the original ticket associated with a commit. That original ticket is quite often a bug report, and sure enough, there was actually a good explanation for why the code is written the way it is, which is almost never going to be captured in commit or inline comments. While having an associated unit test is arguably a better way to capture the reason for such code changes, there are many reasons that's far less likely to exist than a JIRA ticket or equivalent.
pc86 4y ago
"It's impossible to find out why a change was made" is a completely separate issue. Either the code is documented or it's not, completely polluting your history with JIRA tags isn't the answer - not least of all because like a sibling commenter said you're now forever tied to JIRA, or if you ever move off of JIRA, now get to choose between bringing JIRA tag information into the new ticketing system, or rewriting your entire git history again.
- rjsw 4y ago
  The project has just moved to JIRA from Bugzilla. The original convention was to put the Bugzilla issue ID in commit comments, these IDs were carried forward when moving to JIRA so people can still search for them.
- gregmac 4y ago
  It's definitely a concern to rely on the ticket system, but the commit message and the comment can't (and shouldn't) contain every bit of info about a change. Commit message: "Improved clarity and detail in error message" Ok, that's obvious what's happening, and as a standalone change that's absolutely fine. But the question it doesn't answer is why did someone actually put that effort in? If the commit message mentions a ticket, then you can go look that up, and now you can find out, for example: it was a ticket that was an unknown bug being experienced by one specific customer, and so the error message was being improved as part of tracking down the bug. You also see who the customer was, internally who reported/escalated it, how long this has been an issue for, and if the bug was found and eventually fixed or not. I'd argue absolutely none of that belongs in comments in the code, and it's way too onerous for a dev to constantly put that level of detail into every commit message. It's a balance: it's only useful to lookup that info on a small fraction of commits; it takes a lot of time to figure it out when missing (especially if it was many months ago); and putting a ticket number in each commit message is very low effort.
rowanG077 4y ago
Or you just write sensible commit messages. Commits together with the messages should require as little out of band information as possible.
- entropyie 4y ago
  Bullshit. "Fix performance issue in listing page for customer support". Which customer? Is it the same issue as the one this other customer is reporting? How does the support person know the fix has been released? Unless you are expecting devs to copy paste a tonne of info into commit messages, it's way easier to just put the god damn ticket number in the commit title. If you really need to commit something with no ticket, just have a dummy ticket placeholder like DEV-0000. 99/100 it's just laziness on the devs part... It's way easier to add a ticket number than write super detailed commit messages, and every case of missing Jira numbers of seen, there has never been a detailed commit message in its place... /Rant over
  - rowanG077 4y ago
    > Unless you are expecting devs to copy paste a tonne of info into commit messages, it's way easier to just put the god damn ticket number in the commit title. Yes, that's what devs should do. Or link to an issue from the git provider. Commit messages shouldn't contain customer information, they should contain fine grained information why the change fixes a particular issue and other technical minutae. What you doing here is conflating business information and technical information. Business knowledge has no reason to be in commit messages. The code base should be 100% understandable without specific knowledge about what customer wanted what. It would be a huge red flag for me to see those things talked about in the context of the commit messages as a regular thing.
    - entropyie 4y ago
      I hate to break it to you, but code is usually written in support of a business objective and does not exist in a vacuum of technological purity... I say this as someone who's written everything from x86asm to python and everything in between for decades. If it really upsets your sensibilities to insert a reference to that business objective in a commit message then I don't know what to tell you...