Skip to content

Latest commit

 

History

History
61 lines (38 loc) · 3.71 KB

CONTRIBUTING.md

File metadata and controls

61 lines (38 loc) · 3.71 KB
Raw

How to contribute

There are a number of ways you can contribute to an ATC project/repository. Create an issue or ask a question in the Discussions forum in the relevant repository. We also gladly accept pull requests with bug fixes, enhancements. Big and small, all are welcome.

The following sections covers the different ways to contribute.

General feedback and discussions

Each repository has a GitHub Discussion forum where questions can be asked, ideas can be shared, and all general discussions takes place. Feel free to jump in and take part.

Bug- and feature requests

For bugs or feature requests, log a new issue on the relevant repositories Issues list. Be sure to use the right template, and fill in all relevant information.

Security issues

DO NOT REPORT SECURITY ISSUES in the Issues list. Instead, send all details to atcnet.org@gmail.com.

Contributing code or documentation

All public ATC repositories accepts pull requests with code and/or documentation improvements. Before starting work on a pull request, be sure to read the following section carefully, to avoid wasting time, both ours and yours.

  • All ATC projects follow the coding guidelines and rules described in the ATC Coding Rules project. Be sure to familiarise yourself with them. There is also a heavy and opioninated use of .NET analyzers, whose configuration should not be altered. Be sure to have a very good reason for suppressing one of them.

  • Before starting on a feature or bug, make sure to create or read the related issue, and make sure the planned design has been approved by a maintainer of the ATC project. Issues with approved designs are marked with the design approved label. Only very small changes/fixes, e.g. spelling mistakes or code cleanup, should be submitted without first creating an issue or getting feedback from a maintainer.

  • All code should generally be covered by some kind of test, be it unit test, integration test or similar. Be sure to add and/or update tests all relevant tests accordingly.

  • Any code or documentation you share with ATC projects implicitly fall under the projects license agreement.

Here are some resources to help you get started contributing code or new content to an ATC project:

  • help wanted issues - these issues are up for grabs if you want to create a fix. To do this, simply comment on the issue you want to fix and you will be assigned to it.
  • good first issue issues - these are good for newcomers. Good first issues are small, usually require just a few hours of work, and do not require a deep technical knowledge of the project. This is a good place to start if you want to become familiar with the project’s inner workings and maybe take on bigger issues later.

Good practices related to pull requests

You might also read these two blogs posts on contributing code: Open Source Contribution Etiquette by Miguel de Icaza and Don't "Push" Your Pull Requests by Ilya Grigorik. These blog posts highlight good open source collaboration etiquette and help align expectations between you and us.

All code submissions will be reviewed and tested, and only those that meet a high bar for both quality and design/roadmap appropriateness will be merged into the source.

Submitting a Pull Request

If you don't know what a pull request is, read this article: https://help.github.com/articles/using-pull-requests. Make sure the repository can build and all tests pass. It is also a good idea to familiarize yourself with the project workflow and our coding conventions.

Code of Conduct

See CODE-OF-CONDUCT.md