Development Process

This document explains our values and the development process. If we wish to change this, we should aim to stay simple and concise.

Our values

These values should help us make decisions while working on our projects. It would help us decide which compromise to make (if needed) while looking for a solution for a particular problem.

  1. Security - The system should be resistant to all sorts of attacks. User's data should not be compromised in any case. Malicious actors should not be able to manipulate/corrupt the system in any case.
  2. Reliability - The system should work without bugs/errors. It should work predictably every time, on every platform.
  3. Minimalism/Simplicity - It should have a minimal amount of features to complete a specified task.
  4. Succinctness - The code should be clear and concise, it should be broken down into logical blocks that are contextually correct and easy to understand by everyone (junior or senior, newcomers or old-timers).
  5. Consistency - Practices, conventions, and standards should be applied throughout the codebase.
  6. Performace - The program should require minimal computational resources.

These points should be a guideline in case we have to make a compromise, but if that is not the case, we should aim to satisfy all of them.

Github workflow

We are using Github issues for managing our development flow. There are 3 types of issues: Milestones, Tasks and Discussions:

  • Task - An individual task with specifications included. Tasks related to a code implementation should include pseudocode and/or interface specification. They should be able to be finished by 1 person in 7-14 days.
  • Research - An idea that cannot be further discussed without doing required research. After the research is concluded, it could turn into a task.

The process goes like this:

  1. Your tasks will be assigned to you beforehand. Everyone will have a predetermened set of tasks for a given period of time. Tasks will be assigned based on the area of focus of a developer.
  2. If the task is not clear, or you think there is a better solution to a problem, you should leave a comment inside the issue itself. Arguments should be non-biased and backed by logical reasoning according to our values specified above. We should try to exclude personal preferences as much as possible, and be respectful of other people's opinions.
    When all parties agree to a particular solution, the task can be continued.
  3. While doing a task, create a new branch and open a draft PR to the master branch from the very beginning, so other people can follow the progress.
  4. After a task is done, it should be openly marked as ready for review, and have reviews tagged.
  5. All the disputes during the review process should be solved in the same manner as described in step 2.
  6. When all parties agree on task implementation, it should be merged.

We could have 2 kinds of task-to-PR ratios:

  • One-to-one - 1 task done in 1 PR
  • One-to-many - 1 task done in several parts/PRs
Select a repo