Changeset View
Changeset View
Standalone View
Standalone View
source/contributor-guide/feature-requests/index.rst
- This file was added.
.. _contributor-guide-feature-requests: | |||||
================ | |||||
Feature Requests | |||||
================ | |||||
The Definition of a Feature Request | |||||
=================================== | |||||
A feature request is a description of a problem space for which we may seek the | |||||
resolution to be provided within, or with the help of, Kolab. | |||||
Such a problem space is articulated in and by itself, and allows for | |||||
understanding to be formed and interpretation to be fine-tuned over the course | |||||
of a process with multiple parties contributing. | |||||
.. IMPORTANT:: | |||||
Using **problem spaces** re-inforces the importance of the human | |||||
experience for the final product enhancement. | |||||
A bad example of a feature request would be: | |||||
*Make the button background red.* | |||||
This example neither addresses the actual problem, nor the potential value of a | |||||
resolution. | |||||
A better example would be: | |||||
*The contrast between the button background and page is too low.* | |||||
Any target use-case or workflow described must be considered only as a context | |||||
establishing a higher level of comprehension in elaboration, about the | |||||
dimensions of the problem space. Per the existing example: | |||||
*Color vision deficiencies do not allow some people to distinguish the | |||||
button from the background.* | |||||
This would allow us to clarify whether a high-contrast UI is needed, or a | |||||
slight adjustment suffices. We would also get to cover other angles. | |||||
Feature requests without a sufficiently accurate or encompassing description of | |||||
the problem space to address will not be accepted. | |||||
Where Do Feature Requests Go? | |||||
============================= | |||||
Feature requests can be entered in to the Kolab development platform using | |||||
`this form <https://git.kolab.org/maniphest/task/edit/form/12/>`_. | |||||
It's submitted to the backlog of the :red:`Architecture & Design` team. | |||||
The `Architecture & Design`_ team evaluates the enhancement requests, requests | |||||
additional feedback if needed, and assigns the priority should the request be | |||||
promoted. | |||||
The responsibility of this team is to ensure that, in the inception phase, and | |||||
before the elaboration phase; | |||||
petersen: According to the bullet points under this, it is actually "before the Elaboration phase" rather… | |||||
Not Done Inline ActionsOK, I'll change this. I like the analogous terminology used, I'll put that in as a note with the to-be-authored list below. vanmeeuwen: OK, I'll change this.
I like the analogous terminology used, I'll put that in as a note with… | |||||
* we have an accurate and full problem space description, and | |||||
* we understand the scope and dimensions of the problem space, and | |||||
* we can successfully determine where the problem should be resolved, and | |||||
* we can determine the resolution to this problem space makes sense for the | |||||
product that is Kolab, or | |||||
* we can determine that the problem space is better addressed by existing, | |||||
external tooling, and find a means for that external tooling to be | |||||
integrated with Kolab, or | |||||
* we can determine that addressing the problem space does not enhance the | |||||
Kolab product, and | |||||
* an estimate value of resolving the problem space can be established. | |||||
This leads to a common understanding of scope of delivery, the definition of | |||||
done, and the way to verify the results. | |||||
**Backlog** | |||||
All feature enhancement requests put forth. Mostly with wishlist priority. | |||||
**Inception** | |||||
Would this change the world? How would this change the world? | |||||
**Elaboration** | |||||
How do we change the world? | |||||
**Construction** | |||||
The hardhats get to putting the brick and mortar in place. | |||||
**Transition** | |||||
.. This part of the process is called :ref:`developer-guide-process-inception`. |
According to the bullet points under this, it is actually "before the Elaboration phase" rather than the Construction phase.
In teh elaboration phase we decide how to change the world with this task, where as the Construction phase is pure hardhats, bricks and mortar.