amckinley's Onboarding
Open, NormalPublic


  • Review D17641 for some additional setup guidance.

Some starter tasks in Countdown:

After that, the "Basic" and "Intermediate" columns on Contributor Onboarding have approachable tasks with guidance, roughly ordered from "fairly useful" to "frivolous". Most of those tasks have a comment from me somewhere near the bottom with the state of the world; the descriptions didn't always get updated as things evolved. You can pick and choose this stuff, some of the stuff near the bottom is just silly.

If you manage to get ahead of my ability to line up work for you, these are some recent tasks which appear legitimate and could use triage (i.e., figure out if the thing reproduces and what the issue is, but not necessarily actually fix it), although some of them may be very complicated or ridiculously time consuming or just very very uninteresting:

These are some recent and not-so-recent tasks which are probably reasonable to implement, although they don't have detailed guidance and may need more context. Some of these are may be very labor-intensive and a few are at the upper end of complexity in this project. I don't expect you to get through any significant part of this list, this is just a reasonable starting point for open, relatively stand-alone issues that tries to filter out most of the fluff and stuff tied to bigger projects. Just ping me on any of these and I should be able to suggest some reasonable path forward where things aren't clear.

Other context, state, and larger projects to think about in the longer term:

  • Nuance is a planned "support queue" (among other things) application that I expect to work on next (T8783). Once this actually does something there may be more room to collaborate on it.
  • Conpherence is our chat application. It is currently okay. It could be significantly better. The Conpherence workboard is reasonably up-to-date. Progress on Conpherence tends to be impeded by the large amount of JS required and much of the application being about a generation behind in terms of technical debt. Unclear how valuable this is.
  • Phriction is the wiki application. It hasn't received a major update in a while and the Phriction workboard reasonably collects a fair amount of work. Unclear how valuable this is.
  • T12010 describes ongoing work in Differential / Diffusion / Arcanist. arc, as a whole, has not received a major iteration in a long time and has many updates planned. Among these is package management for linters and third-party applications (T5055 / Packages).
  • T4200 describes building installers. It is unclear how valuable this is, especially now that we've shipped SAAS and you can launch test instances in about a minute.
  • Harbormaster (our build tool) and Drydock (a host resource management tool that does things like manage build pools for Harbormaster) are powerful but difficult to use. Some installs pay companies like CircleCI, Travis, and Buildkite for services that Harbormaster/Drydock can provide, but it's not clear how much value there really is here.
  • Although somewhat out of date, T7346 discusses anticipated future SAAS challenges. T12218 discusses some recent issues which now appear to have stabilized. T11230 discusses future plans for higher-end SAAS offerings.
  • T1562 / T4171 are "build charting / reporting", but there is a general scarcity of compelling use cases for these requests at the moment.
  • Improving the first-login experience is probably valuable (most recently, T11132) as rough data suggests that we're losing more users in the "do something with your install" step of the signup process than elsewhere. Formalizing metrics on the registration funnel first may also be useful. We've also made significant changes here since the last time we looked at this. The last big growth project we did was free instances (launched circa December 2016) but it's still too early to really tell how worthwhile that is.

In general terms of assessing the value of work:

  • Self-serving changes which personally make you happier with the product and development workflow are generally valuable. This includes fixing technical debt, obscure bugs, improving tools, working on things you find fun/interesting even if they aren't the very most important projects, taking a break from important-but-horrible projects, never ever ever ever fixing T9548, etc.
  • Beyond personal satisfaction, revenue impact is generally the best proxy for value at this stage of the company. We are limited primarily by engineering bandwidth, and more revenue lets us put more disposable, interchangeable, faceless cogs on payroll to bang out code. Hoo-rah!
  • We make almost all of our revenue from SAAS, and SAAS revenue is the most scalable. Although we haven't hit this yet and our pricing plan makes staying with SAAS indefinitely attractive, we plan to offer private clusters in the future to let our offering grow with large SAAS installs (T11230). Requests from SAAS users are generally tagged with Phacility. Nuance should help formalize this and make it more clear what work directly impacts paying SAAS customers.
  • We make a small amount of revenue from "enterprise" self-hosted installs through Prioritization and Phacility Consulting. Historically, this revenue serves more as a prioritization signal than a real revenue stream. This was more relevant in the past than it is today: we now have a much better sense of internal priorities. In the long term, we make revenue from these installs after they IPO and a bunch of employees leave to start startups and select Phabricator as a development platform, but this takes 4+ years. With Nuance, we hope to offer a support product for these installs that better matches our ability to provide services to their ability to navigate internal approval processes to pay us for those services (rather than trying to extract a prioritization signal).
  • As an open source project, we also have a community that is eager to ask us to build all kinds of things. Although this was a valuable channel in the past, a lot of work has been considered and planned over the past few years and it is relatively rare that feature requests provide much insight nowadays. Many things users request are ultimately ideas which will cost us a lot of resources to maintain and may never generate revenue. Many users self-report their requests as critical (it costs users nothing to say "this is very important" instead of "this would be nice to have") and the users with the least valuable problems and greatest amount of free time sometimes have the loudest voices. Users who don't bother reading any of the instructions can also be the most successful in navigating those instructions (see T12134 for examples). Nuance aims to improve this, but until then you should view user requests with a healthy dose of skepticism. (But, users in Community are generally distinguished as net-positive contributors.) Users are also often strongly incentivized to ask for the quickest, dirtiest hacks they can imagine. These implementations cost us in the long run and we should avoid them. Some of these requests are interesting and valuable but the overall value of this channel has dropped steadily over time and I hope to largely abolish it with Nuance. If we ever complete all the work already in queue and run out of ideas and are just sitting on a big pile of money twiddling our thumbs, we can always revive it.
  • Generally, we don't currently have a good assessment of the value of free installs, but revenue impact is probably low in most cases. For example, we apparently have significant adoption in China, but see approximately zero (perhaps actually zero) revenue from China. Prioritizing work like internationalization might help with adoption in China, but it's not clear that this would actually benefit the company much. I think @chad has a more favorable view of general free adoption than I do -- even if they aren't driving revenue, it's nice to know that people are using the product. I don't find this as personally rewarding, and I'd personally be completely happy if all free users use GitHub forever and we only take their paying users. Preliminary data also suggests that the conversion rate from free SAAS instances to paid SAAS instances is low, although this is still very early.

