2. Developer Guideline

This document serves as the guideline for any development practice in this repository.

🏗️ Development Workflow

We generally follow this standard operating procedure so that the community can be made aware of our recent plan and progress. It should be noted that our core values should be upheld during development.

1. Propose a development plan in the discussion forum

Any new feature should be discussed and evaluated first. The feature discussion should be kickstarted in the discussion forum. Development discussions should be only put inside the development categories. Other categories are dedicated to users.

A detailed plan should be included in the discussion post, better with charts/diagrams/tables. The discussion post should also cover 5W1H (what, why, where, which, who and how) so that other developers can understand what is discussed.

A roadmap and work breakdown should be included in the discussion as well to facilitate the steps below.

2. Label your discussion

You should label your discussion. For example, if you want to include other developers in your plan, you can label your discussion with welcome contribution.

3. Create a project kanban to manage the relevant tasks

The kanban can be created and viewed in the projects tab. A project should be referenced in the discussion post.

A list of issues should be created with reference to the work breakdown. Each issue should be associated with assignee, project and label. You can view this document on how to link your issue with the project if the issue is not linked.

You should clearly describe the issue such that other developers understand the problem, motivation and possible solutions.

4. Create pull requests

Implement your code and create a pull request to the repository. Remember to link your pull request to the issue and project kanban. You can refer to this document on how to link the pull request to issue.

5. Code review

You can request for code review from the developer team.

6. Merge

The pull request is allowed to merge only if all workflows are successful. Only squash merge is allowed.

7. Update documentations

You should update related documentations when a feature is completed. There are two types of documentations to be updated:

• User documentation: Go to docs/ to add the documentation of your feature. This is to tell our users how the feature can be properly used and any possible limitations. Do follow the standard operating procedure for adding a doc in the README.md file.

• Developer documentation: Go to Developer Docs and add a section regarding your feature. You should include design description, diagrams, implementation details, benchmarking results, compatibility support matrix, etc.

Some other good practices are also included in CONTRIBUTING.md.

⛵ Onboarding

For any new developer, please read on the Developer Docs to understand our design and implementations.

👋 Join Development

If you want to join the development, you can join our community development group on slack. Our developer will engage with you to check if you can contribute to any ongoing or planned tasks. We will acknowledge all contributors by displaying the GitHub user profile picture on our Project README.md.

🔨 CI & CD

We rely on GitHub Actions to automate many repetitive tasks for our developers. Please refer to the README.md for more details.