By "support", I mean anything where you're asking the upstream to spend time working with you on something. That includes bug reports, feature requests, revisions / pull requests, help with setup, IRC, etc.
We've grown to a scale where our current approach to free support isn't working very well anymore. We're going to make some changes, but don't have a great pathway forward. Since users on this install are among those most directly impacted, I figured I'd see if anyone has any useful feedback or ideas.
Currently, our support approach is mostly based around IRC and Maniphest. We try to get bug reports and feature requests into Maniphest, and funnel users to IRC for other issues. I think some of the problems we're seeing are:
- IRC is presented as a primary support channel, but is a bad UX.
- Many user problems don't help the upstream improve Phabricator anymore (e.g., one-offs, not real bugs).
- Many Europe/Asia users show up at times when no one is active.
- Many other questions are too complicated for the community to answer out of the goodness of their hearts (e.g., hour-long fishing expedition).
- Major issue: we (and docs) say go here to get support; you usually don't get any.
- Maniphest is often a bad UX.
- Users with the most free time have the loudest voices.
- Some users feel snubbed by an adversarial upstream if we don't spend enough time on an issue.
- Some of the discussion is very low-value ("what's the status on this?").
- Basically no luck documenting our way out of any of this.
- No immediate incentive for users to read the documentation or craft good reports.
I think there are three sort of core problems here:
- Bad IRC expectations: We tell people to go to IRC, where they don't get support. We should set expectations better.
- Time Consuming for Upstream: We spend a ton of time on support, but it has much less impact on making Phabricator better or helping users than spending that time on development. This is really frustrating for us.
- Emotionally Negative for Users: Some users feel rejected if we don't spend enough time helping them or can't prioritize their issues. This can be really frustrating for users.
These problems all have straightforward solutions individually, but they interact with each other in complicated ways.
For IRC, I think we're pretty clearly going to drop it as a primary support channel. There's no real way to give Europe/Asian users a good experience with an unlogged medium with a relatively high barrier to entry. However, it would be nice to replace it with something else instead of just saying "no support".
Reducing the time the upstream spends on issues is ideally an issue of improving issue quality: the top, say, 20% of issues are hugely valuable for us, it's just the other 80% that get less and less valuable down to the point where they're starting to take up way more of our time than they can ever repay. This seems hard. One problem is maintaining fairness, or an illusion of fairness (see below). We can also just shut down channels, but then we'll be throwing good reports away too. Literally spending less time on issues (i.e., rejecting them more abruptly) makes the experience more negative for users.
User emotions are probably the least straightforward. Ideally, we'd spend all the time required to resolve each problem, but this is obviously not possible (even if we had the time for it, many requests are contradictory or impossible), and we want to reduce the amount of time we spend. Generally, telling users "no" is negative, and telling them "no" quickly is even more negative: users feel like we haven't taken them seriously.
Some alternatives are essentially to ignore users or pretend to listen to users. I'm stating these in kind of an extreme way, but the effect of any change here is that users will have substantially less access to the upstream. However, this is what essentially every other company with a free product does, and it's probably actually a better experience for users (e.g., it's a less negative experience to be ignored than rejected).
These mechanisms are, on average, worse for users than a direct line to the upstream, but both give users a credible illusion that their voices have been heard, so the experience is more positive even though the outcome is worse.
We can ignore users with a community forum (we've inched forward in this vein by modernizing Ponder); we can pretend to listen to them with a private report queue which we basically just dump in the trash after sending a "Thanks for your valuable feedback, we'll consider it carefully!" canned response, or a public "vote on features" queue, although I like this less. Broadly, these mechanisms allow us to skim the wheat from the chaff without breaking the illusion of a caring upstream.
The most straightforward approach is probably:
- Bugs and feature requests move from Maniphest to Nuance, a private queue, and we mostly start ignoring that channel with a polite form response. We remove public access to create tasks. (Users who we recognize as net positive contributors retain full access.)
- General support requests move to Ponder, which we mostly ignore.
This doesn't feel great, but it's pretty much what every other company does and does seem to be the best balance of concerns.
Some other alternatives:
Some kind of paid support. I don't really see much of a way forward here. Ideally, we'd, say, make users pay $3 to file a ticket and this would just magically align incentives and solve all of the problems, but if the amount is trivial and just trying to align incentives, this makes users feel like they've invested a lot: a user who has paid $3 to get support expects vastly more from it than a user who has paid $0, since it's now "paid support". If the amount is actually in line with costs, there's already prioritization / consulting / Phacility. We also haven't had much luck trying to get users to make trivial payments to align incentives (see various experiments with Fund). The value of each ticket to us is also hugely different, from good bug reports (which we'd gladly pay to receive) to fishing expeditions ending in environmental causes (which we'd charge thousands of dollars for under consulting).
Gamify support. We could try blending community + queues into something like the League of Legends "Tribunal" process. Something like this:
- You file your issue.
- You're told "your issue awaits judgement; judge other issues to promote it to the top of the queue".
- You vote on report quality, value, etc., of other open issues for a bit. This gives you and your issues points.
- Your issues are also boosted by others judging them worthy, and hampered or rejected by others judging them unfit.
- This process has cool sounds and visual effects.
This feels like it would be amazing if Phabricator was actually a game, and could probably work for some users as-is, but I worry it's a little too out there for many first-time users. Could maybe work if this side of things was substantially downplayed until you got into it, since I'd expect only a few users to do this anyway.