|
|
![logo](../images/oai_final_logo.png)
|
|
|
|
|
|
---
|
|
|
|
|
|
# OAI Software Alliance Ticket Policy #
|
|
|
|
|
|
----
|
|
|
|
|
|
## Table of Contents ##
|
|
|
|
|
|
1. [New Feature Development](#1-new-feature-development)
|
|
|
2. [Existing Feature improvement](#2-existing-feature-improvement)
|
|
|
1. [Creation of an improvement ticket](#21-creation-of-an-improvement-ticket)
|
|
|
2. [Closure of an improvement ticket](#22-closure-of-an-improvement-ticket)
|
|
|
3. [Bug Tracking](#3-bug-tracking)
|
|
|
1. [Creation of an issue ticket](#31-creation-of-an-issue-ticket)
|
|
|
2. [Assessment of the issue](#32-assessment-of-the-issue)
|
|
|
3. [Closure of the issue](#33-closure-of-the-issue)
|
|
|
|
|
|
----
|
|
|
|
|
|
A ticket refers to a task that requires work. It may be
|
|
|
|
|
|
* A new feature development
|
|
|
* An existing feature improvement
|
|
|
* A bug being detected that needs a resolution
|
|
|
|
|
|
The latter 2 task types are using the Git Repository Issues tracker under GitLab or GitHub.
|
|
|
|
|
|
# 1. New Feature Development #
|
|
|
|
|
|
A new feature development is decided by the OSA Strategic Board with given scope, resources and timeline.
|
|
|
Timeline should be divided into intermediate milestones.
|
|
|
|
|
|
Usually development is tracked using one of the OAI development [Trello boards](https://trello.com/oaidev).
|
|
|
|
|
|
A feature branch is dedicated to the development as described in [Feature branches](policy/branch#2-feature-branches).
|
|
|
|
|
|
# 2. Existing Feature improvement #
|
|
|
|
|
|
Improvements may be:
|
|
|
* Performance enhancement
|
|
|
* Memory footprint or
|
|
|
* Processing speed-up
|
|
|
* Code Clean-Up
|
|
|
* Dead-code removal
|
|
|
* Beautifying task
|
|
|
* File tree organization
|
|
|
|
|
|
## 2.1. Creation of an improvement ticket ##
|
|
|
|
|
|
Templates are usually available to help at the creation. However the following information **SHALL** be provided.
|
|
|
|
|
|
* Short title
|
|
|
* Add a proper description of the requested task
|
|
|
* Indicate if the task is repository-wide
|
|
|
* Task **SHALL** be assigned
|
|
|
* Labels **SHALL** be added:
|
|
|
* At least the kind of improvement:
|
|
|
* enhancement
|
|
|
* code cleanup
|
|
|
* If the improvement is not repository wide, indicate the functional part affected with a label
|
|
|
* create a new label if needed
|
|
|
* A **END-DATE SHALL** be scheduled
|
|
|
* Under GitLab it is called 'due date'
|
|
|
* Under GitHub you have to use milestone
|
|
|
|
|
|
The Technical Committee regularly monitors the creation of issues and may ask the ticket creator to follow the creation rule.
|
|
|
|
|
|
A enhancement branch is dedicated to the development as described in [Feature branches](policy/branch#2-feature-branches).
|
|
|
|
|
|
## 2.2. Closure of an improvement ticket ##
|
|
|
|
|
|
# 3. Bug Tracking #
|
|
|
|
|
|
Issues are found by OAI users, contributors, integrators.
|
|
|
|
|
|
## 3.1. Creation of an issue ticket ##
|
|
|
|
|
|
Templates are usually available to help at the creation. However the following information **SHALL** be provided.
|
|
|
|
|
|
* Short title
|
|
|
* Add a proper description of the found issue
|
|
|
* Indicate how to reproduce it --> It will be the skeleton on how to validate the fix
|
|
|
* Indicate the code version:
|
|
|
* Release TAG
|
|
|
* Branch
|
|
|
* Commit ID
|
|
|
* Labels **SHALL** be added:
|
|
|
* Bug **SHALL** be present
|
|
|
* If the issue is located, indicate the functional part affected with a label
|
|
|
* create a new label if needed
|
|
|
* A **NEED-DATE SHALL** be added
|
|
|
* Under GitLab it is called 'due date'
|
|
|
* Under GitHub you have to use milestone
|
|
|
|
|
|
The Technical Committee regularly monitors the creation of issues and may ask the ticket creator to follow the creation rule.
|
|
|
|
|
|
## 3.2 Assessment of the issue ##
|
|
|
|
|
|
The Technical Committee regularly monitors the issue list.
|
|
|
It will assess if the reported issue is valid. The reasons to decline an issues are (non-exclusive):
|
|
|
|
|
|
* Incorrect use case
|
|
|
* Duplicate
|
|
|
* Bug fixed in later version
|
|
|
* User / Contributor shall be warned to the version to use/merge with.
|
|
|
|
|
|
Once the issue is deemed valid by the Technical Committee, it shall assign someone to it.
|
|
|
A dedicated fix branch is dedicated to the development as described in [Bug-fix branches](policy/branch#3-bug-fix-branches).
|
|
|
|
|
|
## 3.3. Closure of the issue ##
|
|
|
|