Part of the goal of Nuance is to make this evaluation-of-value process more straightforward by tying SAAS users directly to requests, allowing enterprise installs to register more formally for direct upsteam access, and reducing the support cost of the least valuable users (e.g., those who don't bother to read the instructions when filing bug reports).

Related Objects

Mentioned Here
D17641: Write a "Developer Setup" guide for onboarding
T1562: Build "Facts", an ETL pipeline and charting application
T4171: Building reporting and data systems
T4200: Building OS packages and install scripts
T5055: Distribution mechanism for arc extensions
T7346: Anticipate scaling challenges in the Phacility cluster
T8783: Unprototype Nuance (v1)
T9548: Support Mercurial's bundle2 wire protocol
T11132: New Phabricator NUX
T11230: Phacility: Private Clusters
T11729: Move Conpherence to EditEngine
T11738: Improve the heuristic which guesses which function/method/class line best provides context for diff snippets
T11831: Add setup check for missing PCRE_UTF8 support
T11934: Make email commands ("/subscribe") work in all contexts, including Conpherence ("/me")
T11981: Support specifying the short name of the repository in .arcconfig for a repository
T12010: Untangle the Gordian Knot of iterating on Differential/Diffusion/Arcanist
T12033: Large diffs can still repeatedly fail to insert
T12071: Require "E" be defined in variables_order so $_ENV is correctly populated
T12100: Consider removing "maximum-scale" from "viewport" tag
T12104: Clean up remnants of old Differential draft storage
T12118: Differential email does not contain reviewers/subscribers information anymore
T12121: Allow users to view changes in merge commits relative to any ancestor, or as conflict resolutions only
T12124: Counterintuitive priority setting via maniphest.edit conduit call
T12134: Develop a Nuance-based Phabricator reporting/support flow
T12164: Put an indirection layer between author/committer strings and user accounts
T12167: Unable to edit menu items on mobile
T12178: Users can send messages to Conpherence rooms they do not have CAN_JOIN permission for
T12184: Large (~750MB) git push fails over SSH
T12185: Action Lists on Repository edit pages don't display on tablet/mobile
T12190: In PHP7, include-time warnings from source files are ignored
T12193: Allow mentions to work in Phriction edit notes
T12200: Typeahead completion (of any kind) does not work with Persistent Chat on
T12218: Reduce the operational cost of a larger Phacility cluster
T12234: Add a "Duplicates" tab to the "Related Objects" section on task page
T12241: Make it easier to find objects while in remarkup box
T12256: Parse multiple commits and commit metadata from "git show" and "git format-patch"
T12257: Add an "author email" field to the "Differential Diff" Herald rule
T12300: git push --mirror --force does not work on Phacility with repo that has refs/pull
T12325: Dynamically adjust the display precision of countdowns to increase dramatic tension
T12363: Configuration of "Tab Panel" is lost when 1st tab has no panel assigned
T12373: Support macros in Phame
T12379: Instance reporting difficulty pushing the Linux kernel to a Phacility instance
T12380: Errors with Mercurial trust while browsing rHGTEST on this install
T12392: Instance reporting that synchronizeWorkingCopyBeforeRead() effectively fails
T12393: Instance reporting possible lock issue around `git fetch` of clustered working copies
T12404: Implement a first-party SMTP client
T12431: Pull logs should let us identify client disconnects
T12440: Broken project permissions/weird bug with nested projects
T12443: Applying fulltext limits first causes missing results
T12455: Tag order on tasks matters for subprojects and milestones
T12458: LDAP sign-in with "Trust Email Address" doesn't beat implicit "auth.require-email-verification"
T12483: SAAS install reporting that they are unable to clone with "git svn"
T12488: Old Calendar events didn't get a utcInstanceEpoch populated, causing fatals on export
T12491: Error reply emails which are generated before identifying the sender should no longer be sent, now that the "always require verification" rule is in place
T12505: Ownership rules whose owning package is a milestone fail to show as accepted
T12523: Remove the ability to delete countdowns
T12524: Modernize Countdown

I'd personally be completely happy if all free users use GitHub forever and we only take their paying users

Just as an FYI, GitHub doesn't offer private repositories on their free plans, so this won't ever happen (I'd guess most people use the free Phacility plan because they need private repositories).

I'd guess most people use the free Phacility plan because they need private repositories.

I don't think so because there are GitHub like solution that offer private repositories for free.

Well, this is a GitHub-like isn't it? In the context of what was quoted, it was specifically GitHub itself that was mentioned.

To clarify, I meant this:

I'd be happy if all [users currently using GitHub for free continue to] use GitHub [for free] forever...

Restated: converting small personal and open source projects from free GitHub accounts to Phabricator is not important to me.

Obviously this won't happen: GitHub could not continue to host these projects if we took all their paying users.

Oh right. I mean Phacility doesn't cater to those people anyway since all repositories are private (and can't be public), so I don't think you have much to worry about there.

avivey renamed this task from Onboard to amckinley's Onboarding.Nov 20 2017, 12:36 PM
pasik added a subscriber: pasik.Sat, May 12, 1:51 PM