Coko Community Products Collaboration Guidelines

Collaboration is crucial for the success of community products such as Ketida and Kotahi. To ensure that all parties involved in the collaboration process are on the same page, a process has been outlined. This process helps to clarify what is trying to be achieved, understand if there are duplicate or complementary features that are already on the roadmap, and solve problems with existing features. In this article, we will outline the process for collaborating on Ketida and Kotahi.

Steps for collaborating on Ketida and Kotahi:

The Proposer approaches the respective Project Manager to discuss the feature:
The Proposer is the person who is proposing a feature for development. The Proposer should approach the respective Project Manager to discuss the feature. This is to help clarify for both parties what is trying to be achieved.
The Proposer writes up the feature as an issue in the project’s GitLab repo:
Once the feature is discussed, the proposer should write it up as an issue in the project’s GitLab repo using the feature proposal template. This outline does not need to be comprehensive, but there should be a description of what the feature is, how it affects workflows and interfaces, and some notes about the technical approach. The proposer should include mocks where appropriate.
The Project Manager discusses the proposal with the Lead Developer for the project:
After the proposal is submitted, the Project Manager should discuss it with the Lead Dev for the project. There may be further consultation with other members of the Coko team, if necessary.
The Project Manager and Lead Developer make comments on the proposal:
Once the proposal is discussed, the Project Manager and Lead Developer should make comments on the proposal. These comments should include suggestions for changes (revisions), if necessary.
Revisions by the Proposer occur if necessary:
If revisions are necessary, the Proposer should make the revisions.
The Project Manager and Lead Developer give a thumbs up:
When the proposal is ready, the Project Manager and Lead Dev should give a thumbs up.
Development begins in a feature branch in the project’s repo:
Once the proposal is approved, development can begin in a feature branch in the project’s repo. The Proposer should push local work to this branch regularly to avoid lost work.
A merge request is made when ready:
When development is complete, a merge request should be made.
The Coko project team check the code and functionality:
The Lead Developer, QA Engineer and Project Manager should check the code and functionality.
Report bugs and make comments for revisions:
If necessary, the Coko project team should report bugs and make comments for revisions.
Revisions occur:
If revisions are necessary, they should be made by the Proposer.
The code is merged by the Lead Developer when ready:
Finally, the code can be merged when ready.

To summarise, successful collaborations require good faith, transparency, and communication. The collaboration guidelines for Ketida and Kotahi have been created to facilitate this by ensuring that all parties involved have a clear understanding of the proposal, development, and merging processes. Importantly, following these guidelines should not cause any delay in development. In fact, if Proposers are ahead of the development team, it can actually accelerate the feature development and delivery process, as there will be less need for large-scale refactors, opportunity for cross-organisational collaboration of specific features, and a reduced likelihood of duplicate efforts.