Close stale feature requests #9182
Conversation
|
There are issues/bugs and feature requests opened for years. That is actually quite common in php-src bugs.php.net. Closing the feature requests will only cause:
So my question is, what objectives does this PR address and if they strongly balance out these negatives. |
Right. And how many of these feature requests will be implemented? Maybe around 50% percent, if we wait for a thousand years. Within a more realistic timeframe (say 10 years), probably less than 10% of feature request will be implemented. And after 10 years, does the FR even make sense? Most feature requests are, unfortunately, dead weight. |
I don't understand how this is a good thing. Yes, closing issues doesn't solve them but neither does leaving them open for eternity. The point is that our resources are limited and even if they weren't nobody is obligated to work on the feature requests. We are somewhat obligated to look at bugs so they are a clear priority for us.
We don't lock issues, we're also not stubborn not to re-open issues if there's feedback and progress being made. The purpose of this is to close stale issues where no progress is being made at all.
You have not tried to think about the positives at all 🙂 We're trying to decrease maintenance burden and make good use of the resources we have. Somebody periodically having to go through issues to close them is just not time spent productively. Auto-closing issues means we'll automatically know what's important for users (because discussion is ongoing) and what is not. |
|
No, I tried, but I hate the negatives. Closing any valid FT is also disrespectful to the submitter. If someone wants to list bugs only, he can easily label filter them. |
Are you suggesting that we ignore feature requests altogether? What would be the purpose of having them then, instead of closing them right away? |
|
I am pointing facts. Valid feature requests should not be closed automatically. Some of them cannot be even implemented in 90 days :) One example: Imagine some major feature like overloaded object operators or generics. If such features will be marked (correctly) as "Feature", such features will be (wrongly) closed because of this change. So closing any feature is simply wrong. If the objective is to reduce the opened FR count, I propose: a) ask the user once if the FR is still valid and he want to pursue it |
|
While I generally dislike stale bots for the reasons Michael has given, in this specific case of PHP feature requests are either trivial (and thus can be implemented in the mentioned timeframe) or non-trivial (and thus require an RFC; moving them out of the tracker onto the list). So consider this a small +1 for merging this PR. |
|
I think it's a good move, as someone that spend a tiresome amount of time on the old bug tracker, it was littered with feature requests dating back from 2001. I don't think the sentiment here is to prevent those feature requests from coming in, especially the smaller and more trivial ones, but once it goes beyond that, like above mentioned genetics, then quite frankly they belong on the mailing lists which still is our official communication platform for language development. I would categorize anything that requires an RFC to be moved to the mailing list instead even. |
That's exactly the kind of feature request we don't want a GitHub issue for. It's an terrible medium for discussion. These kinds of threads usually end with endless repeating comments, lost important information and general dissatisfaction on both sides. For complex RFCs it's IMO much more helpful to have a dedicated repository with separate issues, e.g. https://github.com/Crell/enum-comparison/issues.
That's essentially what this bot is doing, just automated. Issues are closed after 90 (97 technically) days of inactivity, not days period. Once anybody comments the stale label is removed and the issue will stay open for another 90 days.
Smaller feature requests are much more likely to actually be implemented, so they are much more helpful than big ones. |
|
I don't this this is a good idea. 90 days is way to short time to handle feature requests so it should be at least 1 year IMHO. But even that I don't think is a good idea as it might close some features that are desirable for community - especially those that have lots of 👍 . For example for FPM there are lots of good ideas in bug tracker. The fact that some of them are there for years is not such a big problem as we still talk about manageable number and it shows to community that PHP core needs more resources to handle those. In addition some of those are very good first issues to handle for new developers wanting to contribute to PHP but not having any idea what's needed. |
|
@bukka Thanks for your feedback.
Note that issues are closed after 90 days of inactivity. I think it's reasonable to expect desired features to have more activity than 1 comment every 3 months.
We could add a
Hm, the number of open bugs on bugs.php.net is everything but manageable IMO (72'000). |
Does this count upvoting using 👍 ? That's what most people would do if they find it useful. I still think that this should be the same as minor version release duration. For example I often don't care much about new feature until it's close to feature freeze. I think there is not much harm to leave it a bit longer.
This is a good idea and I would go a bit further and not apply to any extension, SAPI and streams as those are actually the ones that are usually useful. It should be really decided by maintainer or someone knowledgeable of the particular area. Remember that most of those features do not require RFC. I actually agree that for language feature requests, this could be auto closed as those often require RFC.
Sorry I should have been more clear as I had in mind just extensions and SAPI's where package specific issues don't usually go over 200 (mostly up to 100) which includes bugs as well so there are not that many feature requests that it wouldn't be manageable. |
|
I'm open to only closing |
|
Consider #7900. It illustrates the classification between a bug and a feature is not enought to determine if an issue is to be closed soon or kept open for higher attention. It also illustrates, the 90 days period would fail and close issue IMO not intended to be closed. Is 1 year enough? 2 years? IDK. I went thru the opened issues https://github.com/php/php-src/issues and some should/can be closed, but some definitely not. As long as the classification rules cannot exclude legit issues with at least 80, 90% accuracy, no rules should be applied. The The IMHO the closing cannot be automatized and should be done by a person. |
|
I restricted this to |
|
Please add at least some label like Maybe a solution could be to not post any message, but instead add a label after 90 days and after another 90 days autoclose such issue. And when reopened, the label should be automatically removed. |
That's what this bot is doing. See how it already works for PRs.
IMO that would be worse from a user perspective. At least with a message I have the option to take action to prevent the issue from closing.
AFAIK this is also already the case. |
|
@iluuu1994 7 days is a bit too little, I'd change this to 14, and without message there is no notification (at least I didn't remember getting any). |
|
@KapitanOczywisty Which issue was yours? There was a bug when processing the first batch where no text was added, but that batch only contained one issue, namely #8296 (comment). It should work now. I'm happy bumping the reaction time to 14 days. |
|
Yes, That one, it wasn't mine and I wasn't involved, but I've been notified only when it was closed, so it would be too late to react. Just being proactive here. |
|
@KapitanOczywisty Done in 8438ad6 (and 2650340 because I'm a dumb-ass). |
@cmb69 As discussed a while back. If there's no activity in a feature request for 90 days it's very unlikely to get picked up after that. If there is in fact still interest the message could actually aid in making it happen as it serves as a reminder.