This document describes how we plan and schedule Phabricator development.
> When will you build **(some feature)**?
We don't know. This document explains why we don't know.
> Are you ever going to build **(some feature)**?
If it's filed in Maniphest, we plan to address it. If it isn't, see [[ https://secure.phabricator.com/book/phabcontrib/article/feature_requests/ | Contributing Feature Requests ]].
You can check the [[ Roadmap ]] or [[ Starmap ]] for near-term and long-term goals, but reading the rest of this document first may help you understand those documents better.
> Can I build **(some feature)** and contribute it?
Maybe. See [[ https://secure.phabricator.com/book/phabcontrib/article/contributing_code/ | Contributing Code ]].
> Can you build **(some important feature)** right away?
You can pay us to build features immediately. See [[ Prioritization ]].
Our primary goal in planning is to **maximize throughput**. By planning, we're trying to identify how we can build the most valuable things in the shortest amount of time.
Creating an accurate long-term forecast is not a planning goal. Forecasting is a means to an end: the real goal is throughput. Forecasting can help with this, but it is not intrinsically valuable. If the goal of planning was to create accurate long-term forecasts above all other concerns, the best plan would be "we will do nothing" followed by doing nothing. This would always be accurate.
For some companies, accurate forecasting may be important to throughput. It is difficult to to coordinate across teams to accomplish large strategic goals without good scheduling and forecasting capabilities. If you have multiple teams, high communication overhead, developers with specialized expertise, complicated dependencies between projects, external timelines, or goals bound to hard scheduling requirements (like a launch window, the construction of a datacenter, or hardware fabrication), good scheduling and forecasting may be important to achieving throughput because the cost of changing direction is very large.
However, we have a small team and essentially all of our strategic goals are software goals that can be accomplished iteratively and paused and resumed at any time. Our product and process are architected to support iterative development. We can reassign development resources freely and have a very low overhead and few technical dependencies or external timelines. The cost for us to completely rewrite our plans is //nearly zero//.
Integration of New Information
Because our goal is to maximize throughput and we can rewrite plans very cheaply, we frequently rewrite plans when new information becomes available which allows us to develop a better plan with higher throughput. For example, here are some kinds of information we might learn which might cause us to change our plans:
- We may learn of very important issues like security vulnerabilities.
- We're heavily driven by user feedback, and often change our plans in response to it, but can not always anticipate how users will receive or interact with a feature before we build it.
- Some kinds of changes can be made more efficiently if we complete multiple features in the same area of the codebase at the same time. If something gets prioritized, this often means that it makes sense to prioritize adjacent changes so they can be completed more efficiently, even if they wouldn't otherwise have been a priority: one planning change can cascade into many planning changes.
- Some aspects of our business are driven by customers and contracts, and we can not always anticipate the business needs of customers. We may learn that they have new needs, or that their needs have changed.
- We sometimes start building something and realize it's a lot harder or easier to build than we'd thought, for a variety of product or technical reasons. This could lead to us making planning changes.
In all these cases, when we learn new information, we make planning changes to incorporate it. Because the cost to rewrite plans is very small, these changes are often substantial.