Skip to content

GitLab

Kotahi
Kotahi
Last edited by Ryan Dix-Peek
Page history

Home

Kotahi Docs Pages

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.

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

  1. Introducing shared/group manuscript reviews.
  2. 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
Mihail 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 tasks definition of 'ready';
    1. 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 >".
    2. Acceptance criteria are written.
    3. Expected result (both happy and unhappy path) described.
    4. UI mockup prepared (if needed).
    5. API definition / endpoints are ready.
    6. Documentation attached to the story (e.g. sequence design) is relevant and up to dates
    7. Task was refined
    8. Dependencies eliminated
    9. Priority set

  • A task definition of 'done';
    1. All workflow steps are done.
    2. Unit tests executed.
    3. Automated integration tests written.
    4. Test coverage respected.
    5. Tooling agreement respected.
    6. Feature is presentable on prod environment.
    7. Test execution passed (all acceptance criteria are met).
    8. Documentation updated.
    9. All critical defects related to the feature 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. Only issues in the Backlog can remain unassigned.
    2. To-do; story is ready to be prioritised and assigned to a Developer.
    3. Dev in progress / Blocked; Developer work in progress. Blocked = Development work that cannot proceed until a story, specification or related issue (dependency) is resolved.
    4. Testing in progress; commit has been deployed to production and the Tester is conducting testing. Commits to include comments as per format provided.
    5. Closed; testing passed and merged with main branch.

Milestones (TBC)

  1. DevOps - Permanent prod environment creation
  2. eLife MVP
  3. Novel Coronavirus Research Compendium (NCRC) MVP
  4. Biophysics Collab MVP