Merge branch 'main' into ts/rulesets

external-contributions.md

@@ -0,0 +1,36 @@
+# External Contributions
+> [!NOTE]
+> _At the Guardian, we are committed to coding in public. A significant portion of our source code is openly accessible on our GitHub repository. This openness sometimes leads to contributions or pull requests (PRs) from individuals outside our organisation._
+>
+> _This guidance may not be suitable for all our projects, and is primarily aimed at unsolicited PRs from people who don’t regularly work with us. Projects which find this guidance most relevant may choose to link to this file via a CONTRIBUTING file in the root folder._
+
+## Guidance for External Contributors
+
+***Thank you!***
+
+We appreciate your interest in contributing to our projects. The relevant team will review your submission and get in touch if they need further information about your proposed changes. Please understand that due to our commitment to thorough review and testing, coupled with our team’s existing workloads, we cannot guarantee a specific timeline for the review or integration of external contributions.
+
+While we value every contribution, there are instances where we may not be able to merge external changes. This decision is not a reflection of your effort or quality of work. Various factors, including project suitability and alignment with internal standards, influence these decisions.
+
+If you’d like more information about the prospects of a change, you may also like to [contact us](mailto:[email protected]) about an idea before you work on it.
+
+## Guidance for Guardian Staff
+
+### Handling External Contributions
+Teams should aim to acknowledge and thank individuals for their effort as quickly as reasonably possible. Set realistic expectations regarding the review and integration of these contributions.
+
+### Reviewing Contributions
+All changes, especially from external sources, require careful consideration and testing. Staff should assess external contributions considering our coding standards and project goals.
+
+Contributions that don’t align with our standards, conventions, or project needs might not be merged. This applies even if certain standards or conventions are newly implemented or undocumented. Teams should always have the discretion to determine the suitability of external contributions.
+
+Involve your product team in discussions about feature changes and prioritisation.
+
+### Feedback and Communication
+When communicating with external contributors, be considerate of the fact that they are not our employees and might have different expectations regarding feedback and requests for revisions. Teams should consider whether it might be more efficient to implement requested changes internally.
+
+### Security and Product Integration
+Think carefully about the risks that could be introduced by changes. Look particularly closely at changes to dependencies or updates. Assess the potential risks involved, including the security of the contributor’s account and potential compromises to dependencies. 
+
+### Procedure for Merging Contributions
+For contributions deemed suitable for integration, create an internal branch mirroring the external contribution. To ensure the work is properly attributed to the external contributor, cherry-pick the commits and/or add a co-author to the merge commit. This allows for the completion of necessary workflows. Once this is done, you can close the external PR. GitHub will then link to the internal PR and display its status upon merging. Close the loop - you may wish to thank the contributor again or give them an update, especially if it’s been a while between the contribution and the final merge.