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:
parent
a9e8e03524
commit
a8e247528c
1 changed files with 41 additions and 0 deletions
|
@ -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
|
||||
==========================
|
||||
|
||||
|
|
Loading…
Reference in a new issue