mirror of
https://github.com/semver/semver.git
synced 2026-07-11 03:53:53 -05:00
[GH-ISSUE #572] REDACTED #4661
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#4661
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jeme on GitHub (Jun 10, 2020).
Original GitHub issue: https://github.com/semver/semver/issues/572
@ljharb commented on GitHub (Jun 10, 2020):
Please don't do that; programmatically closing issues is very user-hostile, and very few issues become less relevant with time.
@jwdonahue commented on GitHub (Jun 10, 2020):
Question threads that have been tagged as answered, where the OP had not responded for months or years, should be closed. Whether that is done manually or by automation is not relevant, provided it is done correctly in either case.
@jwdonahue commented on GitHub (Jun 10, 2020):
One of the real problems here is that GitHub doesn't provide finer grained control of privileges. You can't give tagging privileges to someone without also giving them the keys to the entire kingdom (write access to the repo). If there was a tool that could be configured to recognize some form of tag format in the comment text, and it could be configured to process only tags from a restricted list of users, I would vote for the use of that tool. Someone could tag the thread, giving the OP some warning, then 10 days later the bot comes through and closes them.
@ljharb commented on GitHub (Jun 10, 2020):
I find it highly relevant. Closing things manually - ideally with a handcrafted, not a canned, comment - is kind, and it's more important to be kind than it is to reduce the open issue count.
@jwdonahue commented on GitHub (Jun 10, 2020):
Like I said, it would have to be done correctly. If a human has commented and tagged the thread and there is a grace period, I think that would be awesome.
But yes, I agree with your sentiments regarding kindness.
@jwdonahue commented on GitHub (Jun 10, 2020):
I would also point out that a SemVer 3.0.0 is not anywhere on the near horizon at this point and a lot of the proposals, would require a major version bump of the spec. Those could be tagged for revival later, when there is a plan in place to develop v3.
I basically love tags and automation for this kind of work. Keeping the open issues list down to a workable set is the best way to help get traction on the issues that can be resolved without a major version bump. Provided the automation is a human assistant and not the other way around of course.
@ljharb commented on GitHub (Jun 11, 2020):
I think a bot to mark issues as stale is fine - I’m objecting to a non-human closing issues, specifically.
@FichteFoll commented on GitHub (Jun 11, 2020):
Github added the "Triage" access level some time last year, iirc, which allows exactly for what would be needed: managing issues without write access to the repository.