Issue lifecycle management

[SimiHunjan]

I'd like to open a discussion around defining an approach to issue management — specifically, how we handle the full lifecycle of an issue from creation to closure so it is transparent to the community.

This should aim to define the following:

• Standard process once an issue is created (whether maintainer/contributor)
• By when should maintainers of the project respond to an open issue (if opened by the community and not themselves)
• What criteria do we use to close an issue. Does the maintainer close issues and if so what are the requirements to close an issue i.e. the author of the issue validated the fix, stale issue over x days, or can be the person who opened the issue, etc
• How to handle non-actionable or low-quality issues
• When should an issue be reopened

[exploreriii]

Thanks - great to get this clarified as the projects and diversity grows.

Some ideas to get the conversation going:

Issue creation

• Label the issue (bug, documentation).
• Encourage detailed descriptions (use-case, importance, how to) if known. A description would help the devs can assess the priority and resources to allocate to the issue.
• Encourage further discussion on e.g. discord to learn more about the issue.

Issue response

• Encourage 'acknowledged' or 'seen' neutral responses
• Encourage community members to label / refine / ask clarifying questions and refine issues
• Encourage quick user assignment/volunteer, which also means you are not interested or available if not assigned/volunteered
• If many maintainers are volunteers, 2 week time-frame response is OK and within 2 weeks is a good goal
• If issue is important and urgent, below 1 week time frame is expected. Some go-to contact service might be needed.

Issue development

• Encourage simple status updates if long-time frame has passed
• Encourage communicating in e.g. discord

Issue resolution

• Issue opener can also close. That's ideal.
• Issue can be closed by maintainers with resolved PR and a couple days wait time or merge approval from creator or discussion.
• Issue can be closed due to duplicate, stale (60+days) or out of scope issues with a reason

Issue reopen

• Historical issues that need to live again e.g. due to bug and cannot do so as a new issue
• New issues on similar vein that really need old context
• Generally, better to open a new issue with reference to old if beneficial

Issue Quality

• Encourage 'acknowledged' or 'seen' neutral responses
• Encourage community members to label / refine / ask clarifying questions
• Encourage clarifying interest / assigning members
• If this occurs but they go stale, can close with description.
• Provide a code of conduct

[SimiHunjan]

Thank you for the suggestions. Will give a review and continue building from here.

[jwagantall]

@SimiHunjan , I want to follow up on this topic. Were you planning on writing any guidelines on this?
Do we need guidelines or can we leave it to the maintainers of the repos to manage their issues as best they can? I would assume each team works at a different rate so they might have their own way of administrating issues.