Improve process of reporting and resolving Github issues

[serathius]

Looking for recent issues reported to Etcd repo I have noticed that there are multiple potential improvements that we could make to make the process more efficient and less straining for maintainers.

Some of the problems I have noticed:

• Lack of basic context in bug reports, things like etcd version, reproduction steps etcd. Thus generates unnecessary work on contributors to get this information from reporter. It should be clear what information is needed for a bug.
• Lack of next action items resulting in issues closed by bot due to inactivity. It should be clear whether issue was accepted and is worked on or we are waiting for more evidence.
• Very long resolution time for critical issues. For example it took quarter to resolve critical v3.5 bugs. We cannot honestly recommend using latest release if we are aware of critical bugs and cannot timely resolve them. It should be clear for contributors which issues should be focused on.
• Limited maintainer responsiveness. As time passes and personal/work priorities shift it can be harder and harder to maintain activity especially in open source. I just wanted to note this has become a bottleneck, and we need to find a way to work around limited maintainer time.

Goals:

• Reduce a strain on Etcd maintainers by shifting work to reporters, contributors and reviewers.
• Make the PR/issue triage/resolve process consistent and transparent.

Ideas:

• Create a set of issue templates that would let reporter know what information is required from them. We should also agree and clearly communicate that issues that don't fill nesesery information will be closed. Github - Creating issue forms
• Document a issue triage process, that would clearly specify what stages issue can be (New -> Accepted/Needs More Evidence -> Help Needed -> Assigned -> Closed). Main difference we would introduce would be by introducing Accepted state, which means that a trusted contributor has looked into it, reproduced it and confirmed that it needs to be fixed.
• Introduce a consistent and clearly defined priorities. Currently priorities are used in very limited way. To improve this we need to properly document their meaning so they can be effectively applied by non-maintainers.
• Introduce more roles for Etcd contributors and document a clear set of responsibilities and requirements. Current contributor structure doesn't scale. This was somewhat improvement by recent introduction reviewers, however we need to invest more into documentation and growth to get proper benefits.
• Separate PR review from approval process. Current PR process is slow as every stage requires a maintainer assistance. From enabling running tests, to reviewing and merging. To reduce maintainer load I would propose to delegate most of the process to reviewers, with maintainers only required at the last stage of approve/merge.

There are just couple of high level ideas that I would want to get some feedback from community. Please feel free to propose other problems you noticed and ideas for solving them. I think we can really improve the contribution process and grow Etcd community if we worked together.
cc @ptabor @spzala @hexfusion @wenjiaswe

[jmhbnz]

Updating this stage/tracked issue to reflect progress on some items:

Create a set of issue templates that would let reporter know what information is required from them. We should also agree and clearly communicate that issues that don't fill nesesery information will be closed. Github - Creating issue forms

• We have now strengthened our bug reporting templates to include a clear checklist in 16003 and also setup a process for converting incomplete or incorrectly filed issues to github discussions in 15957.

Document a issue triage process, that would clearly specify what stages issue can be (New -> Accepted/Needs More Evidence -> Help Needed -> Assigned -> Closed). Main difference we would introduce would be by introducing Accepted state, which means that a trusted contributor has looked into it, reproduced it and confirmed that it needs to be fixed.

• We have made some good progress on defining issue triage under Initial re-write for contributor issue triage guide #15881.

Introduce a consistent and clearly defined priorities. Currently priorities are used in very limited way. To improve this we need to properly document their meaning so they can be effectively applied by non-maintainers.

• This still needs to be done. I am tracking this work under Refreshing issue triage for etcd #15773

Introduce more roles for Etcd contributors and document a clear set of responsibilities and requirements. Current contributor structure doesn't scale. This was somewhat improvement by recent introduction reviewers, however we need to invest more into documentation and growth to get proper benefits.

• Think we have made some progress on this recently with Move to community membership model closer to kubernetes one #15593 and the addition of recent etcd members and reviewers with clear responsibilities.

Separate PR review from approval process. Current PR process is slow as every stage requires a maintainer assistance. From enabling running tests, to reviewing and merging. To reduce maintainer load I would propose to delegate most of the process to reviewers, with maintainers only required at the last stage of approve/merge.

• Agree that we need more autonomy for reviewers to enable running tests, this is something we can pursue once we have kubernetes ci infrastructure hooked up and can leverage some prow bot automation. We recently added another reviewer which should hopefully reduce some workload for maintainers.
  Update: We now have the ability to trigger and restart prow or actions jobs with k8s ci robot.