-
Notifications
You must be signed in to change notification settings - Fork 9.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial re-write for contributor issue triage guide #15881
Conversation
|
||
Sometime issues are reported that actually belongs to other projects that `etcd` use. For example, `grpc` or `golang` issues. Such issues should be addressed by asking reporter to open issues in appropriate other project. | ||
|
||
These issues can generally be closed unless a maintainer and issue reporter see a need to keep it open for tracking purpose. If you have triage permissions please close it, alternatively mention the @etcd-io/members group to request a member with triage access close the issue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what about adding label named by area/external? The dependency bug can cause unexpected behavior in etcd. Marked it external might help to track.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense to me - Added area/external
. Gives us a way to recognise over time if there are common types of issues that are being raised against etcd that are external so we can do something more about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will need a maintainer to create the new label if they agree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems not necessary, because eventually one of etcd area/component (e.g. etcdserver, etcdctl, etc) will run into issue. But I have no objection to add one more label area/external
. Leave it to @serathius to decide.
9dbacd8
to
e1e0b63
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
3f3773f
to
1cd3531
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a good base that we can iterate on.
dc8fa8c
to
dcb82b6
Compare
Signed-off-by: James Blair <mail@jamesblair.net>
dcb82b6
to
941d760
Compare
|
||
Refer to [etcd community membership](https://github.com/etcd-io/etcd/blob/main/Documentation/contributor-guide/community-membership.md) for guidance on becoming and etcd project member or reviewer. | ||
|
||
## Step 1 - Find an issue to triage |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
idea: have a #triage-wanted label that maintainers can put to delegate triage to members. I assume maintainers skim through new incoming issues. This label will give signal boost. Ideally all issues should be triaged but I don't think that's happening.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm I see what you mean, though my thinking is that these guidelines are to help all us new members triage in a useful way with full autonomy, i.e. without needing maintainers to do anything at all to prod us. I think we are already starting to do that.
Maybe we could re-evaluate in a month or two after these merge and if there are issues still going without triage for too long then we could add a way for maintainers to prod / suggest we triage?
Some other projects namely kubernetes also by default add labels for needing triage to all new issues, but I think that is less useful on etcd where we don't have any bot automation and there is less volume of issues.
Curious what others think, if more folks want to add it straight away I will update and add a section for it.
Thanks @jmhbnz . Overall looks good to me with a couple of minor comments. One more general comment, it seems that step 3 ~ 6 belong to one step with a couple of sub-sections: Apply appropriate labels
|
@jmhbnz Please let me know if you want to discuss or address the comment separately. If YES, I can merge the PR now. |
Hey @ahrtr - I'm going to be following up with some later changes to tackle things like the prioritization section so I don't mind merging this first iteration as is. With the help of all the feedback above I think we have it in pretty decent shape. I'll have a think about your feedback on number of steps and have a tinker with that layout when I add the priority instructions :) |
This pull request proposes a significant re-write of our existing etcd issue triage guidelines.
The purpose of the re-write is to make the guidelines into a more step by step process with clearer descriptions of the actual actions expected to be taken.
Additionally these new guidelines align closer to the style of kubernetes issue triage guidelines and now take into account our new etcd community membership model.
The expected outcome is that these new guidelines will be easier for contributors to follow and will hopefully empower our new @etcd-io/members to be active with triage, which should reduce burden on maintainers and help support a healthy project.
Relates to #15773
Note for reviewers: There are a couple of areas namely area labels and prioritization that I am still working on and will be proposing additional changes for in future, I just wanted to get this initial re-write out of the way first so the pr doesn't become too much to review at once.