Use label "deferred" instead of closing issues.

[aero31aero]

Hey @ariya I recently noticed that you are now closing most of the newly opened issues saying that if the project revives, they can be revisited later. However, if this project is revived later, it is highly unlikely that someone would go to the trouble of triaging already closed issues for issues that needed revisiting.

It would have been better if GitHub had natively supported a middle ground between open and cloed issues for such a usecase, but in the lack of such a feature, it makes more sense to instead create a new label names "deferred"/"to-revisit" and NOT close the issue so that it remains in the view of someone looking at open issues to solve.

[ariya]

Thanks @aero31aero! Do you have some examples of issues which should be tagged as Deferred?

Note that for a long time we already adopt the policy of not closing an issue if there is a remote chance it might be looked at. This doesn't help. Long story short: issues piling up, people complain even more, nobody volunteers to triage, the cycles continue (see #14541, and perhaps #14548).

Time to experiment with the opposite approach: unless it's actionable (i.e. there is a clear follow-up plan), let's close it. It's easy enough to reopen it if (1) someone cares, or (2) someone else steps up and offers help.

Either approach can't please everyone. But now, let's try an approach that is optimized for the maintainer's time.

[aero31aero]

I'll have to apologize for not being familiar with PhantomJS's codebase- I've only used it as a part of Casper for frontend tests or for playing around with headless browsing and the recent archiving news brought me here.

I'll try to give some examples of issues from the recently closed ones that could be looked at in the future, i.e., are candidates for keeping open:

1. phantomjs: Permission denied shell_exec('phantomjs hi.js 2>&1'); #15337 is a bug report that, if the development continues from the current 'dev' branch, would be relevant. If the development continues from the current stable 2.1 then perhaps not relevant.
2. Problem with build process #15320 points out that build instructions for the current version are outdated. Perhaps a rename of the issue to "Update build instructions for current version" and reopening could be useful as this seems like an easy task for a contributor who regularly builds phantom to update the website/docs regarding this.
3. bug phantomjs in Ubuntu 16.04 #15326 was tagged with "bug" and "confirmed" so it sounds like a TODO for when reviving the project later. This is kind of what I'm talking about. Unless this person reopens the issue or someone else files another issue, this bug report might go unnoticed by someone contributing to the project later.

I believe (and this is my own observation) that closing an issue is akin to permanently hiding it, so even if the number of open issues keeps piling up, its better to have a simple tagging system for the contributors to filter issues by and find something to work on. For example, someone could easily hide all issues labeled 'deferred' when looking for something to work on, and the count of open issues is just a number that is relevant perhaps at a first look only, not in long term contributing.

I would have liked to help triage some issues for you, but I'm unfamiliar with the codebase. I believe there might be others out there who could perhaps at least take up the job of just managing the issues if not managing the code.

[ariya]

Those three issues you mention only applied to version 2.1.3, which is abandoned (not to mention that it was done rather haphazardly, ignoring semantic version, no added tests, zero care for the multi-platform nature, etc). There is no point of revisiting that, see also #15344. If you think that it is not the case, please post your finding directly to each issue and I will take a look, that'll be appreciated.

Of course closing the issue means hiding it. It's just a flag anyway. Any serious contributor can search for issues they want to work on, ignoring this one-bit flag (open vs close). However, the high count of open issues proved to be demotivating for first-time helpers and incite negative drive-by comments. And I said, it's cheap enough to reopen an issue or recreating it.

Again, let's try to optimize things based on the past experience here, not an ideal hypothetical situation. I'm willing to reconsider the approach "keep the issue open" if you can write a more structured summary on the pros and cons, along with the user stories and such, and also based on what has happened in the PhantomJS land.

Take a look at #14543 and #13861 as well.

[behrangsa]

@ariya have you thought about starting an indiegogo campaign to get funds necessary to help with the progression of the project?

The JUnit team managed to raise 50,000 euros to fund development of JUnit 5.

Other potential options are donating the project to Apache, Eclipse, Linux Foundation, or other similar organizations.

[ariya]

@behrangsa To stay on-topic, perhaps add your suggestion to ##13861 instead? Thanks.

[ariya]

Closing this for now, since we're experimenting with reducing maintainer's burden. Thanks!