• Review D17641 for some additional setup guidance.

Some starter tasks in Countdown:

• T12523: Remove the ability to delete countdowns
• Some time after making a visible change like T12523, deploy it to secure.phabricator.com. See Phage (Phacility) for Phage setup help and the deployment workflow. See Developer Setup for prerequisites. See Phacility Cluster CLI Tools for discussion of bin/remote, which phage remote wraps so you can break a lot of machines at once.
• T12524: Modernize 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:

• T12505: Ownership rules whose owning package is a milestone fail to show as accepted
• T12488: Old Calendar events didn't get a utcInstanceEpoch populated, causing fatals on export
• T12483: SAAS install reporting that they are unable to clone with "git svn"
• T12458: LDAP sign-in with "Trust Email Address" doesn't beat implicit "auth.require-email-verification"
• T12379: Instance reporting difficulty pushing the Linux kernel to a Phacility instance
• T12184: Large (~750MB) git push fails over SSH

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: 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 - Some inbound mail exceptions generate a reply when they should not.
• T12455: Tag order on tasks matters for subprojects and milestones - Write failing tests first.
• T12443: Applying fulltext limits first causes missing results - Can move forward but needs guidance.
• T12440: Broken project permissions/weird bug with nested projects - Uses wrong edge type. Start writing inverse edges, migrate to generate inverse edges, switch query to use inverse edges.
• T12431: Pull logs should let us identify client disconnects - Needs a lot of local setup before you can test it.
• T12393: Instance reporting possible lock issue around `git fetch` of clustered working copies - Very hard.
• T12392: Instance reporting that synchronizeWorkingCopyBeforeRead() effectively fails - Very hard.
• T12380: Errors with Mercurial trust while browsing rHGTEST on this install - Debug in production, then fix deployment scripts in rCORE to provision secure hosts correctly.
• T12373: Support macros in Phame - Moderate local setup required.
• T12363: Configuration of "Tab Panel" is lost when 1st tab has no panel assigned
• T12325: Dynamically adjust the display precision of countdowns to increase dramatic tension - Pile of Javascript.
• T12300: git push --mirror --force does not work on Phacility with repo that has refs/pull
• T12257: Add an "author email" field to the "Differential Diff" Herald rule
• T12256: Parse multiple commits and commit metadata from "git show" and "git format-patch" - May be an enormous amount of work for little benefit.
• T12241: Make it easier to find objects while in remarkup box - Lots of Javascript.
• T12234: Add a "Duplicates" tab to the "Related Objects" section on task page
• T12200: Typeahead completion (of any kind) does not work with Persistent Chat on
• T12193: Allow mentions to work in Phriction edit notes
• T12190: In PHP7, include-time warnings from source files are ignored
• T12185: Action Lists on Repository edit pages don't display on tablet/mobile - As below.
• T12167: Unable to edit menu items on mobile - As above.
• T12178: Users can send messages to Conpherence rooms they do not have CAN_JOIN permission for - Might stumble into a trench full of technical debt.
• T12164: Put an indirection layer between author/committer strings and user accounts
• T12124: Counterintuitive priority setting via maniphest.edit conduit call
• 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
• T12104: Clean up remnants of old Differential draft storage
• T12100: Consider removing "maximum-scale" from "viewport" tag
• T12071: Require "E" be defined in variables_order so $_ENV is correctly populated
• T12404: Implement a first-party SMTP client - Fun!
• T9548: Support Mercurial's bundle2 wire protocol - Extra fun!
• T12033: Large diffs can still repeatedly fail to insert
• T11981: Support specifying the short name of the repository in .arcconfig for a repository
• T11934: Make email commands ("/subscribe") work in all contexts, including Conpherence ("/me")
• T11831: Add setup check for missing PCRE_UTF8 support
• T11738: Improve the heuristic which guesses which function/method/class line best provides context for diff snippets
• T11729: Move Conpherence to EditEngine

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).