Skip to content
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

Closed

Conversation

carlosalberto
Copy link
Contributor

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.

@carlosalberto carlosalberto requested review from a team August 30, 2021 14:49
Comment on lines +74 to +75
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.
Copy link
Member

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?

Suggested change
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.

Copy link
Contributor Author

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 ;)

Copy link
Member

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.

@Oberon00
Copy link
Member

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".

Comment on lines +74 to +79
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.
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@carlosalberto Makes sense.

Copy link
Contributor

@iNikem iNikem left a 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
Copy link
Contributor

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.

Copy link
Member

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.

Copy link
Member

@bogdandrutu bogdandrutu left a 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

@carlosalberto
Copy link
Contributor Author

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.

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.

@carlosalberto
Copy link
Contributor Author

Based on @yurishkuro we could also add a roadmap or keep_open tag that would prevent auto-closing issues, if this is supported by a given SIG.

@iNikem
Copy link
Contributor

iNikem commented Sep 13, 2021

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.

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.

Then I agree with #1897 (comment)

@github-actions
Copy link

This PR was marked stale due to lack of activity. It will be closed in 7 days.

@github-actions github-actions bot added the Stale label Sep 21, 2021
@github-actions
Copy link

Closed as inactive. Feel free to reopen if this PR is still being worked on.

@github-actions github-actions bot closed this Sep 29, 2021
@carlosalberto carlosalberto reopened this Sep 29, 2021
@github-actions
Copy link

github-actions bot commented Oct 7, 2021

Closed as inactive. Feel free to reopen if this PR is still being worked on.

@github-actions github-actions bot closed this Oct 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use a common policy for marking issues/pull requests stale
7 participants