|
|
# Ways of working
|
|
|
|
|
|
[[_TOC_]]
|
|
|
|
|
|
*(Updated 16 April 2021)*
|
|
|
|
|
|
Following the [Phased Proposal](https://gitlab.coko.foundation/ncbi/ncbi/-/wikis/Project-overview/Items-for-dev#update-23-march-2021) (submitted 9 March 2021) the DDWG agreed to include an sign-off process to the current way of working.
|
|
|
|
|
|
## Pre-development sign-off process
|
|
|
|
|
|
### Use case deliverables
|
|
|
|
|
|
These high-level deliverables were provided by NCBI oroject owner (Stacy).
|
|
|
|
|
|
1. Use case deliverable 1: Support for Word and XML chapter-processed content: Issue 450
|
|
|
2. Use case deliverable 2: Support for XML and PDF book-processed content: Issue 451
|
|
|
3. Use case deliverable 3: Permissions, Notifications, and Feature Improvements: Issue 452
|
|
|
4. Use case deliverable 4: Production-ready BCMS for internal staff users, Word authoring teams, PDF2XML vendors, and Bookshelf participant administrators: Issue 453
|
|
|
|
|
|
Coko Project Manager (Dione) has mapped the existing issues for Phase 1 to each deliverable.
|
|
|
|
|
|
### Per issue sign-off criteria
|
|
|
|
|
|
Following Stacy's review of the mapped issues, the sign off criteria are confrimed and agreed on for each issue. These my vary depending on the nature of the issue. When new or significantly adapted UIs are required, an visual walk-though, using roughs designs or demos of development-in-progress, is part of the sign-off process.
|
|
|
|
|
|
#### Sign-off responsibility
|
|
|
|
|
|
* Stacy signs off user stories and their designs
|
|
|
* Evengy or Martin sign off techical specs for integration-related issues
|
|
|
* Dione confirms the sign-off criteria are complete and sufficiently detailed for the developers to proceed.
|
|
|
|
|
|
In cases where NCBI and Coko teams do not agree on the acceptance criteria, these issues should be floated to the DDWG to resolve together.
|
|
|
|
|
|
### Sign-off issues in-progress
|
|
|
|
|
|
These issues can be found on the [Scoping Board](https://gitlab.coko.foundation/ncbi/ncbi/-/boards/605)
|
|
|
|
|
|
* Scoping: issues that are being scoped
|
|
|
* Sign-off criteria review: issues ready for NCBI review and sign-off
|
|
|
* Sign-off criteria approved: Sign-off responsibility complete
|
|
|
|
|
|
## Development workflow
|
|
|
|
|
|
These issues can be found on the [Development Board](https://gitlab.coko.foundation/ncbi/ncbi/-/boards/324)
|
|
|
|
|
|
Development begins on the issue when the relevant cycle starts (See [Project Schedule](https://gitlab.coko.foundation/ncbi/ncbi/-/wikis/Project-overview/project-schedule)). Dione may reschedule an issue if the sign-off criteria are not approved.
|
|
|
|
|
|
The **Development phases**:
|
|
|
|
|
|
1. Backlog feature with sign-off criteria approval →
|
|
|
2. Dev to do →
|
|
|
3. Dev Doing →
|
|
|
4. Blocked (when relevant) →
|
|
|
5. QA →
|
|
|
7. Internal review →
|
|
|
8. Dev Done
|
|
|
8. Closed issues (completed work that has been relased and accepted by NCBI according to the sign-off criteria)
|
|
|
|
|
|
When dev issues are ready for NCBI's testing, Dione will create one issue listing all the relevant issues and documentation when relevant.
|
|
|
|
|
|
Be mindful of the information that the team needs to work with you on an issue and follow **best practices**, such as:
|
|
|
|
|
|
* Show your progress on issues by adding comments and including relevant commit numbers.
|
|
|
* When changing the status of your issues, make sure you add a comment that explains the status change. For example, if your issue status changes from 'doing' to 'blocked', the team will need to know why you are blocked so they can help.
|
|
|
|
|
|
To avoid losing track of documents attached in closed Gitlab issues, save them in the Nextcloud 'NCBI\client-shared' folder for easy access.
|
|
|
|
|
|
#### How we manage branches:
|
|
|
|
|
|
We have two main branches:
|
|
|
* 'master' - the code here is stable and matches with the code of the application that the client sees.
|
|
|
* 'develop' - the code here is less stable than the master branch since it is work-in-progress. Tested code in this branch is merged into 'master' for client reviews.
|
|
|
* Each issue is developed and tested in its own branch before being merged into 'develop'.
|
|
|
|
|
|
## NCBI review
|
|
|
|
|
|
### Testing workflow
|
|
|
|
|
|
Dione provides **one testing handover issue** summarising dev work completed that is ready to test, including links to each relevant issue. Each issue is labelled with a release date for improved searching.
|
|
|
|
|
|
NCBI does testing according to the approved sign-off criteria.
|
|
|
|
|
|
If NCBI disagrees with a completed criteria, their testers untick the criteria and provide a link to a 'bug' issue (with clear steps to reproduce) as a comment in the issue. A ‘bug’ issue comprises some unexpected design or behaviour relevant to the sign-off criteria.
|
|
|
|
|
|
When NCBI has completed testing against the sign-off criteria, Let Dione know in the testing handover issue.
|
|
|
|
|
|
Dione labels each issue as "Dev approved" and closes them.
|
|
|
|
|
|
### Testing agreements
|
|
|
|
|
|
#### For FTP submitted content
|
|
|
|
|
|
*(update in progress)* |