From 39277844dd4c2b8a741734d6d453e34281e114a6 Mon Sep 17 00:00:00 2001 From: Juan Font Date: Tue, 23 Apr 2024 22:04:56 +0200 Subject: [PATCH] Apply suggestions from code review Co-authored-by: ohdearaugustin --- CONTRIBUTING.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8296dd9..c1f8d9c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,6 +1,6 @@ # Contributing -Headscale is "Open Source, acknowledged contribution", this means that any contribution will have to be discussed with the Maintainers before being submitted. +Headscale is "Open Source, acknowledged contribution", this means that any contribution will have to be discussed with the maintainers before being added to the project. This model has been chosen to reduce the risk of burnout by limiting the maintenance overhead of reviewing and validating third-party code. ## Why do we have this model? @@ -9,7 +9,7 @@ Headscale has a small maintainer team that tries to balance working on the proje When we work on issues ourselves, we develop first hand knowledge of the code and it makes it possible for us to maintain and own the code as the project develops. -When code is contributed to the project, it is typically a positive thing. People enjoy and engage with our project, but it also comes with some challenges; we have to understand the code, we have to understand the feature, we might have to become familiar with external libraries or services that this new feature integrates with and it needs to be reviewed from a security perspective. And that is only when it comes to reviewing it. After the code has been merged, the feature has to be maintained, meaning that changes to external parts need to be updated, and kept working. +Code contributions are seen as a positive thing. People enjoy and engage with our project, but it also comes with some challenges; we have to understand the code, we have to understand the feature, we might have to become familiar with external libraries or services and we think about security implications. All those steps are required during reviewing process. After the code has been merged, the feature has to be maintained. Any changes reliant on external services must be updated and expanded accordingly. . The review and the day-1 maintenance adds a significant burden on the maintainers. Often we hope that the contributor will help out, but we found that most of the time, they disappear after their new feature was added. @@ -21,7 +21,7 @@ A general description is provided here and an explicit list is provided in our p All new features have to start out with a design document, which should be discussed on the issue tracker (not discord). It should include a use case for the feature, how it can be implemented, who will implement it and a plan for maintaining it. -All features have to be end to end tested (integration tests) and have good unit test coverage to ensure that they work as expected, and work as expected over time. If the change cannot be tested, a strong case for why this is not possible needs to be presented. +All features have to be end-to-end tested (integration tests) and have good unit test coverage to ensure that they work as expected. This will also ensure that the feature continues to work as expected over time. If a change cannot be tested, a strong case for why this is not possible needs to be presented. The contributor must help maintain the feature over time, if a feature is found to be left unmaintained, we will have to remove it.