Repository navigation
GitHub issue tracker cleanup #15593
Replies: 3 comments 7 replies
|
I think this is premature. I just downloaded 3.0a11, and it crashed before I was able to find the settings necessary to reproduce any of the issues this policy aims to close. 3.0 looks like a very significant change (the UI certainly is), but to declare any previously reported issues stale before the new release can stay running long enough to test them doesn't send an affirming message to the community. |
|
It's definitely premature and will just turn issue tracking into a popularity contest instead of allowing issues to actually be fixed. They've stuck a band-aid on a gaping wound and told everyone it will take care of things. I had a very easily reproducible bug moved, because it's a "3.X issue" and therefor moved to a "discussion" instead of having it actually looked at. It was moved by an employee not by a bot. It's a broken system and a great way for them to drop things into the "too hard" basket and not fix actual issues. |
|
Speaking from a lot of OSS experience, I understand the intent. The time to announce the policy is with the alpha. The time to implement & enforce the policy is with the stable release. |
|
what about "issues" that nobody ever looked at and labeled properly as feature requests? I have two feature requests open since November 2023 which have both never been labeled as feature requests. |
is there a way to transform the old issues to feature requests in discussions or does this need to be done manually? |
|
I've seen @HurkaF do this with recently filed issues, so it's possible, but potentially only by folks with admin privs in this repository. |
|
So check if the feature is still not implemented, if not: open a new discussion, refer the issue in it, then close the latter. |
|
From what I've found, users without elevated permissions unfortunately can't move issues to Discussions, even as the author. So the best approach would be the one @m-u-xyz suggested: check whether the feature still isn't implemented, and if so, open a new discussion, reference the original issue in it, and then close the issue. |
|
shame a bot with the required perms that allows authors to self convert to a discussion with a comment trigger isnt an option |
Uh oh!
There was an error while loading. Please reload this page.
PrusaSlicer project now has a new policy for the GitHub issue tracker. It can be summarized as: Anything that is not a reproducible bug should be a discussion. To learn more about the rationale behind this policy, read the original GitHub discussions announcement.
We won't be able to manually go through the issues and decide what the best course of action is for every single one. We simply do not have the manpower to do that. Consequently, we would like to ask for your help. If you could proactively close your bug unrelated issues in the issue tracker and open them in discussions, it would greatly simplify the whole process for us.
To further aid us with the goal of moving any no bug related issues to discussions and cleaning up obsolete issues, we are employing an automated bot. It is fully written by us, solely for this purpose. This bot will label all issues created before the release of PrusaSlicer 3.0 alpha as legacy. Furthermore, for each issue it will dispatch a warning, that the issue will be automatically closed if no action is taken. Finally, it will close any inactive issues.
What does this mean for your issue
It means one of these 4 outcomes:
The aim is not to close relevant issues. We still care about your feedback, we just need to categorize it better. Please help us with the transition, by actively moving your issues to discussions if applicable.
All reactions