- Kotahi Docs Pages
- Project updates
Kotahi Docs Pages
Overview = An overview of the platform, its spaces and design principles.
Using Kotahi = Simple workflow to follow to try out Kotahi. Contains demo videos.
Kotahi Admin = Some items that only the Kotahi Admin has access to.
Workflows = How Kotahi supports different workflows from journals, to micropubs, to pre-prints and more...
Additional Notes = Miscellaneous notes.
- 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.
- Introducing shared/group manuscript reviews.
- Adding setup configuration in support or alternative workflows, themes and publishing capabilities.
|Adam Hyde||Founder, architectural design oversight|
|Ryan Dix-Peek||Proxy-Product Owner|
|Ben Whitmore||Senior Developer, technical oversight (Kotahi)|
|Yannis Barlas||Lead Developer (Coko)|
|Paul Shannon||Head of Technology, architectural design oversight|
|Hannah Drury||Product Manager (Sciety), provide insight & end user feedback|
|Yvonne Currie||Delivery Manager|
|Vadim Calinin||Project Manager|
|Eugeniu Stribitchi||Business Analyst|
|Mihail Gorceag||Lead Developer|
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);
- Discussion and assigning development work.
- Updates for development work not deployed.
- Slicing tasks into daily deliverable tasks.
- 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 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 tasks definition of 'ready';
- Business description present in a format a feature description or user story "As a < type of user >, I want < some goal > so that < some reason >".
- Acceptance criteria are written.
- Expected result (both happy and unhappy path) described.
- UI mockup prepared (if needed).
- API definition / endpoints are ready.
- Documentation attached to the story (e.g. sequence design) is relevant and up to dates
- Task was refined
- Dependencies eliminated
- Priority set
- A task definition of 'done';
- All workflow steps are done.
- Unit tests executed.
- Automated integration tests written.
- Test coverage respected.
- Tooling agreement respected.
- Feature is presentable on prod environment.
- Test execution passed (all acceptance criteria are met).
- Documentation updated.
- All critical defects related to the feature are fixed.
- Endava Development; all tasks to be assigned to the Endava team.
- Development; all tasks assigned to the Coko team.
- Labels (Workflow);
- Backlog; feature stories. Only issues in the Backlog can remain unassigned.
- To-do; story is ready to be prioritised and assigned to a Developer.
- Dev in progress / Blocked; Developer work in progress. Blocked = Development work that cannot proceed until a story, specification or related issue (dependency) is resolved.
- Testing in progress; commit has been deployed to production and the Tester is conducting testing. Commits to include comments as per format provided.
Closed; testing passed and merged with