... | ... | @@ -23,7 +23,7 @@ In phase 1 the priority must always be to develop the simplest implementation to |
|
|
|
|
|
All issues (features and bugs) for scoping are on the [Backlog board](https://gitlab.coko.foundation/ncbi/ncbi/-/boards/605)
|
|
|
|
|
|
### The **Scoping phases**:
|
|
|
### The **Scoping phases**:
|
|
|
|
|
|
1. Backlog →
|
|
|
2. Research (requirements and implementation approach) →
|
... | ... | @@ -56,13 +56,13 @@ All issues (features and bugs) for scoping are on the [Backlog board](https://gi |
|
|
|
|
|
When changes are requested after approval, the issue is weighted again and any other impacts on the schedule are documented. Change requests should only be accepted if they are critical to Phase 1.
|
|
|
|
|
|
## Development
|
|
|
## Development
|
|
|
|
|
|
All issues ready for development are on the [Development Board](https://gitlab.coko.foundation/ncbi/ncbi/-/boards/324)
|
|
|
|
|
|
Development begins on the issue when the relevant cycle starts (See [Milestone](https://gitlab.coko.foundation/ncbi/ncbi/-/milestones)). Dione may reschedule an issue if the scope changes.
|
|
|
|
|
|
### Development phases:
|
|
|
### Development phases:
|
|
|
|
|
|
Issues are added to the Dev board after scope approval and weighting. Any issue in the "Dev to do" can be picked up, but the priority are the issues in the the current milestone.
|
|
|
|
... | ... | @@ -76,7 +76,7 @@ Issues are added to the Dev board after scope approval and weighting. Any issue |
|
|
|
|
|
Dev is 'done' when it its been tested and meets the sign-off criteria in the issue description.
|
|
|
|
|
|
#### How we manage branches:
|
|
|
#### 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.
|
... | ... | @@ -96,6 +96,61 @@ When NCBI has completed testing against the sign-off criteria, Let Dione know in |
|
|
|
|
|
### Testing agreements
|
|
|
|
|
|
#### Communiticating releases and feedback
|
|
|
|
|
|
Coko creates a testing issue for NCBI when there is a new release – at minimum every two weeks so issues don’t build up.
|
|
|
|
|
|
Coko notes in that issue an exact checklist of new things ready to test in structure of (see proposed key for a common language to use about workflow and file types for all testers to understand):
|
|
|
|
|
|
> * Feature A for User to do X in workflow 1 and 2 only - this relates to following User Story (Epic and checklist story item)
|
|
|
> * Feature B for User to do Y in workflow 3a only - this relates to following User Story (Epic and checklist story item)
|
|
|
> * Action A for User to process file type Z in workflow 2a - this relates to following User Story (Epic and checklist story item)
|
|
|
|
|
|
Coko also notes in that issue exactly which bugs and improvements they would like NCBI to test – these bug and improvement issues should be focused on usability and things we can do in the UI or actions we can test in terms of processing, etc.
|
|
|
|
|
|
Record these bugs and improvements as:
|
|
|
|
|
|
>Please check following bugs and improvements:
|
|
|
>
|
|
|
>Bug 1 – if relevant, this relates to the following User Story (Epic and checklist story item)
|
|
|
>Improvement 2
|
|
|
|
|
|
|
|
|
NCBI provides feedback for releases in form of:
|
|
|
|
|
|
1. New bug ticket using Coko bug issue template IF new bug - Feature A or Action B does not work as expected - user cannot do X or Y in workflow 1
|
|
|
2. New improvement ticket using Coko New Feature issue template if we think something could be improved - Feature A works but it is confusing because of Z and we really think it would be better if it could do D because ....
|
|
|
3. Reopen existing ticket if still does not do as expected (Bug tickets should state what should be expected from a user point of view)
|
|
|
4. Reopen existing improvement ticket if it still does not reduce what was confusing or difficult (Feature tickets should state this clearly in the description)
|
|
|
5. If NCBI has questions about the build or was not able to test something they will note this in the Release testing ticket and will not close it until response from Coko in case based on their response they can test it, and so on until everything is resolved.
|
|
|
|
|
|
(Note: As discussed in DDWG, only critical "New improvement" issues can be addressed for the initial release.)
|
|
|
|
|
|
##### Terminology
|
|
|
|
|
|
Proposed key for everyone to use for communicating contexts NCBI must know to complete testing
|
|
|
|
|
|
**Workflow Key**
|
|
|
|
|
|
* Word workflow
|
|
|
* PDF wholebook workflow
|
|
|
* PDF chapter-processed workflow
|
|
|
* XML wholebook workflow
|
|
|
* XML chapter-processed workflow
|
|
|
|
|
|
**File Types Key**
|
|
|
|
|
|
* FTP submission (make sure everyone has representative samples of types of FTP submissions - one file, multiple files, etc)
|
|
|
* Manual upload (make sure everyone has representative samples of types of manual submissions - one file, multiple files, etc)
|
|
|
* Funded content (needs to be noted if manual and/or FTP submission because of key matching and integrity issues)
|
|
|
|
|
|
**Additional Critical contexts**
|
|
|
|
|
|
* Database type documents (chapter-processed with database source type)
|
|
|
* Book (book processed)
|
|
|
* Contributed chapters (chapter-processed content in a book source type)
|
|
|
* Content belonging to a collection (regular series or funded collection also needs to be noted)
|
|
|
|
|
|
#### NCBI review site
|
|
|
|
|
|
* The current ncbi.coko.foundation will move a new URL managed by our hosting partners to allow daily backups and migrations for each release.
|
... | ... | |