Planning

Updated 2,553 Days AgoPublic

Actions

This document describes how we plan and schedule Phabricator development.

Planning FAQ

Can you build (some feature) soon?

Sort of! See: T12681: Upcoming Support Product / End of Paid Prioritization

Are there other ways to get features built sooner?

No. The only way to affect the priority of an issue is to pay us.

What's the status of (some feature)?

We use Phabricator to track progress, and the appropriate task already has the most up-to-date information about progress and status.

We have thousands of open tasks, and only a few can move forward at once.

Are you ever going to build (some feature)?

If it's filed in Maniphest, we plan to address it. If it isn't, see 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.

When will you build (some feature)?

We don't know. This document explains why we don't know.

Why We Don't Have Concrete Timelines

We generally do not have concrete timelines for feature development and do not make or attempt to make accurate long-term forecasts.

Instead, we try to maximize throughput and respond quickly to new information. These goals are at odds with long-term forecasting and concrete timelines. We think these goals are much more important than forecasting, so we have no plans to ever produce accurate long-term forecasts.

The remainder of this document discusses these points in greater depth.

Maximizing Throughput

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.

In almost every case that we have an opportunity to improve throughput by rewriting plans, we'll do so. This improves throughput overall, but makes long-term forecasting impossible.

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 our understanding of problems and use cases, and often change our plans in response to changes in this understanding, 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. This improves our ability to react to changing circumstances, but makes long-term forecasting impossible.