Since we are working with lots of different people it is important we record issues in a clear consistent and concrete way, therefore these guidelines should always be followed. (Not just in OMS-General, but in every module)
This page is based on the official JIRA constants page, however, stick to the convention laid out here when working on the OMS project.
Issue types
JIRA is used as an issue tracker, here the term 'issue' is a very vague term, it does not necessarily mean that something is wrong with the software (a bug) but can also be a new feature.
An issue can be one of the following:
...
When filing a new issue, think about what kind of issue it is and if unsure label it as a task.
Story vs Epic
We have had an internal discussion about when to use a story and when to use an epic. The conclusion was that there is no real definition to either or on the difference between them. In the end, we decided to mostly go with epics because these have some extra functionality such as having sub-stories and some filter options in the dashboard. The definition we will use for an epic will be 'A larger concept of a set of features or actions', the definition of a story will be 'A concrete single feature or action, often part of a bigger epic'.
Issue syntax
When creating a new issue please take the following conventions in account:
- Formulate the summary in a short, clear and imperative way
- Add a couch surfing mechanism
- Give newly registered users an O365 account
- Formulate the description in an explaining and natural way
- As an AEGEE-member, I would like to use the OMS to easily find a place to couch surf.
- As a newly registered user, I would like to receive an office-365 account for personal use.
- Add examples and other information at the end of the description
- Make it clear, avoid confusion
Priorities
For the priorities we will use the standard definitions given by JIRA:
...
When in doubt assign the 'Medium' priority
