Technical contribution guide
This is a guide for making technical contributions to CiviForm. ****
If you haven't already, please read our code of conduct.
Join the conversation in the Civiform Slack workspace.

Getting started

To set up your environment and learn how to run a local CiviForm server and tests, see Getting started.

Issue tracking

Development tasks are managed in the GitHub issues for this repository. When you begin working on an issue, please self-assign or comment on it indicating you're beginning work to avoid duplicate effort.
If you're just getting started, check out issues labeled with Good First Issue. Also check out issues in the next milestone so you can work on the highest-priority tasks.

Pull requests

When you're ready to submit your code, open a pull request with "Closes #X" to link the relevant issue.
It's easy for the intention of code review comments to be unclear or get misinterpreted. To help with communication, reviewers are encouraged to use conventional comments and explicitly indicate that comments are (blocking), where the discussion must be resolved for PR to be merged, or (non-blocking) where resolving the discussion is optional for the implementer.

Adding Reviewers

You can select the reviewer you feel most has context on your PR. If you want a round robin review, our repo supports that (it will cycle through people within the team 'civiform/developers', more details on how to add roundrobin reviews here. Once that is done you can add the name of the team (civiform/developers) in the reviewer box and it will auto assign someone.

Approval and merging

Reviewers should grant approval if they do not feel additional review is necessary before merging. This does not necessarily mean no more changes are required before merging, but that any further changes are expected to be minor enough to not require review.
If the pull request does not require additional changes, the reviewer should merge it immediately after approving. Otherwise, once they have addressed all comments marked (blocking) or nit, the pull request author should either merge if able or re-request review and merging from a maintainer if not. Authors are encouraged to at least reply to (non-blocking) and (if-minor) comments if they do not address them with code changes.

Getting up to speed

Want to get up to speed on this project? Awesome! Please see the following:
  • Work on at least one issue tagged with good first issue before moving to others. Feel free to ask for task recommendations in Slack.
  • Pair program with one of the project's main engineers. Reach out on Slack - we're happy to help!
Export as PDF
Copy link
Edit on GitHub
On this page
Getting started
Issue tracking
Pull requests
Adding Reviewers
Getting up to speed