Communicating maintenance capacity and prioritization

[ariya]

So far we have not been doing a great job at communicating the current state of maintenance. This is a discussion to find a better way of achieving that.

The team behind PhantomJS (@ariya @vitallium @zackw and other occasional contributors) is committed, yet we remain a small team. None of us is paid to work on PhantomJS, thus we carry out the contribution during our spare time. For the sake of discussion, let's say that our estimated total effort is 4 hours/week.

Meanwhile, the users of PhantomJS continue to grow and the demand keeps increasing. Every user wants the latest updated WebKit, full ES6 support, and zero crash. In theory, to moderately keep up with this demand, it requires at least one full-time sofware engineer, an equivalent of 40 hours/week of work.

The impact of our limited maintenance capacity is that the progress pales in comparison to the skyrocketing user demand.

Issues are piling up in the issue tracker because the triaging rate is much lower than the reporting rate. Triaging is not difficult (see #13861) but it takes a lot of time and yet there is very little external help.

When an issue is not being looked at, users affected by the issue become disappointed (see the most recent example #12750). Given the limited maintenance capacity, prioritization is inevitable. Sadly, that perspective is not taken into account by the users and the message comes across the wrong way.

We are still happily making progress, and we do not plan to stop anytime soon. In some cases, our progress is judged by the commit statistics which (in the case of this project) unfortunately do not correlate with the effort (we often worked on a big 100-hour task that resulted in just one git commit). And when an user is not feeling the progress because our current focus does not overlap with their needs, it triggers a sweeping generalization that there is no progress at all.

What is the best way to ensure that every user is aware of this mismatched capacity vs demand?

Suggestions are welcomed!

[annulen]

Some thoughts:

• It may be a good idea to start crowdfunding campaign with goal of fixing most prominent bugs, and hire developer for this money. Users who pledged more money can select more issues for priority fix
• Promote self-service as the best way to get issues fixed timely. Maybe more developer documentation is required to lower barrier of entry
• https://www.bountysource.com - if someone cannot self-service, there may be someone else to earn a little money on it

[thoop]

Issues are piling up in the issue tracker because the triaging rate is much lower than the reporting rate

How can we, as a community, help on the issues side of things? I'd love to help in the very small amount of free time I have, but I feel as if the barrier to entry is high just for curating issues.

I know you mention #13861 but your suggestions there don't seem like they would be helpful besides on a few popular issues.

PhantomJS has a high surface area since it can be used with nodejs, webdriver, ghostdriver, selenium, etc. And that's not even mentioning all of the different browser features supported by PhantomJS/Qt, operating systems used, etc. That makes it hard to know what to prioritize, what is actually an issue with PhantomJS and not an upstream or downstream dependency, or even validate a reproducible test case.

That being said, I think it would be great if we could do those things for the contributors and free up your time for other things. How can we enable that, or reduce the barrier to entry on curating issues in general?

[gsouf]

@ariya I would like to mention #13797 in which there is 0 output from the team. This issue is very ennoying because it's written in the doc but it does not seem to work and it looks like the team is not even aware about it. That's a factor of frustration. A good thing would at least to notice the users that you are aware of it, and give some clue about an eventual fix (or no fix) like "okay, we will fix this soon" or "hard to fix for the moment, we need design decision"

[ariya]

@annulen All good suggestions, thank you! It doesn't seem likely that I personally have time to do any of these 3 steps, but the very least, I do plan to improve the state of the documentation (both for end-users and future contributors).

[ariya]

@thoop Should we have a flowchart on issue triaging? I can write down something on the wiki and we can iterate from there.

[ariya]

@gsouf You're describing the precise problem that we're facing (in your own words). The team does not have a chance to be aware of every single issue because we tackle 2 issues/day while we have 10 new issues/day being reported.
If you are in that situation, what would you do differently instead?

[gsouf]

@ariya I dont know what I would do, that's why you started a few issues related to this in order to find solutions!

[thoop]

I think improving documentation is always a good thing, but I don't know how much a flowchart would help besides superficial issues.

I think zackw was doing lots of issue triaging for a while, right? I don't know what all they were doing, but did it help with your availability to do other things? I remember seeing lots more labels on issues than I see now.

Maybe I can jump in and just try to start commenting on issues and report back with any ideas on how it would be easier to get others to do the same in the future?

[gsouf]

I think that if you dont have enough time to look at all issues, a first step should be to find some people to help to label issues, answer question issues and close undesired issues. That would already help for a lot of issues

[ariya]

@gsouf If you have a concrete idea on how to find those people, please chime in at #14543.