Contributing to the Project¶

Introduction¶

Contributing to the project requires good understanding of the project’s structure and the way it is built, but also of the practices employed by the project’s members.

Code of Conduct¶

We value the contributions of every individual and are committed to creating a welcoming, inclusive, and respectful environment for all contributors.

By participating in this project, you agree to uphold our principles of collaboration and respect. This means avoiding any form of discrimination, harassment, or offensive behavior, and treating everyone with kindness and professionalism.

Development Lifecycle¶

Developing features requires a good understanding of the project’s structure and the way it is built. Each new feature or component that is added to the project must follow the following three principles:

1. Write the documentation of the feature or component in the associated /docs directory of the repository

   There is no need to write a ton of paragraphs to describe simple or straightforward features, we do not want to have a novel in our documentation. We want to immediately get to the point and understand what the feature or component does, and more importantly, how it solves a problem or improves the project.

   Warning

   Before proceeding to the next step, make sure to talk with the other contributors about the feature or component you want to add to the project.

   This eliminates the risk of having to rewrite the feature or component because it does not fit the project’s vision, or causes issues/refactors down the line.

   Do not start developing the feature if you haven’t shown your documentation first.

   Tip

   You can still prototype and write documentation as you go if this helps you, but make sure to let the other contributors know about your work.

2. Prototype the feature or component locally in the poc directory of the repository

   This is required if the feature or component is either complex or mandatory for the project to work. This can be especially useful if said feature or component requires the use of e.g. an external dependency.

   Tip

   One such example is conceptualizing a graphics subsystem by interfacing the Hardware Abstraction Layer, which itself relies on SFML

3. Develop the feature or component

   Develop the feature or component where applicable (e.g. a subsystem shall be developed in /src/subsystem and /include/subsystem).

   Tip

   Make sure to take a look at the Project Architecture page for more information regarding where to lay out your work in the source tree.

Using Git¶

We use Git as our version control system, and we require new, refactored or deleted features/components to be added to the project through a pull request.

Doing a pull request requires the creation of a new branch from the main branch, of which the name shall follow the name of the overall feature or component you are working on.

Using Jira¶

During the development, make sure to update the associated Jira ticket or create a new one if the feature or component is not yet tracked.

Taking the time to update the Jira ticket is important, as it allows the project’s members to keep track of the progress of the project, and to know what is being worked on.