Planning

Updated 2,469 Days AgoPublic

Actions

This document describes how we plan and schedule Phabricator development.

Planning FAQ

Can you build (some feature) soon?

Yes! Paying customers can request features be prioritized through support.

Are there other ways to get features built sooner?

No. The only way to affect the priority of a feature is to pay us.

Can I request a feature?

Yes! Paying customers can request features through support.

Are there other ways to request features?

No. The only way to request features 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.

If you are a paying customer and you'd like more detailed insight into our planning process and roadmap, you can file a support request. However, we usually don't have a concrete timeline and can only offer a bit of context and guesswork.

Are you ever going to build (some feature)?

If it's filed in Maniphest, we plan to address it. If it isn't and you're a paying customer, file a request through support.

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 usually don't know. This document explains why we don't know.

Upstreamable Features

Not every feature is a good fit for the upstream, and we often decline to implement features. (If we don't think upstream features are the best solution, we'll try to find another way to solve your problem.)

To be upstreamable, a feature must usually satisfy these points:

Broad Appeal: A new feature must be useful to many different users at many different organizations.

Also, these users and organizations must actually exist in reality, not just as hypotheticals. We will essentially never implement a feature which solves a problem for only you personally or only your organization.

Problem Fit: A feature must represent a good solution to a real problem which we have a deep understanding of.

Sometimes, problems are really rooted in cultural, organizational, or process concerns. We will usually decline to implement features which work around cultural or organizational problems, and recommend you try to fix those problems instead.

We must understand problems before we implement features to solve them. If we do not understand the problem we're solving, we can't maintain the feature.

Robust: A feature must be secure, scalable, and reliable.

We will generally decline to implement features which have significant security, scalability, or reliability concerns which we can not overcome.

Supportable: A feature must be reasonably easy to maintain, test, and support.

We will generally decline to implement features which are very difficult to test or maintain or likely to be confusing or overwhelming for a new user. (We may be able to find a similar approach which is easier to understand.)

Features which add a new configuration option or checkbox generally make the product more difficult to maintain and support, and face a higher barrier to upstream adoption.

General Purpose: We prefer features which solve many different problems for many different organizations over features which solve a narrow set of problems.

After gaining a deep understanding of the problems several organizations face, we can often build a general purpose toolset for an entire problem domain.

Aligned With Starmap: A feature must align with our long term plans for Phabricator, and generally be a cohesive and consistent part of the product and platform.

We will decline to implement features which conflict or interfere with our overall plans.

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.