Differential D13663 Diff 33054 src/docs/contributor/feature_requests.diviner

Changeset View

Standalone View

src/docs/contributor/feature_requests.diviner

	Show First 20 Lines • Show All 154 Lines • ▼ Show 20 Lines
	Finally, your proposed solution may not be compatible with the direction we			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			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.			which has approximately the same effect and does fit into the product direction.

	If you only describe the solution and not the problem, we can't generalize,			If you only describe the solution and not the problem, we can't generalize,
	contextualize, merge, reframe, or offer alternative solutions or workarounds.			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			Create a Task in Maniphest
	==========================			==========================

	If you think your feature might be a good fit for the upstream, have reasonable			If you think your feature might be a good fit for the upstream, have reasonable
	expectations about it, and have a good description of the problem you're trying			expectations about it, and have a good description of the problem you're trying
	to solve, you're ready to file a feature request:			to solve, you're ready to file a feature request:

	https://secure.phabricator.com/maniphest/task/create/			https://secure.phabricator.com/maniphest/task/create/
	Show All 15 Lines