Original Description

This is an umbrella task to help answer user questions about progress and estimates. If this seems useful, we could make it part of the documentation.

Have a contract with us?

If you have a contract with us, none of this document applies to you; refer to your contract for timelines and estimates. This document discusses our ability to make long-term forecasts in the general case, outside of contractual agreements. If you are interested in Paid Prioritization, you can read more about it here.

About Phacility

Phacility is the company that develops, maintains, and supports Phabricator. We're a small, independent company located in the San Francisco bay area. We have 3 employees and no external funding. Although the first version of Phabricator was built at Facebook (and the three of us used to work there), Phabricator is now an independent project and Facebook is just a normal user of the software.

Overview

In the general case, we don't have much ability to precisely predict when features will be built. This is an explicit decision, based on a series of careful evaluations. Being able to make accurate long-term predictions isn't especially valuable to us on its own, and when it conflicts with another development goal we'll almost always trade away the ability to make long-term forecasts in order to get any other advantage. Doing this systematically has left us with a reduced ability to make accurate forecasts, but improved abilities in other areas. Overall, we think this is highly desirable.

Worse Forecasts, Higher Throughput

Often, the advantages we seek to gain are either flexibility or overall velocity. Specifically, by accepting that we won't be able to make accurate long-term forecasts, we can get more important things done sooner and get more done overall.

Here are some examples of how we prioritize things like flexibility and velocity over the ability to make accurate long-term forecasts:

• When we become aware of important issues, like security issues and critical bugs, and prioritize and fix these immediately. We think being able to address security issues quickly is very important, and have an excellent track record on doing this. However, letting them jump to the head of the queue negatively impacts our ability to make accurate long-term forecasts, because we can not predict how many issues will be encountered.
• Our short-term and long-term roadmaps are heavily influenced by user feedback. If we start working on something but it ends up not being as useful to users as we'd hoped, we may deprioritize it. If we get a lot of demand for something, we might prioritize it. If we're getting good feedback about a feature but users are having trouble with it, we might spend more time developing or improving it to make sure it's easier to use. These kinds of changes can move development around on the roadmap a great deal, and can happen on a very short feedback cycle because we ship updates frequently. We'll often have at least a rough sense of where a feature sits relative to our expectations within a few days of building it. Overall, this lets us focus on more important features which impact a greater number of users. However, it reduces our ability to make accurate long-term forecasts.
• Our total throughput is greater by being able to schedule similar tasks at the same time, hold features until after infrastructure changes, and make other technically-motivated adjustments which reduce the total implementation burden of a change. Scheduling features and bugs in a way that makes sense technically lets us get a greater total amount of work done, but it reduces our ability to make accurate long-term forecasts.
• We have contracts with some customers which give them influence over our roadmap. Their priorities can change as their business needs change, and we can react to these priority changes as soon as they're communicated to us. Since we have varying levels of insight into customers' businesses, we often can't predict how these priorities may change. Allowing customers to change their priorities as their business needs change is valuable to them and allows us to offer a better service, but reduces our ability to make accurate long-term forecasts.
• Software estimation is a hard problem in general, and even under ideal conditions we aren't experts at it. Since accurate long-term forecasts aren't especially valuable to us, this isn't an area we focus on very heavily. Even if we were experts and felt this was more important, the tradeoffs we've made make consistent, accurate long-term prediction impossible. We would need to reduce our flexibility or overall velocity to materially improve our ability to make predictions.
• Culturally, we think that work/life balance is important, and that focusing heavily on timelines and deadlines is disruptive to that, especially if it implies an expectation that employees will work overtime to hit upcoming deadlines. We expect employees to prioritize their lives over their work, don't do things like "crunch time" or "lockdown", and encourage employees to step away from work when they want to without necessarily giving very much advance notice. (Our company isn't a free-for-all, but we employ responsible adults and trust them to make sound decisions.) We think this increases overall throughput, and are certain it increases how much we like working here, but it reduces our ability to make accurate short term predictions.

