|
|
|
[[_TOC_]]
|
|
## Kotahi Docs Pages
|
|
## Kotahi Docs Pages
|
|
|
|
|
|
### Pages
|
|
### Pages
|
... | @@ -17,3 +18,114 @@ |
... | @@ -17,3 +18,114 @@ |
|
= Miscellaneous notes.
|
|
= Miscellaneous notes.
|
|
|
|
|
|
|
|
|
|
|
|
## Project updates
|
|
|
|
* Description; feature enhancements being made to the platform.
|
|
|
|
* Team; Coko, eLife and Endava team roles and responsibilities.
|
|
|
|
* Ways of working; development coordination and communication.
|
|
|
|
* Weekly updates; progress against milestones.
|
|
|
|
|
|
|
|
### Description (TBC)
|
|
|
|
1. Introducing shared/group manuscript reviews.
|
|
|
|
1. Adding setup configuration in support or alternative workflows, themes and publishing capabilities.
|
|
|
|
|
|
|
|
### Team
|
|
|
|
**Coko**
|
|
|
|
|
|
|
|
| Name | Project role |
|
|
|
|
| --- | ----- |
|
|
|
|
| Adam Hyde | Founder, architectural design oversight |
|
|
|
|
| Ryan Dix-Peek | Proxy-Product Owner |
|
|
|
|
| Ben Whitmore | Senior Developer, technical oversight (Kotahi) |
|
|
|
|
| Yannis Barlas | Lead Developer (Coko) |
|
|
|
|
|
|
|
|
**eLife**
|
|
|
|
|
|
|
|
| Name | Project role |
|
|
|
|
| --- |----- |
|
|
|
|
| Paul Shannon | Head of Technology, architectural design oversight |
|
|
|
|
| Hannah Drury | Product Manager (Sciety), provide insight & end user feedback |
|
|
|
|
|
|
|
|
**Endava**
|
|
|
|
|
|
|
|
| Name | Project role |
|
|
|
|
| --- | ----- |
|
|
|
|
| Yvonne Currie | Delivery Manager |
|
|
|
|
| Vadim Calinin | Project Manager |
|
|
|
|
| Eugeniu Stribitchi | Business Analyst |
|
|
|
|
| Mihai Gorceag | Lead Developer |
|
|
|
|
| Sergiu Cociug | Developer |
|
|
|
|
| Ion Riciu | Developer |
|
|
|
|
| Mnicoleta Ursu | Developer |
|
|
|
|
| Ilia Eriomenco | DevOps |
|
|
|
|
| Sebastian Rad | Tester |
|
|
|
|
| Beatrice Suarasan | Tester |
|
|
|
|
|
|
|
|
|
|
|
|
### Ways of working
|
|
|
|
* Teams work across the following times zones;
|
|
|
|
* UTC; Hannah, Yvonne & Paul.
|
|
|
|
* UTC +2; Endava team, Yannis & Ryan.
|
|
|
|
* UTC +13; Adam & Ben.
|
|
|
|
|
|
|
|
* Communication channels;
|
|
|
|
* Gitlab; via Issues for development tasks and project updates.
|
|
|
|
* Mattermost; for support help regarding project tasks, goals and deliverables.
|
|
|
|
* Microsoft Teams; for all synchronous meetings.
|
|
|
|
|
|
|
|
* Daily Stand Up (planning) and Daily Retrospectives (reviews);
|
|
|
|
* DSU;
|
|
|
|
* Discussion and assigning development work.
|
|
|
|
* Updates for development work not deployed.
|
|
|
|
* Slicing tasks into daily deliverable tasks.
|
|
|
|
* DR;
|
|
|
|
* Review of deployments by developers.
|
|
|
|
* Demo of features deployed by developers.
|
|
|
|
* Updates on the work which has not been completed.
|
|
|
|
* Answer 'what was great about today?' and 'what can I try differently tomorrow'.
|
|
|
|
|
|
|
|
### Gitlab
|
|
|
|
* Gitlab is our main tool for development and project management.
|
|
|
|
* Work is organised in issues with labels.
|
|
|
|
* Anyone on the project team can create an issue.
|
|
|
|
* Stories are broken down into issues. **When creating issues;**
|
|
|
|
* Each issue should be documented separately.
|
|
|
|
* Describe the purpose of the issue clearly.
|
|
|
|
* Provide enough information to cover any expected follow-up questions.
|
|
|
|
* Include links, images, and other supporting material when possible.
|
|
|
|
* Label the issue appropriately (see 'Labels' definition in Gitlab>Issues>Labels).
|
|
|
|
* @mention and assign the responsible person.
|
|
|
|
* Mention if the issue is time sensitive or blocking your work in some way.
|
|
|
|
* If you're logging a bug, include screenshots and the steps to reproduce the error.
|
|
|
|
* Issues are development tasks to be completed with a working day (max 2 days) that contribute to the completion of a user story.
|
|
|
|
* A **stories definition of 'ready';**
|
|
|
|
1. Business description present in a format of "As a < type of user >, I want < some goal > so that < some reason >".
|
|
|
|
1. Acceptance criteria are written.
|
|
|
|
1. Expected result (both happy and unhappy path) described.
|
|
|
|
1. UI mockup prepared (if needed).
|
|
|
|
1. API definition / endpoints are ready.
|
|
|
|
1. Documentation attached to the story (e.g. sequence design) is relevant and up to dates
|
|
|
|
1. Story was refined
|
|
|
|
1. Dependencies eliminated
|
|
|
|
1. Priority set
|
|
|
|
* A **stories definition of 'done';**
|
|
|
|
1. All workflow steps are done.
|
|
|
|
1. Unit tests executed.
|
|
|
|
1. Automated integration tests written.
|
|
|
|
1. Test coverage respected.
|
|
|
|
1. Tooling agreement respected.
|
|
|
|
1. Story is presentable on prod environment.
|
|
|
|
1. Test execution passed (all acceptance criteria are met).
|
|
|
|
1. Documentation updated.
|
|
|
|
1. All critical defects related to the story are fixed.
|
|
|
|
|
|
|
|
### Development workflow
|
|
|
|
* Boards;
|
|
|
|
* Endava Development; all tasks to be assigned to the Endava team.
|
|
|
|
* Development; all tasks assigned to the Coko team.
|
|
|
|
* Labels (Workflow);
|
|
|
|
1. **Backlog;** feature stories. Issues in the Backlog can be unassigned.
|
|
|
|
1. **To-do;** story is ready to be prioritised and assigned to a Developer.
|
|
|
|
1. **Dev in progress / Blocked;** Developer work in progress. Blocked =
|
|
|
|
Development work that cannot proceed until a story, specification or related issue (dependency) is resolved.
|
|
|
|
1. **Testing in progress;** commit has been deployed to production and the Tester is conducting testing.
|
|
|
|
1. **Closed;** testing passed and merged with `main` branch. |