-
Notifications
You must be signed in to change notification settings - Fork 891
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
Define minimum stale time for issues/PRs in SIGs #1897
Conversation
Issues with no activity during 1 year can be considered stale | ||
and can be closed. However, SIGs are free to use a longer period of time. |
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.
closed immediately or marked stale first?
Issues with no activity during 1 year can be considered stale | |
and can be closed. However, SIGs are free to use a longer period of time. | |
Issues with no activity during 1 year can be marked stale and can be closed | |
7 days later. However, SIGs are free to use a longer period of time. |
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.
I'd vow for closing them immediately. 1 year is rather enough time to be able to forget about them ;)
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.
Marking issue stale is a form of notification to people, who can react to it, come back and say "I'm still interested", which could signal the bot to remove stale marker. They technically can reply to a closed issue, but that won't reopen / extend the issue without manual intervention from repo owners (who can always close manually if necessary).
I personally don't find it that useful to auto-close issues in the first place. Closing PRs makes sense because they rot much faster, but an issue might record just an idea on the roadmap, or even some registry like jaegertracing/jaeger#638. So if we introduce auto-close for issues I think it must be accompanied by a tagging mechanism that exempts certain issues from auto-close, like roadmap
or keep_open
labels.
My unqualified opinion as an "armchair (non-)maintainer": I think old issues should not automatically be closed. This creates an incentive to let issues rot to let them resolve itself. If a SIG is overwhelmed with the amount of issues, they can always manually sort by "updated by" and close out old issues on demand. I don't think a fixed age is the best policy for that, but rather something like "if we have more than 200 open issues we will close all issues that were created before the release of 1.3 except marked as important". |
Issues with no activity during 1 year can be considered stale | ||
and can be closed. However, SIGs are free to use a longer period of time. | ||
|
||
Pull requests with no activity during 7 days can be marked stale, | ||
and they should stay at least 7 days as stale before they can be closed. | ||
Similarly to issues, SIGs are free to use longer periods of time. |
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.
However, SIGs are free to use a longer period of time.
Similarly to issues, SIGs are free to use longer periods of time.
I think this should rather be defined in the repo guidelines in https://github.com/open-telemetry/community.
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.
We already have a lot regarding issues in this section - we can try to move it out in a follow up, however.
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.
@carlosalberto Makes sense.
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.
I agree on the part about PRs, assuming that our goal is to have enough time for all interested parties to participate in PRs.
I don't understand the part about issues. What is the goal of this 1 year period? IMO maintainers should be free to close issues whenever they want. And I don't see any benefit in auto-closing.
@@ -71,6 +71,13 @@ action, please provide the rationale for closing, and indicate that OP can | |||
re-open for discussion if there are additional info, justification and | |||
questions. | |||
|
|||
Issues with no activity during 1 year can be considered stale |
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.
Does this mean that maintainers are not allowed to close issues faster? Regardless of the activity.
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.
This is only about closing due to it being stale. If the issue has been sufficiently addressed it can be closed anyway regardless of this.
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 overall, regarding where this should be can be in the repo setup process steps
This is mostly about auto-closing issues (that have had no activity in long time, hence considered stale), if that is supported by a specific SIG. Because of this, we have the "minimum" timeline. If that makes sense, I can clarify the wording. |
Based on @yurishkuro we could also add a |
Then I agree with #1897 (comment) |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
Fixes open-telemetry/sig-contributor-experience#26
Initial proposal to define 1 year as a minimum period of time before a issue without activity can be closed; use the 7 days stale, 7 days closed policy for PRs, as currently done in the Specification.