- Review D17641 for some additional setup guidance.
Some starter tasks in Countdown:
- {T12523}
- Some time after making a visible change like T12523, deploy it to `secure.phabricator.com`. See [[ phacility_cluster/phage/ ]] for Phage setup help and the deployment workflow. See [[ handbook/developer_setup/ ]] for prerequisites. See [[ phacility_cluster/cli/ ]] for discussion of `bin/remote`, which `phage remote` wraps so you can break a lot of machines at once.
- {T12524}
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:
- {T12505}
- {T12488}
- {T12483}
- {T12458}
- {T12379}
- {T12184}
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.
- {T12491} - Some inbound mail exceptions generate a reply when they should not.
- {T12455} - Write failing tests first.
- {T12443} - Can move forward but needs guidance.
- {T12440} - Uses wrong edge type. Start writing inverse edges, migrate to generate inverse edges, switch query to use inverse edges.
- {T12431} - Needs a lot of local setup before you can test it.
- {T12393} - Very hard.
- {T12392} - Very hard.
- {T12380} - Debug in production, then fix deployment scripts in rCORE to provision `secure` hosts correctly.
- {T12373} - Moderate local setup required.
- {T12363}
- {T12325} - Pile of Javascript.
- {T12300}
- {T12257}
- {T12256} - May be an enormous amount of work for little benefit.
- {T12241} - Lots of Javascript.
- {T12234}
- {T12200}
- {T12193}
- {T12190}
- {T12185} - As below.
- {T12167} - As above.
- {T12178} - Might stumble into a trench full of technical debt.
- {T12164}
- {T12124}
- {T12118}
- {T12121}
- {T12104}
- {T12100}
- {T12071}
- {T12404} - Fun!
- {T9548} - Extra fun!
- {T12033}
- {T11981}
- {T11934}
- {T11831}
- {T11738}
- {T11729}
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 ((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).