1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-19 21:32:43 +01:00

Document that hypothetical requests aren't helpful

Summary: Fixes T8908. We sometimes receive hypothetical requests (usually when existing companies are thinking about adopting Phabricator) in the form of "No users have actually done this yet, but bad thing Y might happen". We can almost never move forward with these. Explain this in detail.

Test Plan: Reading.

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: epriestley

Maniphest Tasks: T8908

Differential Revision: https://secure.phabricator.com/D13663
This commit is contained in:
epriestley 2015-07-22 07:14:56 -07:00
parent a9e8e03524
commit a8e247528c

View file

@ -160,6 +160,47 @@ If you only describe the solution and not the problem, we can't generalize,
contextualize, merge, reframe, or offer alternative solutions or workarounds.
Hypotheticals
=============
We sometimes receive hypothetical feature requests about anticipated problems
or concerns which haven't actually occurred yet. We usually can't do much about
these until the problems actually occur, since the context required to
understand and properly fix the root issue won't exist.
One situation where this happens is when installs are thinking about adopting
Phabricator and trying to guess what problems users might encounter during the
transition. More generally, this includes any request like "if users do **X**,
they might find **Y** confusing", where no actual users have encountered
confusion yet.
These requests are necessarily missing important context, maybe including the
answers to questions like these:
- Why did users do **X**?
- What were they trying to do?
- What did they expect to happen?
- How often do users do this?
The answers to these questions are important in establishing that the issue is
really a problem, figuring out the best solution for it, and prioritizing the
issue relative to other issues.
Without knowing this information, we can't be confident that we've found a good
solution to the problem, can't know if we've actually fixed the problem, and
can't even know if the issue was really a problem in the first place (some
hypothetical requests describe problems which no users ever encounter).
We usually can't move forward without this information. In particular, we don't
want to spend time solving hypothetical problems which no real users will ever
encounter: the value of those changes is zero (or negative, by making the
product more complex without providing a benefit), but they consume development
time which could be better spent building much more valuable features.
Generally, you should wait until a problem actually occurs before filing a
request about it.
Create a Task in Maniphest
==========================