Issues Repository: Issue Closure Policy

[netcarver]

Hello @ryan and @Francesco Schwarz,

There are currently a lot of issues (about 20% of the total) that are still open on the processwire-issues repository but marked as "Resolution: fixed (close when ready)." Some of these date back over a year. I doubt many of the older ones will ever be closed by the initiator. There is a similar situation building up with the issues tagged as "Resolution: Not a bug" - though there are less of them.

If that's the case, how about closing any issues that are 3+ months old (or that have not been tagged as a discussion) with a polite note that the issue should be re-opened if needed? This would really help reduce the list of open issues.

 

[adrian]

Hi @netcarver - I very much appreciate where you are headed with this, but I am not sure I agree with automatically closing issues 3+months old (even those tagged with not a bug, or fixed) because there is often further discussion after tagging which I think warrants further input/consideration from Ryan.

One example is: https://github.com/processwire/processwire-issues/issues/494 - others have chimed in with their agreement and I still consider it a bug because it's possible to set the description and notes for a fieldset. If Ryan doesn't think it's a bug, then I don't think it should be possible to set these in the first place, because it's current confusing and inconsistent behaviour. While I don't expect this will ever be high enough on his priorities to be fixed I still don't think it should be closed because I am convinced it's still something that needs attention, one way or the other.

I think the best approach is to encourage issue OPs to be more diligent in closing fixed issues because with so many building up it becomes even harder for Ryan to reconsider some of these other ones which still have some validity.

I hope that makes sense and doesn't seem obstructionist in moving forward with an improvement to the current situation which is obviously getting out of hand and not sustainable.

[gmclelland]

Maybe some kind of Bot can automate the closing of issues that have been marked as "Resolution: fixed (close when ready)" after 2 weeks of applying the label?  That would at least clean up those issues.

[adrian]

8 minutes ago, gmclelland said:

Maybe some kind of Bot can automate the closing of issues that have been marked as "Resolution: fixed (close when ready)" after 2 weeks of applying the label?  That would at least clean up those issues.

I think that would be ok so long as it only happens if the thread is also quiet for those two weeks and also if it doesn't prevent the OP from re-opening. I think there are quite a few examples where there is ongoing discussion about further refinements to an issue even after that tag has been added.

[wbmnfktr]

4 hours ago, netcarver said:

This would really help reduce the list of open issues.

Sure... but it wouldn't help resolving those issues.

Someone doesn't close an issue just because x amount of time has passed.

Issues were opened for a reason. Therefore they should be closed for a reason, too.

 

[adrian]

34 minutes ago, wbmnfktr said:

Issues were opened for a reason. Therefore they should be closed for a reason, too.

The hard part is getting OPs to actually close issues when they are fixed and there is no ongoing discussion - if we could do that, then things would look quite a bit leaner in the Issues repo.

[wbmnfktr]

I know... closing issues and tickets comes straight after writing documentation. ?

Some things just have to evolve and need to be established. Doing a clean-up once a week doesn't hurt. Ok first due to so many open issues but later on it gets easier.

 

[netcarver]

Thanks for the feedback everyone; some really good ideas here. I guess that Ryan and Francesco are the ones who get to declare if things are getting out of hand though ?

Whilst there is, obviously, the ideal issue closure (issue closed by the opening poster after verification that it is really fixed); the reality is that many of the issues have been left unanswered for many months following a commit to the codebase, addition of a tag and a comment on the issue with an @ mention to the person who raised it. If there is no feedback for months following these actions, I'd personally be inclined to close the issue with an invitation for anyone to re-open with a follow-up post if needed. IIRC anyone can re-open an issue by simply posting a new entry on it; closure does not necessarily mean an end to a conversation.

Best wishes!
Steve

[wbmnfktr]

2 minutes ago, netcarver said:

the reality is that many of the issues have been left unanswered for many months following a commit to the codebase, addition of a tag and a comment on the issue with an @ mention to the person who raised it. If there is no feedback for months following these actions, I'd personally be inclined to close the issue with an invitation for anyone to re-open with a follow-up post if needed.

Ok... I got this totally wrong in your first post and didn't get this @-comment/feedback process.

Sorry if my answer was therefore kind of rough.

With this comment/feedback process I'd agree with your concept of closing unanswered-open-but-fixed issues.

[netcarver]

@wbmnfktr No problem ?

3 hours ago, adrian said:

One example is: https://github.com/processwire/processwire-issues/issues/494 - others have chimed in with their agreement and I still consider it a bug because it's possible to set the description and notes for a fieldset. If Ryan doesn't think it's a bug, then I don't think it should be possible to set these in the first place, because it's current confusing and inconsistent behaviour. While I don't expect this will ever be high enough on his priorities to be fixed I still don't think it should be closed because I am convinced it's still something that needs attention, one way or the other.

@adrian I agree with you (and, as it happens, I agree with your analysis in that issue - it was one of the ones I read before starting this thread), and dealing with these semi-subjective issues is more difficult than the clear-cut cases of a bugfix. However, I'd like to still advance the thought that having a closed issue re-opened, perhaps multiple times, would send a louder signal than keeping it open indefinitely and just having someone give the occasional thumbs-up to one of the pro-posts. 

[Robin S]

The PW issues repo is a bit of a cause for concern I think. Issues are added much more frequently than they are solved, so the collection of open issues is just going to grow and grow over time unless something changes to accelerate the rate at which they are addressed. At the end of the day, it seems the volume of issues is too great to deal with by just a single person with limited time.

And a comment Ryan made in a blog post a while ago left me a bit puzzled:

Quote

