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.

Docstrings
~~~~~~~~~~

All functions, methods, classes and modules that are newly added (or changed
extensively) must contain a docstring for other developers to understand
what it does. Docstrings of public elements will be included in the
developer documentation.

Sphinx documentation
~~~~~~~~~~~~~~~~~~~~

In addition to that you should document the function or the way the app
works in the project documentation (`docs/` directory). Use that especially
for functionality which is shared by your app for other apps (public APIs).

Your Sphinx documentation should contain what the API can and shall be sued
for, and how other apps can benefit from it.

When creating a new app, also include documentation about it targeted at
administrators and users.  At least you have to document what new developers
and users have to do in order to get a working instance of the app.

Sphinx documentation for all official apps will be published together.


Contributing to upstream
------------------------

If possible and reasonable, code that can be of use to others in the general
Django ecosystem shall be contributed to any upstream dependency, or a new
generalised upstream dependency be created, under the most permissive
licence possible.


How to contact the team
-----------------------

Development platform
~~~~~~~~~~~~~~~~~~~~

Main development of AlekSIS is done on the `EduGit`_ platform in the
`AlekSIS group`_ and discussions are held on the linked `Mattermost team`_.

All platforms and tools mandated for development are free software and
freely usable. EduGit accepts a variety of sources for login, so
contributors are free to decide where they want to register in order to
participate.

If any contributor cannot use the platforms for whatever reasons, patches and
questions directed at the developers can also be e-mailed to
<aleksis-dev@lists.teckids.org>.


.. _PEP 8: https://pep8.org/
.. _Django coding style: https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/
.. _black: https://black.readthedocs.io/en/stable/
.. _Django Best Practices: https://django-best-practices.readthedocs.io/en/latest/index.html
.. _Git guide: https://rogerdudler.github.io/git-guide/
.. _How to Write a Git Commit Message: https://chris.beams.io/posts/git-commit/
.. _Sane software manifesto: https://sane-software.globalcode.info/
.. _Accessibility Manifesto: http://accessibilitymanifesto.com/
.. _User Data Manifesto: https://userdatamanifesto.org/
.. _Free Software Definition: https://www.gnu.org/philosophy/free-sw.en.html
.. _reStructuredText: http://docutils.sourceforge.net/rst.html
.. _EduGit: https://edugit.org/
.. _AlekSIS group: https://edugit.org/AlekSIS/
.. _Mattermost team: https://mattermost.edugit.org/biscuit/