Project Issue Lifecycle

[jlaura]

Description
This issue is being generated from a discussion within the ISIS Technical Committee. Specifically, I (we) believe that this project would be well served by having an explicit issue lifecycle document that we used to manage contributor and stakeholder expectations.

This issue is being opened to solicit feedback from all interested parties so that a policy can be developed by the ISIS Technical Committee for this project.

What is this issue attempting to accomplish?

• Promote stakeholder participation by pruning the number of current issues

What is the current state?

• We believe that the project has too many issues that have little to no chance of being addressed for a number of reasons (e.g., the problem no longer exists in the current version, the user that reported is no longer working on a project the issue is impacting due to issue age, the enhancement is now out of scope due to time and project evolution, etc.). We assert that none of these are necessarily inherently negative.
• We do not have a policy document at this point. Having a policy document would be a nice thing to have
• We do not need to be prescriptive of the process, we need a set of guidelines on what/when/how things are pruned

How might we prune issues?

• Reach out to the original poster and ask about the current need (concerns about person-power to accomplish this)
• How do we handle enhancements?
  • Close with a note and then ask the poster to reopen if this is still an issue (enhancements)
• How do we handle bugs?
  • Other communities are +1 on issues that are of interest. We don’t see this. How can we better engage to have stakeholders helping us prioritize issues of importance.
  • A date based flush point is an option
  • A person trying to replicate and then pinging back is an option (significant concerns about person-power to accomplish this)

What is one candidate solution moving forward?

• Go with a date based pruning policy

Open Questions:

• Is this a one time thing? Likely not; a policy on timelines would help with everyone's expectations
• Newer issues are perceived to have higher value by the developers. Is this accurate? If not, how do we engage users to indicate otherwise?
• This isn’t specifically a count issue; this is a resource constraint issue. E.g., the goal is not to say, we will only have X open issues. Instead the goal is promote participation by setting all participant expectations about the likelihood an issue will be addressed.
• We need to engage the users better on enhancement requests to help them define the relative value of the enhancement request. This is a going forward thing. How can we best do this?

[jlaura]

This issue has not seen any action at all, so I am going to propose to move forward with the following with the goal of generating some conversation:

One time cleaning:

• Close all issues (bugs, enhancements, questions, etc.) >= 11 months old.
  • Include a message asking the poster or any watcher to reopen the issue, add a reaction emoji, or comment to have the issue go back to being live. In cases of a bug, we will ask the re-opener to confirm they can reproduce on the current ISIS version.

New Policy:

• Set a maximum duration for any issue at 12 months. This means that an issue that has not had a comment, upvote emoji, related PR, related issue etc. within the past 12 months would be closed. This also means that any issues not bulked closed above in the 11 month age time bracket are up for closing in one month. We can have a bot post a message at some intervals (1 month, 6 months, 11 months, 11.5 months) to prompt for additional comment from the submitter or any watchers.
  • The related issue linkage is important here because it will mean we can have issues that behave more like an epic stay relevant. This is important for larger feature requests that can then be composed of a number of smaller feature requests.

[blandoplanet]

This isn't quite clear to me. Say I put in an enhancement request on Jan. 1. The first point suggests it will automatically be closed on Dec. 1 whether there's activity on it or not. Is that correct? So let's say it closes at 11 months, but I reopen it because I don't think it has been adequately addressed. Does it close again on Jan 31 if no one comments on it?

[michaelaye]

i'm reading the 1st bullet as a 1 time clean-up action and the 2nd as the actual policy? It would clash otherwise, it seems?

[jlaura]

@michaelaye Yes - the first one is a one time thing.

@blandoplanet Apologies that my initial post was unclear. I updated the post based on the questions posed. In your example the enhancement would stay open assuming it had some activity. If it had no activity over the 12 month period it would be closed. The initial cleanup is a onetime thing.

[jessemapel]

This policy seems okay to me. How are we planning to contact reporters for issues that were pre-github? just posting a comment on those github issues will not prompt them with a notification or anything because the bot migrated them. I am open to just expecting our users to be used to looking at github now. I'm not sure how safe that assumption is.

[jlaura]

@jessemapel I am working under the assumption that anyone currently tracking the project will be using GitHub. We made the move long enough ago that I would also expect interested parties to have migrated over to GitHub.

