Stream: implementers
Topic: Jira comment policy
Josh Mandel (Nov 10 2020 at 19:11):
commenting is no longer possible without re-opening.
@Lloyd McKenzie who establishes this policy? I think there are probably good reasons to relax it.
Lloyd McKenzie (Nov 10 2020 at 19:27):
It was established be me as part of the Jira design after seeing numerous instances where people commented on gForge tracker items that had been resolved and nothing happened (because no one ever looks at tracker items that have been resolved and very few people monitor all of the update notifications that stream through their inbox).
What is the use-case for recording comments on an issue that's already resolved (as opposed to opening a new issue that references the original)?
Josh Mandel (Nov 10 2020 at 19:28):
instances where people commented on gForge tracker items that had been resolved and nothing happened
Use case is to record dissenting perspectives, or leave your thoughts for folks revisiting similar issues in the future.
Josh Mandel (Nov 10 2020 at 19:28):
(You often don't want to create a new issue, but you want to express yourself and tack this onto the previous context.)
Lloyd McKenzie (Nov 10 2020 at 19:29):
A dissenting perspective post-resolution won't cause any change. And when people define new issues it'd be extremely uncommon to look through the comments on issues that were potentially similar.
Lloyd McKenzie (Nov 10 2020 at 19:30):
If we're going to capture a comment, it needs to be on something such that our workflow ensures it'll actually get looked at and considered.
Lloyd McKenzie (Nov 10 2020 at 19:31):
Otherwise we're giving people a chance to shout into the void, but nothing more. (And if people submit feedback with an expectation it'll influence things, we don't want to provide a means for that that's not actually going to be monitored.)
Lloyd McKenzie (Nov 10 2020 at 19:32):
Can you describe the sort of workflow you'd like to see?
Josh Mandel (Nov 10 2020 at 19:40):
I'd like to see "a workflow where people can comment on stuff". It doesn't specifically matter whether it's going to "cause any change"; folks should know when/where to write comments when they want to cause change, but closing discussions off doesn't achieve this.
Lloyd McKenzie (Nov 10 2020 at 19:43):
What's the objective of writing a comment no-one will read?
Lloyd McKenzie (Nov 10 2020 at 19:44):
Closing discussions once they're past the point of debate is pretty common on a lot of forums...
Jean Duteau (Nov 10 2020 at 19:46):
I'm seeing Lloyd's point - if I have a JIRA issue that has been resolved and implemented, how would commenting achieve anything? What does a workgroup do with a comment that is entered after the issue has been implemented? It seems to make more sense to me to force commenters to create a new JIRA issue with their concerns and our comments so that they can actually be seen by the workgroup.
Gino Canessa (Nov 10 2020 at 20:05):
I'm not sure I agree thatresolved - change required should count as closed in this context. I know that I've wanted to post comments on issues with that state (e.g., here's an implementation, do people agree it works).
Jens Villadsen (Nov 10 2020 at 20:12):
I don't see how making it cumbersome to comment on 'closed/resolved' tickets (by forcing users to create new tickets that links to existing tickets) solves anything.
Jean Duteau (Nov 10 2020 at 20:15):
so you don't see that commenting on a closed/resolved ticket essentially means your comment goes into the ether? Again, I'll ask: What does a workgroup do with a comment that is entered after the issue has been resolved, voted on, and implemented? If you just want to comment about the implementation, I guess that is okay, but if you're actually trying to re-open the issue or provide dissenting feedback, I believe that opening up a new Jira issue makes more sense.
Jens Villadsen (Nov 10 2020 at 20:23):
A JIRA issue pretty much has full history capacity, so you won't necessary have to create a new issue in order to track changes, unless thats the process you feel most comfortable with (which is sane IMHOP). But the current proces simply not allowing commenting seems a bit rigid
Jean Duteau (Nov 10 2020 at 20:25):
to be clear, it does allow commenting - up and until the issue is closed. and Lloyd gave the rationale for why we don't allow commenting after the issue has been closed which seems reasonable to me.
Jens Villadsen (Nov 10 2020 at 20:33):
you might as well have an end state called Dixi :grinning: . Joke aside, - I guess we just agree to disagree on this one
Lloyd McKenzie (Nov 10 2020 at 20:47):
The issue I want to avoid is people submitting a useful comment that should cause the work group to revisit an issue, but because the comment is made on something closed, no one reads it or does anything with it. The only time you can expect a work group to look at comments on a Jira item is if they're "open".
@Gino Canessa It's possible for 'managers' to comment on 'resolved - change required'. So if you're someone involved in actually making the changes/fine tuning what's to be done, you can make comments. However, you're past the point of making a decision to implement the change, so someone who's just a regular user adding a comment is potentially problematic. If you want something revisited, you need a new issue.
Josh Mandel (Nov 10 2020 at 20:49):
This proliferation of rules and restrictions, and special cases, and the interaction between these rules and states and roles.. makes the whole system impossible for anyone to understand :)
Lloyd McKenzie (Nov 10 2020 at 20:55):
Agree it's complex. I've tried to document reasonably well in Confluence, though I'm sure I haven't captured every nuance. The intention is that you shouldn't have to read all the documentation - you just do what the system allows you to do. If you can't submit a comment and there's something you want to say, then you need to submit a new issue. You can reference the original issue in a your descriptive comment.
Josh Mandel (Nov 10 2020 at 20:59):
Right -- I'm just saying I disagree with this policy. I think @Jens Villadsen does too.
Lloyd McKenzie (Nov 10 2020 at 21:03):
You would rather have people post comments to items that no one will notice, read or act on?
Lloyd McKenzie (Nov 10 2020 at 21:04):
If someone sees something that's dangerous/broken, I'd much rather they raise the issue in a manner that someone will actually have to pay attention to and act on somehow
Josh Mandel (Nov 10 2020 at 21:28):
You would rather have people post comments to items that no one will notice, read or act on?
Correct. Though I'd say it like: you can't force people to actually read and act on comments; it's a fiction to imagine that some complicated matrix of Jira settings can ensure this. So, better to let people express themselves where/how they see fit, and provide guidance (rather than hard constraints) on top.
Lloyd McKenzie (Nov 10 2020 at 22:03):
There's no mechanism to provide guidance - at least not that I have any hope people will read. My intention here is that the mechanism they might ideally want to follow (just throw a comment on the item) isn't available, and it's something they think is important, they'll try to find some other way to raise it (Zulip, new issue, send an email, raise on a call, etc.). If we let them raise the comment where it'll get ignored, then the feedback vanishes and we never fix the problem. (And the user feels like we're ignoring their feedback.)
Lloyd McKenzie (Nov 10 2020 at 22:03):
Are there other opinions on this topic?
Rik Smithies (Nov 10 2020 at 22:35):
A Jira is not the whole topic concept, it's just one discussion about it. When that reaches a conclusion it doesn't mean the entire concept/subject is closed for comment, only this discussion strand of it.
I don't see it as a problem to require starting a new Jira to talk about the same thing. The inability to add comments is a good clue. But it is true that some won't get further than that and it's a shame to lose good input. I do think Jira is not primarily for ongoing discussions but for tracking issues to resolution.
I can only think that a note on a closed in Jira to say "Want to talk more about this? Raise a new issue" would help, but there's probably no mechanism for that.
Or could a short version be added as a workflow choice to closed items e.g. "Reopen as new" or "To comment please make a new item"? It may not even need to be functional, it could be just a context specific message, greyed out.
Elliot Silver (Nov 10 2020 at 23:52):
How about adding a "Post resolution comment" field with a warning that "Your comment might not be seen in typical workflows. Consider raising a new issue."? :-D
Lloyd McKenzie (Nov 11 2020 at 00:10):
"might not be seen" is too soft. "Is unlikely to be seen or acted on" is more accurate. And the question remains what the point would be of allowing that. I could define a transition that might look promising but wouldn't let the user capture anything but instead would just provide a message telling them what they should do instead.
Lloyd McKenzie (Nov 11 2020 at 00:10):
Re-open as new is also a possibility. That would auto-clone the issue and establish a link
Vassil Peytchev (Nov 11 2020 at 04:18):
Looking at the specific use case that started this discussion, I think it brings up a couple of issues:
- Is "resolved, will change" the proper end point for the workflow where an issue is closed for comments?
- After an issue is resolved, allow the submitter to still make comments (for a limited time?)
For the first issue, I think that "resolved, will change" does not indicate the issue is closed. I think this status should be reached with the assignment of the person who will make the change, and the issue is closed when the change is applied.
Once the new "resolved, change applied" status is reached, then only the original submitter, the person who applied the change, and administrators can still make comments - the second point above.
Richard Townley-O'Neill (Nov 11 2020 at 05:46):
I agree with severely limiting comments on completed issues.
I agree that "resolved, will change" status is before completion.
Lloyd McKenzie (Nov 11 2020 at 14:35):
I could open up commenting to everyone rather than just co-chairs and other managers for "resolved - change required" issues on the premise that at least one person from the work group should be looking at the comments (the person who applies the change). However, the reality is that for 'simple' changes, quite often the person applying the changes will just look at the resolution and ignore all the discussion. They'll often only look at discussion where the resolution isn't clear or things are complicated. That's why I limited commenting to only managers, on the presumption they'd have a decent sense of when comments were going to be looked at, and more importantly, that the person applying the changes themselves would be able to comment on the issue.
I don't think we can reasonably force people applying changes to look at the comments, meaning that regular users who make comments are at risk of having them ignored. Are we comfortable with that?
Rik Smithies (Nov 11 2020 at 14:46):
does that only apply before "Change applied", or forever?
Lloyd McKenzie (Nov 11 2020 at 14:46):
Once it's applied, no-one can comment
Rik Smithies (Nov 11 2020 at 14:52):
So it's a narrow time window there possibly. And I think it would often go unnoticed. Once something is resolved I make the change, load the Jira and hit "applied". I don't do a scan over the comments. I am not sure at what point we anticipate more comment. This doesn't seem to help all that much.
Rik Smithies (Nov 11 2020 at 14:53):
I think the issue is really closed once the resolution happens. You can't overturn that with a comment.
Rik Smithies (Nov 11 2020 at 14:55):
I suppose if you spot some fatal flaw that no one else notices, then you could stop it being applied. But that may only be noticed after it is applied anyway.
Rik Smithies (Nov 11 2020 at 14:57):
I think just make it as easy and clear as possible that you can start a new issue about the same topic (but not implying that motions can just be overturned without good reason).
Melva Peters (Nov 11 2020 at 15:39):
I agree with @Rik Smithies I don't go back and look at comments. If someone is interested enough in an issue, they shouldn't be waiting until there is a decision made by the WG to comment. They should have been participating in the discussion to influence the discussion. I think a new issue should be added rather than allowing commenting on issues that have been resolved (based on the discussion and information available at the time).
Josh Mandel (Nov 11 2020 at 15:52):
they shouldn't be waiting until there is a decision made by the WG to comment.
I think there's a misunderstanding -- the submitter creates an issuer; then hears nothing for weeks or months; then gets a notification email that the issue has been "resolved". At this point, they click through and want to leave a comment expressing anything from a "thank you" to an "I understand but disagree", etc.
Rik Smithies (Nov 11 2020 at 16:04):
During that time nothing may be happening. Which is not a Jira issue. But if stuff is happening that they need to hear about they can "request in-person" so that the issue wont be discussed on a call without them being there. There are other channels that they can choose to monitor, where discussion may happen, but if they request "in person" they should get all the information. Commenting after the resolution is the hard part. "Thank you" is a nice to have. But "disagree", is too late by then. Re-open needs to be the step, it just needs to be obvious.
Josh Mandel (Nov 11 2020 at 16:21):
But "disagree", is too late by then.
Of course it won't affect the vote, but it's still a real feeling that a human being might want to express.
Melva Peters (Nov 11 2020 at 16:23):
Often nothing has been happening because the submitter hasn't responded to emails or updates to Jira to get more information - at least that is the experience from Pharmacy. They submit the request without sufficient information and then don't respond to a request for more information or to attend a call to discuss. At some point the WG has to make a decision. Then they don't like the decision. I think if we allow commenting on the issues that are "resolved" or "applied" will set expectations that the decision may change. I think if they really disagree with the change, then they should submit a new issue with sufficient information to guide the decision.
Paul Church (Nov 11 2020 at 16:26):
I don't have strong feelings about this issue but I'm sympathetic to the point of view that a JIRA ticket is a procedural way of forcing a WG to take action, and a comment on a closed issue does not force any action - so for any feedback other than "thank you" it would always be preferable to open a new ticket.
Josh Mandel (Nov 11 2020 at 16:27):
It sounds like I'm in a minority here (though I'll note that this thread tends to reflect the perspective of the more... process-aware side of the community).
Lloyd McKenzie (Nov 11 2020 at 16:35):
@Josh Mandel If the need for 'expressing' is just personal to let off steam, there's no need for that to be supported through the tool. If the intention of the 'expressing' is so that their opinion is heard and understood, then commenting on a closed issue won't achieve that. However, what I'm hearing is that there's a need for a clear option that will allow that opinion to be heard.
So, my proposal would be as follows:
- on "Resolved - change required", add a new workflow option called "Please revisit" that would change the "Resolved - change required" status to a "revisit requested" status. Making the transition would require a mandatory comment, with a prompt telling the user that they need to provide information or a viewpoint that was not represented as part of the original discussion on the issue (as represented in the text and comments of the issue and/or associated Zulip thread). Once in that state, a work group can vote to either re-open the issue (changing it back to triaged) or choose to not re-open, causing the status to go back to "Resolved - change required"
- on all 'final' statuses (deferred, resolved - no change, duplicate, applied, published) add a new workflow called "Create linked issue" that generates a new change request referencing the current issue with a link to the original. (I'm not positive that I can do this, as it's not really a 'transition', but I'll at least investigate.)
Would those changes meet the identified need?
Rik Smithies (Nov 11 2020 at 16:45):
I don't object, but question the need for the first bullet. Objecting about a - presumably successful - resolution, in the time between the resolution and the change being applied, seems a very small subset of this. No harm in it, but I don't think it adds much.
Josh Mandel (Nov 11 2020 at 16:48):
I might prefer the status quo; adding more states to the Jira workflow diagram and making it easy for people to one-click their way into new issue creation sounds likely to add to confusion.
Lloyd McKenzie (Nov 11 2020 at 16:57):
Someday I'll clean up that diagram. However the workflow maintenance process (which uses source control) doesn't give any ability to maintain the diagram (which apparently isn't importable), so every time we import an updated workflow, it trashes the diagram.
Last updated: Apr 12 2022 at 19:14 UTC
