The community hangs out in the Phabricator channel (type # and phabricator as one string) on irc.freenode.net

I've never heard this term "user group" before (it has "typical" things it does in your lexicon?) Can you provide some examples of successful "user groups"?

I would love if users did a better job supporting each other, particular on configuration issues. e.g. of the last five tasks filed here (T6794 -> T6798) two of them (T6796 and T6795) are user configuration issues. Long term / unless in the long term we become profitable enough to hire tons of people to handle these thing, we - the "maintainers" - will not be able to address these queries. (I'd argue we should ignore them even now we have so little resources, but I digress.)

Does this "user group" help solve this problem?

Otherwise, we seem to have a non-virtuous cycle right now where more users create more questions / "support" needs, further draining our resources, making us unable to proceed on SAAS, and thus putting our company in jeopardy from a financial perspective. It would be nice if any "user group" here somehow raised the bar on what sort of questions were being asked directly of the core team here.

I expect Ponder to serve some user to user role at some point. IRC and awesome people like @avivey really help a ton. Beyond that I think Bob is right, we need to focus on getting a real business going which will help us expand the core team and knowledge.

A healthy IRC channel is great, but compared with other channels IRC is quite demanding and leaves basically no memory. It's like high bandwidth for a minority, any it would be good to complement this with a low demand, asynchronous channel. In the old days this would be solved with a mailing list or a web forum (or both, and we would have endless discussions about which channel is better). Here we can think in our own tools, like Maniphest or Ponder.

Polishing use cases:

• Community support. Nobody wants to have the maintainers busy replying basic questions. Some community members will be happy replying to questions, while learning and perhaps even earning some reputation. It's a known model. So what if there would be a "community support" tag that the maintainers would assign to tasks that they know others can handle well? Those of us could watch the tag and step in whenever we know the reply.

• Meetups. An example: @aklapper and me will run a session at FOSDEM explaining our experience migrating Wikimedia Bugzilla to Phabricator. With about 5000 free software users and developers sharing a weekend in Brussels, chances are that someone else is involved in some Phabricator project. Wouldn't it be nice to meet in person and have a beer? (Belgian, of course)

• Marketplace. Another known model, linked with the concept of community support. Phabricator user X runs an instance and has a problem, little time, and some budget. Imagine a list of services and consultants tied to their profiles here, and their activity. It's ok if you start with 1-3 people, if this is all what it is. Phabricator adoption is increasing, and that list will grow around the place where it was started. This is especially relevant when Phacility doesn't seem to be interested in capitalizing the consultancy / premium support models (and we thank you for that, honestly).

PS: what happened to Ponder in this instance? Not that I miss it much, personally.

My two cents on this:

Community Support

In an ideal world, we'd like to resolve as many of the "community support"-able issues as possible through technical means. For example, a technical fix like T6533 means that very few users will need to ask "how do I enable syntax highlighting?" ever again. Obviously not everything can be resolved this way, but many issues can. Many other issues can be documented, and then the support solution can be just linking to the right page (I think D10493 is a good example of this working and reducing support burden). Theoretically, this means most issues really are well-suited to an IRC-ish medium (where you can immediately get a link to the thing you actually need, and just aren't asking the right question or whatever), because the answer is just a pointer from some unique way of asking a question to the right resource that resolves it.

IRC is technically logged, although it's not very searchable:

https://secure.phabricator.com/chatlog/channel/6/

Overall, I think we field relatively few repeated / archive-able support requests. When something crops up a few times, we can almost always find a technical/product fix for it. For most issues, we have a long history of success with this approach -- for example, in T4130 we added a setup warning about ft_min_word_len and I haven't seen any support requests for that issue since then. This isn't always that easy, and the space of ways users can misconfigure or misuse the software is huge, but in the overwhelming majority of cases there is usually something we can do to prevent, detect, correct, work around, or trivialize any issue we see crop up more than a handful of times.

(I think @btrahan and I have slightly different views on whether this approach can resolve 50% or 95% of issues, but I'd tend to say that T6796 is a bug in PHPMailer which we should fix and T6795 could likely be resolved with clearer documentation/instructions if users hit it again [looks like they did in T6813, actually]. I wouldn't necessarily want community members telling each other to drop tables -- for example, we have at least some community members in IRC who occasionally give well-meaning but not-really-accurate advice. A very technical community member might be able to triage T6795 for us, but I generally wouldn't expect the community to resolve those issues. There are plenty of other examples of community-resolvable things, like T6814, of course, but at least in that case I was beaten to the punch!)

We had a mailing list a while ago (a Google group, I think), but it was rarely used and most questions/answers were IRC-like and temporary/transient. We eventually shut it down as it seemed like the least useful communication channel we maintained, by a wide margin.

We disabled Ponder on this install because it doesn't have Herald integration so I kept missing questions. We'll probably turn it back on once Herald integration gets built, but didn't want users to ask questions and not get an answer for weeks. Generally, it needs a bit more work to come up to the level of features/quality that most of the other apps are at.

If you look at, e.g., the StackOverflow questions for Phabricator right now, they mostly have one-line transient answers: lots of "we don't have that feature right now, see Txxx for the existing request", "no, and we don't plan to support it, see Txxx for discussion", "this sounds like a bug, see X to file a proper report and get it fixed", etc.

We had some similar issues with Ponder on this install -- lots of temporary/transient questions with answers which are useful to only one person at only one time. I think that with some changes (Herald integration, "mark as good answer", "archive question", "merge as duplicate") we might be able to start building more of a knowledge base in Ponder, but I think we need real curation tools to distinguish "this is a one-time answer to a one-time question" from "this is a durable answer to a persistent question, which might be useful to others, and which we can not better answer with technical / product solutions". Ideally, I imagine the number of questions which this is the best solution to to be very small -- things like "What are some of your favorite image macros?", where multiple users can provide answers over a long period of time and still remain relevant. I believe we field very few questions like this.

There are also a handful of durable-but-not-permanent tasks in Maniphest (they have the Guides tag) which might do well in Ponder instead. T5447 is one example. But I think 95% of the value is having the thing written so users can be pointed toward it.

Marketplaces

For the Marketplace issue, there just aren't many service providers yet. We have this page, and plan to eventually expand it if/when there's a need for it, but the number of providers is just so small for now that a static page we manually update seems to serve the need:

http://phabricator.org/hosting/

I think there also isn't much demand for Phabricator customization/services right now (maybe because it's mostly used internally and the upstream moves so quickly that forking + customizing it is usually undesirable). Almost all the demand we see is either for a SAAS version (which we're working on) or significant new application/feature development (which we're also working on).

Meetups

Yeah, we don't have a good solution to this right now, although I don't think a user group/mailing list/forum is ideal either (and there hasn't been too much demand). Once Calendar gets built out we might be able to do one sort of organically: create an event, tag it "Meetup", and we'd put a list of meetup events on the home page? Not sure if that'd work out, but it might be a start.

Forum / Discussion Tool?

Somewhat tangential, but Facebook also had a "Discussion" tool (sort of like a forum) and @chad, at least, has a lot of thinking about forum products. We don't currently have any real plans to build a tool in this vein (although Conpherence will get some features which push it in this direction a little bit), but might build such a tool eventually. One issue is that the role it would fill / problems it would address aren't very clear to me (I wasn't a big fan of the tool at FB) and there's a lot of overlap with other tools.

Overall

I think our overall plans are basically:

• When Ponder matures a bit more, turn it back on and see if we can build something more durable / community-centric there on the support side.
• When Calendar matures a bit more, we could see if that's a reasonable way to do meetups.
• Existing static page seems OK for marketplaces for now. We have very-long-term plans around more marketplace stuff (see T5447 and T5055 for some discussion) but currently don't consider this limited by a lack of marketplace product technology.

This doesn't really address the sort of "hang out casually with other users" use case, which might be a legitimate one, although we didn't see much usage in that vein on the group when we had one. As Conpherence matures, it might be able to do this. Or we might build a tool for it. Or as Phame matures it might handle it. We also had a "post a status" tool a long time ago, which maybe we'll rebuild. In all these cases, it's mostly just not clear how much is falling through the cracks of the other existing tools. Currently, we don't think it's very much, which makes it hard to motivate building tooling for it.

(The one sort of request I do see which might qualify here is users tweeting "Anyone using Phabricator?", but my guess is that they want quick / trusted feedback and having a forum/group wouldn't convert that into a registration + post + solicit answers from random people.)

My proposal has less to do with "building tooling" and more with building community. But well, I agree with you in the sense that Phabricator adoption is overall growing, and we can always wait until critical masses of regular users, service providers, etc clarify the needs. Meanwhile, I still think it would be useful for everybody if you would point to areas where you welcome community help.

Practical proposals that could be implemented here and now:

• Create and advertise somewhere a Conpherence thread (or whatever alternative) for people interested in Phabricator development. The focus would be more how to fund development in roadmapped tasks and less about forking + customizing.

• Create a Maniphest task to organize a Phabricator meeting in SF Bay Area during 2015.The complexity of the event would be directly proportional to the amount of participants confirmed. Organizing a 1,5 days meeting for 20 people is simple. A 2 day meeting for 80 is more complex, but could be the beginning of something. Phacility should evaluate whether the investment of time is worth. Free location and even free/shared catering should be doable. The community could help. Wikimedia would certainly want to help. Worst case scenario: nothing happens at the end (which is the current status, so there is nothing really to lose).

I think its theoretically possible to build perfect software that has zero support costs though I'd bet this will never be achieved by any team of humans. Relatedly, I do think its possible to build many things to reduce support costs.

However, I am less convinced in the particular context of Phabricator development that we can build things to reduce support cost fast enough to actually reduce our total support burden. So its less a question of whether the things we build cover 50% or 95% of support costs but rather whether will we ever get far enough ahead of the remaining 50%-5% to actually be doing something other than support full time. (If its not known, I have been 100% on tasks labelled Support Impact for a good quarter or so - these are the known set of tasks that reduce support costs - and from my perspective and simple metrics like our burndown chart, support costs are still growing at the same steady clip. I know @chad has been doing nothing but support too and most days I'm not sure if he even ends up with enough time to code there's so many things to answer on a day to day basis...!)

Anyway, back to the idea here, at this time, I am only interested in changing the way we interact with the community to help reduce support costs. Otherwise, status quo will have to do. Once we have a revenue stream established that can grow as a function of users, it starts to make some sense to me to do things to directly foster that user growth, engage more users, etc.

@qgil - I'm curious if you can share how many people you have on "support" over at wikimedia anytime? I recognize this is probably rather nuanced given the scope of what you all do over there, but I'd appreciate what the costs look like for a more mature open source organization such as wikimedia.

I've been thinking a lot how open source, specifically gathering bugs, features, is a very non-scalable way to build a company. At least at closed source places, priorities come from sales, product, and management, each with a reasonable position to be making product requests that benefit said company. However in the open source world, requests that come in align with the other sources, and not usually the upstream itself. Managing these and setting expectations in a polite, yet firm way, is challenging. I think Phabricator itself is fairly unique and hard to compare to individual open source projects like Wordpress or Wikimedia, in that Phabricator spans a very broad base of utility. That means it's much more susceptible to feature creep and much harder to say no to things that perceive to be likely useful.

I also feel our focus is dramatically different these past few months getting Phacility up and running, and once it's running we'll have more time to manage this... maybe? It's hard to say, but I do wonder if feature requests might be best kept to Phacility customers and leave other channels (as mentioned here) for users to give product ideas. I am finding it takes a bit of time each day to thoughtfully reply to steady stream of requests. I'm not sure that's something the upstream will need to do on a day to day basis in the future.

I would also love a way to do User Stories with Maniphest. I think it would reduce some of the back and forth to find the actual problem a user is having.

http://en.wikipedia.org/wiki/User_story

In T6797#89105, @btrahan wrote:

@qgil - I'm curious if you can share how many people you have on "support" over at wikimedia anytime? I recognize this is probably rather nuanced given the scope of what you all do over there, but I'd appreciate what the costs look like for a more mature open source organization such as wikimedia.

I don't know whether we should be proud or ashamed for this, but the fact is that nobody is being paid to offer MediaWiki support at the Wikimedia Foundation, neither have we explicit resources allocated for this. https://www.mediawiki.org/wiki/Project:Support_desk is entirely run on volunteering resources, and the same can be said about mailing lists with a support component like mediawiki-l or wikitech-l. By "volunteering resources" I mean either Wikimedia Foundation employees replying to requests on their own initiative or actual independent volunteers doing so.

In T6797#89113, @chad wrote:

I've been thinking a lot how open source, specifically gathering bugs, features, is a very non-scalable way to build a company. At least at closed source places, priorities come from sales, product, and management, each with a reasonable position to be making product requests that benefit said company. However in the open source world, requests that come in align with the other sources, and not usually the upstream itself. Managing these and setting expectations in a polite, yet firm way, is challenging.

While it is challenging... I think you are doing fairly well so far. Your prioritization of tasks is clear, and allows any community contributor or third party to know whether a proposal makes sense or not, and what needs to be fixed before addressing it. I think you could cut support costs by applying that prioritization to yourselves more strictly.

Maybe you are too kind putting too much time on tasks marked as Wishlist / Low, or that you have even said that you as upstream are not interested in pursuing? Also note that by being quick and efficient even in Low / Wishlist / Wontfix tasks you are indirectly making it more difficult to other community members to step in and provide answers there. Don't be afraid to keep your own resources in a clearly delimited area, letting all the rest to an organic process happening without the core maintainers, where good ideas and good contributors may still arise and be brought to the main plan.

I think Phabricator itself is fairly unique and hard to compare to individual open source projects like...

While Phabricator in an outstanding open source project in many ways, I don't think the problems you are describing and the possibilities to solve them are unique at all. You are not the first software project having to define a clear roadmap and scope so others can plan accordingly, having to decide between speed of development and maintaining a complete and reliable API, etc.