I am also 100% expecting us to have potential duplicative issues after the bulk close in that, we have too many issues currently for any person to manually parse without some real effort. I am hopefully that this closure increases engagement and that with that, we might see issues being generated that had previously been closed. If it works out that way, I would be elated to leave the old issue closed and work on the new one since it is timely given the effort the poster put in.

Given the general positivity towards the proposed, I will get a PR open with a new file, maybe called ISSUE_LIFECYCLE.md.

[AndrewAnnex]

this looks good to me, I strongly recommend to make the bot once the pr with the lifecycle is merged.

[kidpixo]

An useful addiction would be to add a tag like automatically_closed or inactive to have all those issues at glance.

@jlaura hub · an extension to command-line git offer a command like interface to github, issues included.

@jessemapel is right, not everybody is using github, but if this is the official way to interact with the project it is safe (I think).

There are some other possibilities (like dspinellis/git-issue: Git-based decentralized issue management ) but this will increase the overall complexity.

[blandoplanet]

I have some reservations about this, although I understand the desire (perhaps necessity) of letting old issues close. Our current process of support sprints feels more efficient then the previous model; however, there are still only 4 sprints per year, and only so many issues can get worked on. This will mean an issue gets closed if it doesn't get picked up in those four chances (4 strikes and your out). This could be a problem in a system in which more issues are generated then closed. Just because something hasn't been worked on doesn't mean it's not important. Issues can sometimes get passed over during sprints because they were relatively high priority but too complex to start mid-week, or because their advocate was on travel during prioritization. I guess I just worry about important things falling off the table. And yes, I realize issues can be re-opened but, as already discussed, that requires significant user engagement.

Unfortunately I don't have a "better" solution to offer. Perhaps we just need to aware of what will be closing in the next 3 months when we are starting to prioritize issues.

[jlaura]

@blandoplanet I agree that it is concerning that an issue is potentially not addressed in the 12 month cycle given our support cadence. Would it work to:

1. Reverse sort the issues before our internal prioritization meetings and start the discussion with the reverse sorted issues
2. Add a comment or emoji to an issue that might not make the cut but that we know we want to see in the next sprint prioritization meeting. This would reset the counter.
3. Determine some internal process whereby issues that are getting the Ipce #2 treatment do not become the multi-year bug that will never be addressed. I think our own internal planning meetings for what we are going to work on in a sprint might be a great time for this discussion. Something like: "Issue #123435 has been open for Y months and has not percolated to be fixed. Is it still a priority?"

I am with you that this policy is all about addressing expectations and bandwidth. We want to ensure that we are hitting the highest priority needs in a timely way while being responsive to changing needs.

[jlaura]

@AndrewAnnex The bot exists already. It just needs to be turned on.
@kidpixo I like the idea of using the labels to be able to pull these back up quickly via the GitHub interface. Nice call.

[blandoplanet]

@jlaura yes, that sounds like a good approach. I think it just takes us being cognoscente and making sure we have the conversation in your #3.

[lavalaz]

I will say that I have a philosophical issue with making known issues disappear without addressing them. I think it is important that the process have a healthy balance between transparency and efficiency. I recommend that auto-closed issues go in a different, and clearly labeled, category than issues that are actually dealt with. Such a repository can be very useful to a user who encounters an issue and wonders if it is just their own mistake or if this was seen by others. And I imagine it could be useful for developers trying to figure out if a problem is because of a recent change or is something that has been around for years. The earlier post might also look at the same problem from a different perspective, helping to decide between different ways to address the issue.

Sometimes what I say is unclear, so I'll try to repeat myself from a different angle. I laud the attempt to prune the number of active issues to a more reasonable number, both from the perspective of making life more manageable for the developers and providing a more realistic view to the users. I cannot think of a system better than the time-based approach you suggest. However, I think it is essential to not mix issues that have "expired" from issues that are "addressed". Trends in the "expired" issues category could be very important to examine when developing a long-term strategy for ISIS - are there topics we consistently never get to but users keep asking for? Is it clear that basic support is under-funded because this category is growing at a fast rate? Or, to flip it around, it is the best documentation we have that ISIS development is doing well because all the issues in the expired bin have a darn good reason for being there and they should stay there.

I think this is a very verbose thumbs up to @kidpixo 's suggestion.

[jessemapel]

The policy document has been updated and a bot is getting setup. I am going to close this issue. If there are issues with policy that need further discussion then please re-open.