-
Notifications
You must be signed in to change notification settings - Fork 0
Contribution Guidelines
The aim of these guidelines is to create a streamlined process for coordinating development effort and reducing duplicate effort.
Issues and pull requests are used to coordinate work. They make up a tree where the root nodes are tests from the SIDP documentation. The second layer of issues are deliverables which are verified by the tests in the first layer. These issues might be broken into sub-issues, but the leaf nodes are always pull requests, and these encapsulate work.
Illustrated below:
+---------+ +-----------+ +------------+
|test case+-+-> |deliverable+---------------> |pull request|
+---------+ | +-----------+ +------------+
+
+---------+ | +-----------+ +-----+ +------------+
|test case+-+-> |deliverable+---> |issue+---> |pull request|
+---------+ +-----------+ +-----+ +------------+
+---------+ +-----------+ +-----+ +------------+
|test case+-+-> |deliverable+---> |issue+---> |pull request|
+---------+ | +-----------+ +-----+ +------------+
|
| +-----------+ +-----+ +------------+
+-> |deliverable+---> |issue+-+-> |pull request|
+-----------+ +-----+ | +------------+
|
| +------------+
+-> |pull request|
+------------+
Test -- Deliverable -- n * (Sub issue (optional)) -- Pull Request
This tag denotes an issue which is a test case as described in this google sheet.
This tag recognises an issue which is a deliverable as desribed in ass2 SIDP doc.
Issues which contain work which cannot be completed by one pull request must be broken into smaller issues. Issues may only have one parent, but multiple sub-issues.
A pull request must be small and encapsulate less than 4 hours of work. You should be able to describe what the purpose is without using the word 'and'. If this is the case then the issue it belongs to needs to be broken up. Pull requests must belong to exactly issue.
The first comment on a deliverable must include a list of required functionality which must be implemented to satisfy the deliverable. An example of this is #30. Each of the items in this list is either a sub-issue or a pull request which implements this functionality. Once all the items in the list are complete, the deliverable is complete.