mirror of
https://github.com/semver/semver.git
synced 2026-07-11 08:02:23 -05:00
[GH-ISSUE #413] Issue tracking conventions at semver/semver #2040
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#2040
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 @jwdonahue on GitHub (Nov 29, 2017).
Original GitHub issue: https://github.com/semver/semver/issues/413
Are there any written conventions regarding what issues should be tracked and when they should be closed?
I have been reviewing open issues here for a good part of the last few days and have observed that many of them are well past due for closure. In my opinion, if there is nothing to fix in the SemVer spec or this GitHub project site, and there is no current controversy in active discussion, it should be closed so that those of us who are looking for a way to contribute, can find open and actionable work items without having to wade through over a hundred un-actionable open items. If someone wants to come along and add comments to closed items, let them do so, or re-open it?
Any thoughts from the semver illuminati?
#362
@jwdonahue commented on GitHub (Nov 29, 2017):
#362 is an example of just one of the many issues that were started here in order to present ideas regarding best practices. It's an interesting idea that I think might deserve a link from the new Wiki page I started (WIP), or perhaps it warrants its own wiki page?
I've been talking a lot lately about how we need to formally link SemVer with the rest of the web of best practices and alternative versioning schemes without cluttering up the SemVer standard document. This is one place I've been going with that.
@jwdonahue commented on GitHub (Nov 29, 2017):
StackOverflow has a semantic-versioning tag that has been used 251 times since 2012/02. We're a small community so we might not warrant a SemVerExchange, but it still might be worth investigating in support of the many question issues that come along?
@FichteFoll commented on GitHub (Nov 30, 2017):
Imo issues should be closed once either a question has been answered, a proposal has been declined or implemented, or the author doesn't expect meaningful answers anymore. This has generally been the procedure over the past years and I think it works quite well overall.
The only thing "missing" here is a reminder for the issue author to consider whether he does or doesn't expect any more answers (by my last point), as you have sucessfully been doing over the past days.
@jwdonahue commented on GitHub (Dec 13, 2017):
Ok, so it seems I've been pushing for issue closure at about the right pace so far as I can tell. Had some push-back here and there, some of it really justified, but mostly getting voluntary closure, which is a good thing. Low hanging fruit is maybe 60% taken care of. Now I think we need some labels to tag what is left, but that's another issue...