From b13b97b0f91409c3e453225e78bc01c4b82e3326 Mon Sep 17 00:00:00 2001 From: Dominik George <nik@naturalnet.de> Date: Thu, 16 Jan 2020 22:03:00 +0100 Subject: [PATCH] Update contribution guidelines with input from SchoolApps Also, restructure a bit on the go. --- CONTRIBUTING.rst | 94 ++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 83 insertions(+), 11 deletions(-) diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst index aaa786141..5aba6d096 100644 --- a/CONTRIBUTING.rst +++ b/CONTRIBUTING.rst @@ -36,6 +36,12 @@ 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 ------------------------------- @@ -44,18 +50,34 @@ 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 -~~~~~~~~~~~~~~~~ +Help and information on Git for beginners are available in th `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 +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. +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 ~~~~~~~~~~~~~~~ @@ -72,6 +94,25 @@ 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 -------------------------------- @@ -89,9 +130,8 @@ 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, @@ -99,7 +139,7 @@ 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 purposefullt foster free software and services, if +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 @@ -110,11 +150,42 @@ is connected through a proprietary, single-purpose interface, measures shall be taken to also support alternative free services. -Text documents --------------- +Documentation +------------- -If there is no objective reason against it, all text documents accompanying -the source use `reStructuredText`_. +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 @@ -149,6 +220,7 @@ questions directed at the developers can also be e-mailed to .. _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/ -- GitLab