CONTRIBUTING.rst

Development principles and contribution guidelines

In order to create a high-quality software product, the AlekSIS developers have agreed upon fundamental principles governing the code layout, coding style and repository management for AlekSIS and all official apps.

Coding layout and style

The coding style is defined in PEP 8, with the following differences and decisions:

• The defaults of the black code formatter are used - This implies all string literals usin double-quotes, if it does not lead

  to more escaping. As proposed by black: "My recommendation here is to keep using whatever is faster to type and let Black handle the transformation."

• The maximum line length is 100 characters

• Imports are structured in five blocks, each of them sorted as defined in PEP 8 and the Django style guide:

  1. Standard library imports
  2. Django imports
  3. Third-party imports
  4. Imports from AlekSIS core and other apps (absolute imports)
  5. Imports from the same AlekSIS app (realtive imports)

  Use isort to take care of this

For the layout of source trees and style recommendations specific to Django, the Django coding style is a good source of information, together with the Django Best Practices collection.

To ensure code is styled correctly, before commiting, run:

tox -e reformat

Text documents

If there is no objective reason against it, all text documents accompanying the source use reStructuredText.

Working with the Git repository

The Git repository shall be used as a historic documentation of development and as change management. It is important that the Git commit history describes waht was changed, by whom and why.

Help and information on Git for beginners are available in the Git guide

Feature and issue branches

All features and bug fixes should be developed in their own branch and later merged into the master branch as a whole. Of course, sometimes, it is sensible to not do that, e.g. for fixing mere typos and the like.

Within the feature branch, every logical step should be commited separately. It is neither required nor desired to do micro-commits about every development step. The commit history should describe the trains of thought the design and implementation is based on.

If you work on multiple issues at the same time, you have to change between branches. Never work on unrelated issues in the same branch.

Branches should either contain the number and title of the related issue (as generated by GitLab), or follow the naming convention type/name, where type is one of bugfix, feature, or refactor.

All changes on the code should be commited and pushed before stopping work on in order to prevent data loss. If a logical step is continued later, you should amend and force-push the commit.

Issue branches should be rebased onto the current master regularly to avoid merge conflicts.

Commit messages

Commit messages should be written as described in How to Write a Git Commit Message.

Commit messages should mention or even close any related issues. For merely mentioning progress on an issue, use the keyword advances; for closing an issue, use closes; for referring to a related issue for informational purposes, use cf.. This should be done in the body of the commit message.

The subject of a commit message can (and should) be prepended with a tag in square brackets if it relates to a certain part of the repository, e.g. [CI] when changing CI/CD configuration or support code, [Dev] when changing something in the development utilities, etc.

Example:

Solve LDAP connection problems

- Add the ldap-with-unicorn-dust dependency
- Configure settings.py to accept the correct groups from LDAP

Closes #10.

Merge Requests

If you think that the work on your feature branch is finished, you have to create a merge request on EduGit in order to let other developers and the maintainers take a look at it.

See below on how to submit patches if you cannot use the development platform.

Manifestos governing development

The FOSS community has created some manifestos describing several aspects of software development, to agree upon a baseline for these aspects. The AlekSIS developers have agreed to adhere to the following manifestos:

• The Sane software manifesto
• The Accessibility Manifesto
• The User Data Manifesto

Not all theses from these manifestos are applicable. For example, most data about persons in a school information system are dictated by the school and probably governed by laws defining what and when to store. In that case, giving the user control over these decisions is not possible. Developers need to decide what should resonably be followed.

The case on supporting non-free services

Defined by the Free Software Definition, it is an essential freedom to be allowed to use free software for any purpose, without limitation. Thus, interoperability with non-free services shall not be ruled out, and the AlekSIS project explicitly welcomes implementing support for interoperability with non-free services.

However, to purposefully foster free software and services, if interoperability for a certain kind of non-free service is implemented, this must be done in a generalised manner (i.e. using open protocols and interfaces). For example, if implementing interoperability with some cloud-hosted calendar provider can be implemented either through a proprietary API, or through a standard iCalendar/Webcal interfaces, the latter is to be preferred. Lacking such support, if a proprietary service is connected through a proprietary, single-purpose interface, measures shall be taken to also support alternative free services.

Documentation

The documentation in the AlekSIS project shall consist of three layers.

Source code comments

The parts of your code that are not self-explaining have to be commented. Ideally, source code is self-explaining, in the sense that its logical structure, naming of variables, and the like makes it easy to read and understand, for a reasonably talented programmer, to follow what it does.