Skip to content

Home

Jump to bottom
squapp edited this page Jul 21, 2015 · 5 revisions

OCDM Project Workflow

Issues

Issues consist of two things:

  • Title (max. 80 characters)
  • Description

After the review of an Issue an assignment of Type and Severity takes place. In practice, appropriate labels are assigned to the Issue. Following possible weighted values will have influence on the handling of the Issue

  • The type weight factors, one of the following:
  • Type: duplicate (*0)
  • Type: wontfix (*0)
  • Type: invalid (*0)
  • Type: question (*1)
  • Type: feature request (*2)
  • Type: enhancement (*3)
  • Type: bug (*4)
  • The severity weight factor, one of the following
  • Severity: low priority (*1)
  • Severity: high priority (*2)
  • Severity: critical (*3)
  • Severity: blocking (*4)

In addition, the reviewer adds a further label (e.g. a component name, a product name or organisational declaration) derived from the issue title/description. A list of all available currently used labels can be viewed at the labels page

Let's assume we have a Decoder component. An filed issue for this component gets after review the labels bug and blocking which in product will rate this issue with 4 * 4 = 16. This two-dimensional weight product allows for estimations with respect to the Milestones.

Milestones

Milestones are groups of issues that correspond the targeted release of a component or version. A Milestone is reached if All Issues related to the Milestone are closed on time.

Testing

We expect tests to be written before or while patches/features are developed. Please ensure to point either to a n included Web browser based test (Test page) or appropriate unit tests with your pull requests.

Contribution

5-step-contribution-workflow

  1. File Issue Start your work by filing an Issue.
  2. Write a test Ideally, you write a test in advance to your development (see prior section). Of course, adjustments can/will occur.
  3. Do the work
  4. Start from a clean (feature) branch on your fork!
  5. Code. Commit often. Check coding style
  6. Push to your branch to your public fork.
  7. Raise PR Raise a Pull request. State against which Issue you are raising the PR (Reference the issue, using hashmarks). Point to tests.
  8. The integrator/reviewer will merge/reject the PR. Tests will help to judge.

Mainly, this workflow follows the Integration-Manager-Workflow.

Communication

Besides utilizing GitHub's 'issues' feature this project communicates via the 'opencdm' Google group: https://groups.google.com/d/forum/opencdm.

Clone this wiki locally