The focus here has been on making sure we've got any significant issues taken care of in the GitHub issue reports. If you are aware of any significant and reproducible bugs in the core that affect multiple people (rather than isolated to one instance), those are the issues we want to make sure are covered first, so please be sure to submit them in GitHub issue reports. Or, if there already is an issue report open, please double check that it is still applicable on the current dev branch of ProcessWire. If it is, please let us know that the issue remains active in 3.0.93 by replying to it so that we'll be pinged on it. Thanks for your help in testing and reporting.

Maybe I'm reading that wrong, but it sounds like Ryan believes that almost all significant issues are already solved. I wouldn't agree with that as I think the majority of the open issues are valid ones that affect multiple people. Maybe the fact that there are quite a few issues that have been solved but are still left open is obscuring the fact that a significant number of unsolved issues exist, some dating back a long while. So I would support the idea of closing issues marked solved if it also meant taking a fresh look at the ones not yet solved. 

[netcarver]

14 hours ago, netcarver said:

the reality is that many of the issues have been left unanswered for many months following a commit to the codebase, addition of a tag and a comment on the issue with an @ mention to the person who raised it.

It seems I didn't sample enough of the comments put on the issues. Not all of them @ mention the initiator - so my comment isn't totally valid. I've therefore started @ mentioning the initiating party on the resolved threads - but it takes a while, so I'm appreciating @gmclelland's robot suggestion more now, though I think I'd not want it to auto-close issues but rather auto-remind the initiator to do the close, and later flag it for a human closure decision.

[LostKobrakai]

The only sane approach to issues on github I know is closing them as fast as possible, which can be split up into subtasks by deciding if something is a …

• bug => fix as fast as possible/fitting and then close directly. If there are still things to clarify this can be done in the closed issue. ryan can open it again if really needed, but it's ryans task to say "this issue is resolved" by marking/keeping issues closed. Keeping that responsibility on the issue openers side simply does not work from my experience.
• feature_request => should be closed immediately with a message to where feature requests should be stored
• not a bug => closed immediately
• not reproducable => ask for failing test/repo/something, close if there's no response after x (2-4) weeks

[netcarver]

Well, nice to see some fixed issues being closed now. I count 35+ closures since yesterday, which takes the project well below 200 open issues.

I do hope that some progress can be made on other items. Can we ease creating pull requests for small items in any way, perhaps that would help the overall effort?

[gmclelland]

Thanks netcarver!

Coming from a Drupal background...  If an issue has been fixed by the module maintainer, then he/she marks it with a status of "Fixed" see https://www.drupal.org/issue-queue/status#fixed.  After two weeks the issue automatically changes to "Closed (Fixed)" see https://www.drupal.org/issue-queue/status#closed.

Drupal's issue queues are different than Processwire's.  On drupal.org, anybody can change an issue status at anytime.  On github/processwire, only the issue creator or admins can the issue status.

Although 200 open issues seems like a big number, check out https://www.drupal.org/project/drupal ?

Although with Wordpress it's hard to tell what the number is https://core.trac.wordpress.org/tickets/latest

[netcarver]

On 7/24/2018 at 8:32 PM, netcarver said:

IIRC anyone can re-open an issue by simply posting a new entry on it; closure does not necessarily mean an end to a conversation.

I remembered incorrectly! ? The person who initially opened the issue can continue re-open the conversation after closure - but not a 3rd party. So the conversation can't just be picked up re-opened by anyone.

Edited July 27, 2018 by netcarver
Clarification of meaning

[LostKobrakai]

Nobody but maintainers can reopen closed issue, but people can still comment on closed issues, initial opener or not. I cannot confirm that specifically for the processwire repos as I'm a maintainer there, but that's the behaviour I see on other repos on github.

[netcarver]

@LostKobrakai

1 hour ago, LostKobrakai said:

Nobody but maintainers can reopen closed issue, but people can still comment on closed issues, initial opener or not.

I'm probably misunderstanding this then, but here's what I see on issue 514...

Looks like it was re-opened by the initial opener, but my comment on the issue didn't do it.

[matjazp]

Steve, I would like to thank you for your effort on closing stale issues and especially bringing back to life (and to Ryan's attention) those forgotten, but still valid issues, affecting multiple people. Keep up good work!

[teppo]

@netcarver, re-opening issues depends on who closed them. Here's the key part, borrowed from this StackOverflow answer:

• you can re-open your own issues *if you closed them yourself.
• you cannot close or re-open issues opened by someone else.
• you cannot re-open your own issues if a repo collaborator closed them

Also: thanks for your work there – the issues repository is looking much better already ?

[netcarver]

@teppo and @LostKobrakai Thanks for the pointers, that helps clarify things for me. I was under the mistaken impression that anyone adding a comment to a closed issue re-opened it.

@gmclelland Ouch - let's hope we never reach those dizzy heights.

@matjazp Thank you.

Many thanks to everyone who responded to my promptings via github or PM here on the forum - really happy to see there have been 51 fixed or duplicate issues closed in the last week. We're still awaiting resolution on about another 15 that I've posted on, but I hope some of those will be closed this week.

I've been working through some older issues, trying to reproduce them - and I think that we can all help Ryan by trying to do describe the reproduction pathway as clearly as possible (there are issues that are somewhat ambiguous,) and considering if a little screen capture might help.

Also, Tracy has a feature that allows versions, modules and the like all to be dumped in a Markdown-friendly format that can be pasted right into issue reports.

Once the "Copy for Github" button has been pressed, you can simply paste it in at the end of your issue report. Very helpful - and I only found out about it yesterday ?.