Contributing¶
How To Provide Feedback¶
Please raise an issue in Github.
Code of Conduct¶
See CNCF Code of Conduct.
Community Meetings (monthly)¶
A monthly opportunity for users and maintainers of Workflows and Events to share their current work and hear about what’s coming on the roadmap. Please join us! For Community Meeting information, minutes and recordings please see here.
Contributor Meetings (twice monthly)¶
An opportunity for contributors and maintainers of Workflows and Events to discuss their current work and talk about what’s next. Feel free to join us! See the Contributor Meeting doc for minutes, recordings, and more information.
Slack¶
You can join the following channels on CNCF Slack:
#argo-workflows
: discussions focused mainly on use of Argo Workflows#argo-wf-contributors
: discussions focused mainly on development of Argo Workflows
Roles¶
The Argo project currently has 4 designated roles:
- Member
- Reviewer
- Approver
- Lead
The Reviewer and Approver roles can optionally be scoped to an area of the code base (for example, UI or docs).
Current roles for Reviewers and above can be found in OWNERS.
If you are interested in formally joining the Argo project, create a Membership request in the argoproj repository as described in the Membership guide.
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.
Contributor Workshop¶
Please check out the following resources if you are interested in contributing:
- 90m hands-on contributor workshop.
- Deep-dive into components and hands-on experiments.
- Architecture overview.
Running Locally¶
To run Argo Workflows locally for development: running locally.
Committing¶
See the Committing Guidelines.
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.
Triaging Bugs¶
New bugs need to be triaged to identify the highest priority ones. Any Member can triage bugs.
Apply the labels P0
, P1
, P2
, and P3
, where P0
is highest priority and needs immediate attention, followed by P1
, P2
, and then P3
.
If there's a new P0
bug, notify the #argo-wf-contributors
Slack channel.
Any bugs with >= 5 "👍" reactions should be labeled at least P1
.
Any bugs with 3-4 "👍" reactions should be labeled at least P2
.
Bugs can be sorted by "👍".
If the issue is determined to be a user error and not a bug, remove the type/bug
label (and the type/regression
label, if applicable) and replace it with the type/support
label.
If more information is needed from the author to diagnose the issue, then apply the problem/more information needed
label.
Please only assign issues to members. New contributors are encouraged to work on a PR directly without being assigned.
Staleness¶
Only issues and PRs that have the problem/more information needed
label will be considered for staleness.
If the author does not respond timely to a request for more information, the issue or PR will be automatically marked with the problem/stale
label and a bot message.
Subsequently, if there is still no response, it will be automatically closed as "not planned".
See the Stale Action configuration for more details.
Sustainability Effort¶
Argo Workflows is seeking more Reviewers and Approvers to help keep it viable. Please see Sustainability Effort for more information.