Describing Root ProblemsPhorge Contributor Documentation (Contributing in Detail)
Explains how to describe a root problem effectively.
We receive many feature requests with poor problem descriptions. You may have filed such a request if you've been sent here. This document explains what we want, and how to give us the information to help you.
We will never implement a feature request without first understanding the root problem.
Good problem descriptions let us answer your questions quickly and correctly, and suggest workarounds or alternate ways to accomplish what you want.
Poor problem descriptions require us to ask multiple clarifying questions and do not give us enough information to suggest alternate solutions or workarounds. We need to keep going back and forth to understand the problem you're really facing, which means it will take a long time to get the answer you want.
We want a description of your overarching goal. The problem you started trying to solve first, long before you decided what feature you needed.
This doesn't need to be very detailed, we just need to know what you are ultimately hoping to accomplish.
Problem descriptions should include context and explain why you're encountering a problem and why it's important for you to resolve it.
Here are some examples of good ways to start a problem description:
All of these descriptions are helpful: the provide context about what goals you're trying to accomplish and why.
Here are some examples of ways to start a problem description that probably are not very good:
These problem descriptions are not helpful. They do not describe goals or provide context.
If you're having trouble understanding what we're asking for, one technique which may help is ask yourself "Why?" repeatedly. Each answer will usually get you closer to describing the root problem.
I want custom keyboard shortcuts.
This is a very poor feature request which does not describe the root problem. It limits us to only one possible solution. Try asking "Why?" to get closer to the root problem.
Why? I want to add a shortcut to create a new task.
This is still very poor, but we can now think about solutions involving making this whole flow easier, or adding a shortcut for exactly this to the upstream, which might be a lot easier than adding custom keyboard shortcuts.
It's common to stop here and report this as your root problem. This is not a root problem. This problem is only slightly more general than the one we started with. Let's ask "Why?" again to get closer to the root problem.
Why? I create a lot of very similar tasks every day.
This is still quite poor, but we can now think about solutions like a bulk task creation flow, or maybe point you at task creation templating or prefilling or the Conduit API or email integration or Doorkeeper.
Why? The other developers email me issues and I copy/paste them into Maniphest.
This is getting closer, but still doesn't tell us what your goal is.
Why? We set up email integration before, but each task needs to have specific projects so that didn't work and now I'm stuck doing the entry by hand.
This is in the realm of reasonable, and likely easy to solve with custom inbound addresses and Herald rules, or with a small extension to Herald. We might try to improve the documentation to make the feature easier to discover or understand.
You could (and should) go even further than this and explain why tasks need to be tagged with specific projects. It's very easy to provide more context and can only improve the speed and quality of our response.
Note that this solution (Herald rules on inbound email) has nothing to do with the narrow feature request (keyboard shortcuts) that you otherwise arrived at, but there's no possible way we can suggest a solution involving email integration or Herald if your report doesn't even mention that part of the context.
Poor problem descriptions are a common issue in software development and extensively documented elsewhere. Here are some additional resources describing how to describe problems and ask questions effectively:
Asking good questions and describing problems clearly is an important, fundamental communication skill that software professionals should cultivate.
- returning to Contributing Feature Requests.