Contributing to the SKA

We’re delighted that you’d like to contribute to an SKA project. First of all, please read our SKA Code of Conduct, which sets out our expectations for behaviour when working on the SKA. Since you’re most likely here to work with our repositories, you should probably read our guide to Working with GitLab.

The advice provided here is general; please look at the documentation for the repository you wish to commit to to check out the specific policies. For example, if you wish to Contribute to the developer portal, you’ll need to read the linked page. If a specific policy contradicts the general advice, please follow the policy for the relevant repository over the guidance provided here. Note that at the moment, not all repositories have good processes to deal with merge requests from forks of that repo.

SKA repositories follow feature based Branching policy with Merge Request for code review and integration. Everyone is welcome to clone/fork the repository and open a Merge Request for contribution. The Merge request will be reviewed by the repository maintainers. Please make sure you follow the contribution guidelines defined here and in the repository as well.

Please read the Coding guidelines for the language you’re working with; you’ll need to adhere to those standards. Many repositories will perform PEP-8 or similar linting checks. If you’re working on documentation for any repository, we use ReadtheDocs, using the Sphinx documentation generator, which uses reStructuredText.

For documentation, we recommend that file and directory names do not use underscores, but use hyphens. We recommend using Thomas Cokelaer’s heading syntax. We suggest updating pages as you work on them to adopt this style.

When you are writing instructions for a developer or user, do not assume you know the gender of that person. Pronouns such as “you”, “we” and “they” are all acceptable. If you need to refer to the actions of an individual, use singular “they” or a role: “If a team member is struggling with using git, they should contact the System Team for help.” But you may find that (as in this sentence), you can write a more friendly guideline by using “you”.

Any images you add to documentation should have adequate contrast. A good test is to preview or print images out in black and white; if they’re still legible, the contrast is likely to be acceptable for people with low vision. All images should have alt-text added, unless the same information can be obtained from a figure caption. We recommend reading a guide to writing good alt-text.

Thank you for reading; we hope that you’re able to contribute to the SKA.