@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.)
hq.recaptime.dev/wiki/Phorge
phorge
phabricator
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
+41
+41
src/docs/contributor/feature_requests.diviner
+41
src/docs/contributor/feature_requests.diviner
···
160
160
contextualize, merge, reframe, or offer alternative solutions or workarounds.
161
161
162
162
163
+
Hypotheticals
164
+
=============
165
+
166
+
We sometimes receive hypothetical feature requests about anticipated problems
167
+
or concerns which haven't actually occurred yet. We usually can't do much about
168
+
these until the problems actually occur, since the context required to
169
+
understand and properly fix the root issue won't exist.
170
+
171
+
One situation where this happens is when installs are thinking about adopting
172
+
Phabricator and trying to guess what problems users might encounter during the
173
+
transition. More generally, this includes any request like "if users do **X**,
174
+
they might find **Y** confusing", where no actual users have encountered
175
+
confusion yet.
176
+
177
+
These requests are necessarily missing important context, maybe including the
178
+
answers to questions like these:
179
+
180
+
- Why did users do **X**?
181
+
- What were they trying to do?
182
+
- What did they expect to happen?
183
+
- How often do users do this?
184
+
185
+
The answers to these questions are important in establishing that the issue is
186
+
really a problem, figuring out the best solution for it, and prioritizing the
187
+
issue relative to other issues.
188
+
189
+
Without knowing this information, we can't be confident that we've found a good
190
+
solution to the problem, can't know if we've actually fixed the problem, and
191
+
can't even know if the issue was really a problem in the first place (some
192
+
hypothetical requests describe problems which no users ever encounter).
193
+
194
+
We usually can't move forward without this information. In particular, we don't
195
+
want to spend time solving hypothetical problems which no real users will ever
196
+
encounter: the value of those changes is zero (or negative, by making the
197
+
product more complex without providing a benefit), but they consume development
198
+
time which could be better spent building much more valuable features.
199
+
200
+
Generally, you should wait until a problem actually occurs before filing a
201
+
request about it.
202
+
203
+
163
204
Create a Task in Maniphest
164
205
==========================
165
206