This repository has been archived by the owner on May 30, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New policy: auto-close stale issues #15395
Labels
Comments
ariya
added a commit
that referenced
this issue
Dec 25, 2019
ariya
added a commit
that referenced
this issue
Dec 29, 2019
This was referenced Dec 29, 2019
Closed
This was referenced Dec 30, 2019
Closed
Closed
ariya
added a commit
that referenced
this issue
Dec 31, 2019
Working as expected. |
I do understand the lack of contributers and issue piling up causing demotivation for the team or contributors, but auto-closing 1000+ items without reading them and determining priorities first ?! We often check the number of opened issues before choosing an open source solution and here the number won't be representative anymore .. Had opened #14445 in the past and had no workaround at the time. Only workaround we finally found was to change to Chrome's recent Headless mode .. |
Repository owner
locked as resolved and limited conversation to collaborators
Jan 9, 2020
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
As hinted already in the previous discussion (#15349), I want to formalize the experiment with the new policy: stale issues will be automatically closed. The closing will be automatically carried out by Stale bot.
Rationale: as long as the maintenance capacity is far beyond the demand (please read #14541) and there is not enough volunteers (#13861), the issues will continue to pile up. When that happens, it is demotivating for the team and for the potential contributors, not to mention the occassional uncalled-for drive-by comments.
What is the definition of stale? For our purpose, it means the lack of all these 3 things (as also stated in Reporting an Issue:
The last one is important and yet it is often overlooked. It is not practical for the team behind PhantomJS to try to reduce the generic problem "PhantomJS does not work X" and to pinpoint it a very specific root cause (e.g. the website uses ES2017 features not supported yet by PhantomJS). Of course we do not expect a very detailed root cause analysis, however any meaningful initial steps in that direction will be immensely helpful. The WebKit project also has an explanation about this, read Test Case Reduction for more details.
I believe the above policy will help the triaging process and to make the whole issue handling slightly more humanly bearable.
The text was updated successfully, but these errors were encountered: