Contributing¶
How To Provide Feedback¶
Please raise an issue in Github.
Code of Conduct¶
See Code of Conduct.
Community Meetings (monthly)¶
There are currently no community meetings. Please raise an issue to reach out.
Contributor Meetings (twice monthly)¶
There are currently no public contributor meetings. Please raise an issue to reach out.
Slack¶
There is currently no public Slack. Please raise an issue to reach out.
How To Contribute¶
We're always looking for contributors.
Authoring PRs¶
- Documentation - something missing or unclear? Please submit a pull request according to our docs contribution guide!
- Code contribution - investigate a good first issue, high priority bugs, or anything not assigned.
- You can work on an issue without being assigned.
Running Locally¶
To run ARC locally for development: running locally.
Dependencies¶
Dependencies increase the risk of security issues and have on-going maintenance costs.
The dependency must pass these test:
- A strong use case.
- It has an acceptable license (e.g. MIT).
- It is actively maintained.
- It has no security issues.
Example, should we add fasttemplate, view the Snyk report:
| Test | Outcome |
|---|---|
| A strong use case. | ❌ Fail. We can use text/template. |
| It has an acceptable license (e.g. MIT) | ✅ Pass. MIT license. |
| It is actively maintained. | ❌ Fail. Project is inactive. |
| It has no security issues. | ✅ Pass. No known security issues. |
No, we should not add that dependency.
Test Policy¶
Changes without either unit or e2e tests are unlikely to be accepted. See the pull request template.
Other Contributions¶
- Reviewing PRs
- Responding to questions in the Slack channels
- Responding to questions in Github Discussions
- Triaging new bugs
Reviewing PRs¶
Anybody can review a PR. If you are in a designated role, add yourself as an "Assignee" to a PR if you plan to lead the review. If you are a Reviewer or below, then once you have approved a PR, request a review from one or more Approvers and above.
Timeliness¶
We encourage PR authors and reviewers to respond to change requests in a reasonable time frame. If you're on vacation or will be unavailable, please let others know on the PR.
PR Author Timeliness¶
If a PR hasn't seen activity from the author for 10 business days, someone else may ask to take it over.
We suggest commenting on the original PR and tagging the author to check on their plans.
Maintainers can reassign PRs to new contributors if the original author doesn't respond with a plan.
For PRs that have been inactive for 3 months, the takeover process can happen immediately.
IMPORTANT: If a PR is taken over and uses any code from the previous PR, the original author must be credited using Co-authored-by on the commits.
Triaging Bugs¶
New bugs need to be triaged to identify the highest priority ones.