Contributing

Thank you for taking the time to contribute to this project. The maintainers greatly appreciate the interest of contributors and rely on continued engagement with the community to ensure this project remains useful. We would like to take steps to put contributors in the best possible position to have their contributions accepted. Please take a few moments to read this short guide on how to contribute.

Feedback and questions

If you wish to discuss anything related to the project, please open a GitHub issue.

Contribution process

All contributions have to go through a review process, and contributions can be made in two ways:

• For simple contributions navigate to the documentation page you want to improve, and click the Edit this page link in the top-right corner (see also the GitHub documentation). You will be guided through the required steps. Be sure to save your changes quickly as the repository may be updated by someone else in the meantime.
• For more complex contributions or when you want to preview and test changes locally you should fork the repository as documented on the Using Git and GitHub page.

Contributing via PRs

Before proposing a contribution via the so-called Pull Request (PR) workflow, there should be an open issue describing the need for your contribution (refer to this issue number when you submit the PR). We have a three-step process for contributions:

1. Fork the project if you have not done so yet, and commit changes to a feature branch. Building the documentation locally is described in the README.
2. Create a GitHub PR from your feature branch, following the instructions in the PR template.
3. Perform a code review with the maintainers on the PR.

PR requirements

1. If the PR is not finalised mark it as draft using the GitHub web interface, so it is clear it should not be reviewed yet.
2. Explain your contribution in plain language. To assist the maintainers in understanding and appreciating your PR, please use the template to explain why you are making this contribution, rather than just what the contribution entails.

Code review process

Code review takes place in GitHub pull requests (PRs). See this article if you’re not familiar with GitHub PRs.

Once you open a PR, automated checks will verify the style and syntax of your changes and maintainers will review your code using the built-in code review process in GitHub PRs.

The process at this point is as follows:

1. Automated syntax and formatting checks are run using GitHub Actions, successful checks are a hard requirement, but maintainers will help you address reported issues.
2. Maintainers will review your changes and merge it if no changes are necessary. Your change will be merged into the repository’s main branch.
3. If a maintainer has feedback or questions on your changes, they will set request changes in the review and provide an explanation.

Release cycle

The documentation is using a rolling release model, all changes merged to the main branch are directly deployed to the live production environment.

The main branch is always available. Tagged versions may be created as needed following semantic versioning when applicable.

Community

EGI benefits from a strong community of developers and system administrators, and vice-versa. If you have any questions or if you would like to get involved in the wider EGI community you can check out the EGI website