Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • 1256-personalevents-with-fullday-error-in-backend
  • 928-add-frontend-for-free-busy-model
  • 976-show-announcements-in-calendar
  • 1225-rebuild-account-registration-form
  • renovate/django-maintenance-mode-0.x
  • add-datacheck-fix-in-changelog
  • 1172-add-button-that-marks-all-notifications-as-read
  • 1181-rebuild-dashboard-using-vue-vuetify-and-new-structure
  • 1232-group-calendars
  • 1251-registryobjects-are-their-own-parent-registries
  • stable/4.0
  • renovate/ipython-9.x
  • renovate/graphene-django-3.x
  • tmp-ticdesk
  • 1209-introduce-django-rest-framework-serializers
  • db-init
  • renovate/intlify-eslint-plugin-vue-i18n-4.x
  • renovate/eslint-plugin-vue-10.x
  • 1162-strange-behaviour-with-personal-events
  • 4.0.0 protected
  • 4.0.0.dev16 protected
  • 3.2.2 protected
  • 3.1.7 protected
  • 4.0.0.dev15 protected
  • 4.0.0.dev14 protected
  • 4.0.0.dev13 protected
  • 4.0.0.dev12 protected
  • 4.0.0.dev11 protected
  • 3.2.1 protected
  • 3.1.6 protected
  • 4.0.0.dev10 protected
  • 4.0.0.dev9 protected
  • 4.0.0.dev8 protected
  • 4.0.0.dev7 protected
  • 4.0.0.dev6 protected
  • 4.0.0.dev5 protected
  • 4.0.0.dev4 protected
  • 4.0.0.dev3 protected
  • 4.0.0.dev2 protected
40 results
Blame Permalink
After you've reviewed these contribution guidelines, you'll be all set to contribute to this project.
CONTRIBUTING.rst 4.11 KiB

Development principles and contribution guidelines

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

Coding layout and style

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

  • The maximum line length is 100 characters
  • Imports are structured in five blocks, each of them sorted as defined in PEP 8:
    1. Standard library imports
    2. Django imports
    3. Third-party imports
    4. Imports from other BiscuIT apps (absolute imports)
    5. Imports from the same BiscuIT app (realtive imports)
  • All string literals use single quotes

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.

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.

Feature 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.

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.

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 BiscuIT developers have agreed to adhere to the following manifestos:

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.

Text documents

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

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.