Because we've consciously traded away the ability to make accurate long-term predictions about software development timelines in order to increase flexibility and throughput, any estimates we give for anything are at best educated guesses. To be explicitly clear: our estimates are routinely off by many months or even years, in either direction. While we can take a best guess given plans today, the guess probably isn't very good and it's almost guaranteed that the plans will change (often substantially) between now and whenever the estimate date is.

How We Prioritize

Here's a general outline of how we prioritize work. This is not an algorithm, but intended to provide a broad sense of the kind of things we work on and why:

1. Security issues.
2. Bugs which are blocking users from getting work done.
3. Bugs and features which will cost us much more to fix later than now (often support issues, migration issues, etc).
4. Bugs and features we've made contractual agreements to build.
5. Other bugs and features. Most of the work we plan to do for the next year or two is filed in Maniphest, and Maniphest is the master list of tasks we work on.
   • Stuff on our Roadmap generally gets built sooner.
   • Stuff which affects a lot of users generally gets built sooner.
   • Stuff which has high impact for the development cost generally gets built sooner.
   • Stuff which is cool or interesting generally gets built sooner.
   • Bugs usually get fixed sooner than features get built.
   • Stuff which affects very few users generally gets built later.
   • Stuff which is really complex to implement generally gets built later.
   • Stuff with "Wishlist" priority usually gets built much later, if at all.

When will my thing get built?

You can get an extremely approximate sense of this by walking through the list above. These things will get it built sooner:

• Is it filed in Maniphest?
• Is it a security issue?
• Is it preventing you from getting work done?
• Does it affect a large number of users?
• Is it a bug?
• Is it easy to fix?
• Is it easy to reproduce and test? Do we have enough information?
• Will lots of people use it or benefit from it?
• Is it on the roadmap?
• Is it cool or interesting?
• Do you or the company you work for have a history of involvement and contribution to Phabricator?
• Is there code attached?
• Do you have a contract with us outlining a timeline?

These things will get it built later:

• Is it not filed in Maniphest?
• Is it a feature?
• Is it very complex to build?
• Is it a huge, incredibly complex feature?
• Does it only affect you, and/or only affect a few users?
• Will only a few users benefit from it?
• Is it hard to reproduce, or hard to test or verify? Do we have only a little bit of information?
• Is it totally boring and lame?
• Is it not on the roadmap?

Based on these criteria, we try to get things done on roughly these timelines:

• Security Issues: Immediately (usually less than 6 hours).
• Critical Bugs: Same day.
• Not-so-critical bugs, easy stuff, high-value stuff: Next couple of days.
• Things that, for whatever reason, hit enough of the points above to get higher priority: Next few weeks.
• Stuff on the Roadmap: Next year or so.
• Other stuff: Next few years.

What are you working on right now?

The easiest way to see what we're working on right now is to look at what we've recently worked on. Since the project is open source and we build things using a series of small changes, we're rarely more than a day (and often no more than a few hours) ahead of the last activity available in Phabricator. In particular, you can look at:

• Phabricator Feed
• Phabricator Commit History
• Recently Closed Tasks

Can I build my thing?

Probably. Phabricator is open source, and we welcome contributors (to date, we've accepted patches from more than 200 unique contributors).

If your thing is a bug fix, you can almost certainly just build it and send us a patch. We're happy to give you guidance on how to get started (filing a task, or making a comment on existing task, is a good way to get questions answered).

If your thing is a feature, we ultimately have to maintain stuff that goes in the upstream, so sending us a patch isn't a guarantee that your thing is going to make it in. If your thing is complicated, or not very generalized, or serves a very narrow use case, or just obviously a bad idea, it may cost us a lot of time and effort to support it in the future, so we might not want to accept it. If you want to build something small, sending a patch is fine and we can talk through the merits in review, but if you're planning to build something bigger it might be worthwhile to:

• File a task (or make a comment on an existing task) explaining what you want to build, why, and making it clear that you're interested in building it.
• We'll give you some guidance on how to move forward, or why the feature doesn't make sense in the upstream, or should wait for other changes before being built (e.g., if we're planning to change a piece of infrastructure in the future, it generally doesn't make sense to build on top of it right now).
• Once everyone's on the same page, build the thing.

To actually build stuff, start with the Contributor Introduction.