Have a feature you'd like to see in Phabricator? This article describes how to file an effective feature request.
The most important things to do are:
- Understand the upstream
- Make sure your feature makes sense in the project
- Align your expectations around timelines and priorities
- Describe your problem, not your solution
- File a task in Maniphest
The rest of this article walks through these points in detail.
If you have a bug report (not a feature request), see Contributing Bug Reports for a more tailored guide.
For general information on contributing to Phabricator, see Contributor Introduction.
Before filing a feature request, it may be useful to understand how the upstream operates.
The Zero Engine upstream is the Zero Engine Developers who work in DigiPen's Research & Development department. We maintain total control over the project and roadmap. There is no democratic process, voting, or community-driven decision making. This model is better at some things and worse at others than a more community-focused model would be, but it is the model we operate under.
We have a cohesive vision for the project in the long term, and a general roadmap that extends for years into the future. While the specifics of how we get there are flexible, many major milestones are well-established.
Although we set project direction, the community is also a critical part of Zero. We aren't all-knowing, and we rely on feedback to help us identify issues, guide product direction, prioritize changes, and suggest features.
Feature requests are an important part of this, but we ultimately build only features which make sense as part of the long term plan.
Since it's hard to absorb a detailed understanding of that vision, describing a problem is often more effective than requesting a feature. We have the context to develop solutions which fit into our plans, address similar use cases, make sense with the available infrastructure, and work within the boundaries of our product vision. For more details on this, see below.
Some feature requests support very unusual use cases. Although we are broadly inclusive of many different kinds of users and use cases, we are not trying to make the software all things to all users. Use cases which are far afield from the things the majority of users do with the Zero Engine often face substantial barriers.
Zero is primarily targeted at video game and simulation development. We are most likely to design, build, and prioritize features which serve these types of projects.
Zero is primarily targeted at software professionals and other professionals with adjacent responsibilities (like project management and operations). Particularly, we assume users are proficient computer users and familiar with software development concepts. We are most likely to design, build and prioritize features which serve these users.
Zero is secondarily targeted at educational users and has supported many curriculums over the years.
Phabricator is not limited to these kinds of organizations, users and use cases, but features which are aimed at a different group of users (like casual projects, or inexperienced computer users) may be harder to get upstreamed. Features aimed at very different groups of users (like architects, room planning, or dog walking) will be much harder to get upstreamed.
In many cases, a feature makes something better for all users. For example, suppose we fixed an issue where colorblind users had difficulty doing something. Dogs would benefit the most, but colorblind human users would also benefit, and no one would be worse off. If the benefit for core users is very small these kinds of features may be hard to prioritize, but there is no exceptional barrier to getting them upstreamed.
In other cases, a feature makes something better for some users and worse for other users. These kinds of features face a high barrier if they make the software better at dog walking and worse at reviewing code.
We have a lot of users and a small team. Even if your feature is something we're interested in and is a good fit for where we want the product to go, it may take us a long time to get around to building it.
We work full time on Phabricator, and our long-term roadmap has many years worth of work. Your feature request is competing against many other requests for priority.
In general, we try to prioritize work that will have the greatest impact on the most users. Many feature requests are perfectly reasonable requests, but have very little impact, impact only a few users, and/or are complex to develop and support relative to their impact. It can take us a long time to get to these.
Even if your feature request is simple and has substantial impact for a large number of users, the size of the request queue means that it is mathematically unlikely to be near the top. We reprioritize frequently and can not accurately predict when we'll build a feature which isn't very near to top of the queue.
As a whole, this means that the overwhelming majority of feature requests will sit in queue for a long time without any updates, and that we won't be able to give you any updates or predictions about timelines. One day, out of nowhere, your feature will materialize. That day may be a decade from now. You should have realistic expectations about this when filing a feature request.
When you file a feature request, we need you to describe the problem you're facing first, not just your desired solution. Describing the problem you are facing is the most important part of a feature request.
Often, your problem may have a lot in common with other similar problems. If we understand your use case we can compare it to other use cases and sometimes find a more powerful or more general solution which solves several problems at once.
At other times, we'll have a planned solution to the problem that might be different from your desired solution but accomplish the same goal. Understanding the root issue can let us merge and contextualize things.
Sometimes there's already a way to solve your problem that might just not be obvious.
Finally, your proposed solution may not be compatible with the direction we want to take the product, but we may be able to come up with another solution which has approximately the same effect and does fit into the product direction.
If you aren't sure exactly what we're after when we ask you to describe a root problem, you can find examples and more discussion in the links below: