Page MenuHomePhabricator

When will my feature get built, or my bug get fixed?
Closed, ResolvedPublic

Description

IMPORTANT: Discussion of project planning has moved to Planning on the wiki. That document obsoletes this task, which is no longer authoritative.

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:

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.

Related Objects

Mentioned In
T5474: Support workboard column triggers which activate when a task is dropped into a column
D12165: Add --project option to 'arc tasks' workflow.
D10297: Support Azure AD / Office 365 as an OAuth provider
T7563: Dragging tasks on Maniphest appear in the wrong position (n+1)
T6835: Add a Gantt chart view to the "Reports" section
T4427: Add formal task points
T7470: show the base branch name in Differential revision info
T7358: When Replying to an Inline Comment, provide original context in email?
T5150: Extend query by time restrictions
T7166: Putting project to CCs as a condition of Herald Rule doesn't get triggered
T7068: Diff Parse Exception: Expected a hunk header
T7073: The meaning of the login icon is not clear
Roadmap
T6997: Show prefix or project for commits in feeds
T6876: Differential should preserve inline comments in code through revision updates
T3669: Make it easier to remember to submit inline comments when updating a diff
T6583: Allow video embed and custom html in dashboard markup
T6617: Fix CTRL+click and middle click on notifications menu
T4909: Rate limit or restrict access to comment removal
D10764: Write bug report, feature request and code contribution guides
T6347: Write a document describing the classes of changes we build/accept in the upstream
T3820: Implement top-level "Spaces" that provide policy isolation to groups of objects
T6297: Maniphest email notification doesn't say why I'm receiving it
T5636: add option to arc diff to include entire commit history for review
T5819: Allow project colors to be relabeled
T3980: Support "Bind to External Thing" to define project membership
T4698: Support for SVN patches, created by PhpStorm
T4453: When multiple commits correspond to a single revision, Differential updates to show one of them arbitrarily
Mentioned Here
T6309: Build Notification "Switchboard" Preference Panel
T6297: Maniphest email notification doesn't say why I'm receiving it

Event Timeline

epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley added subscribers: epriestley, chad, btrahan.
epriestley updated the task description. (Show Details)Apr 9 2014, 10:47 PM
epriestley updated the task description. (Show Details)Apr 10 2014, 12:13 AM
qgil added a subscriber: qgil.Apr 18 2014, 10:28 PM
nemobis updated the task description. (Show Details)Oct 17 2014, 5:23 PM
nemobis updated the task description. (Show Details)Oct 17 2014, 5:25 PM

@nemobis, please don't edit documents like this which are written in Phacility's voice and describe policies that "we" (the upstream) follow. If you think the text is unclear, leave a comment suggesting changes or write about it in a context where the voice is clearly yours (e.g., a personal blog).

epriestley updated the task description. (Show Details)Oct 17 2014, 5:33 PM

Err, I just pasted what you folks said

Ok, following your request: please integrate the diff https://secure.phabricator.com/transactions/detail/PHID-XACT-TASK-4qse7yakd4fvs45/ because it contains important information that I wish I had known before filing tasks. The text comes from comments by maintainers at T6297, T6309; copying it here makes it easier to reference (I have to link one thing instead of 6 comments) and will hopefully save you from repeating the same things again on countless other tasks.

Those comments both address what features we build. This task talks about timelines and prioritization, which are different. Those comments are also written in specific contexts, and are not a good discussion of the issue without that context.

In general, listing everything we've chosen not to build here with individual rationales wouldn't be helpful in answering questions about timelines and prioritization, and it wouldn't be particularly helpful even in a dedicated "What sort of features do you build or accept in the upstream?" discussion because each reason for rejection would be too narrow in scope.

I didn't propose adding any list. The comments were expressed as generic. If this guide is about the "When", can a similar guide be created with the "What"? Otherwise, if collating the information in question is not considered interesting, is there a wiki where to collect links to scattered place currently containing it?

If you want to file an issue, I can write "What" eventually. Per this task, it's not a priority.

This comment was removed by epriestley.
chad updated the task description. (Show Details)Apr 14 2015, 4:32 PM
epriestley closed this task as Resolved.Apr 15 2015, 10:12 AM
epriestley updated the task description. (Show Details)