Contributor policy and guidelines

Cody Boyko edited this page Jun 11, 2018 · 15 revisions

We recently wrote up our plans to make CKAN into a sustainable independent international project and the core development of CKAN should reflect this.

Over the last few months we have been working hard to improve our contribution guidelines, our documentation and test infrastructure to support greater community contributions and involvement.

We made our roadmap public and accessible and updated the information for our processes.

Now, we are detailing how to get involved and become a CKAN Project core contributor. Being a core contributor means taking responsibility for the quality and consistency of CKAN - ensuring things are well documented and tested, coming to the developer meetings and helping review pull requests.

To help the process, we are proposing to introduce the notion of Module Owners - who are a set of people responsible for specific areas of CKAN and will act as the gatekeepers for merging in new code to their area.

Below we describe the process for becoming a core contributor, what that involves, how to help with pull requests and how core contributors work with module owners (as well as how to become a module owner!).

Core Contributors

A core contributor to CKAN is an experienced CKAN developer who contributes significant code/documentation/tests back to the main CKAN repository.

Core contributor perks

  • Come to pull requests/dev meetings on Tuesday’s and Thursday’s - currently done via skype at 12 noon BST - help shape and decide the future of CKAN!
  • Listed on the site as a core contributor
  • Help triage tickets
  • Get a vote on controversial core changes
  • Review pull requests and ideally work closely with a module owner
  • Can become a module owner

How to become a core contributor

  • Fairly open access - show willingness and active involvement
  • Must care about the CKAN project
  • Sign up to product discussion and ckan dev mailing lists
  • Willingness to contribute and understand the project, read the docs, code guidelines etc.
  • Willing to attend review/dev meetings at least once a fortnight
  • Follow pull request guidelines (if doing code changes)
  • Willingness to review pull requests (see pull request guidelines)
  • Need to sign a Contributor Licence Agreement

Current core contributors

Module Owners

Module Owners take responsibility for a particular area of the code. Only module owners should be merging new code into CKAN core.

What does it mean to be a module owner

  • Responsible for merging in pull requests for the area of code they are responsible.
  • Help advise core contributors in making pull requests or reviewing them for their area.
  • Essentially, have to sign off any code related (substantially) to their area of work with the exception of testing and documentation which any owner can merge unless there are significant structural changes.
  • Insignificant changes or bug fixes to other areas can be merged in by any of the module owners. When in doubt, please contact relevant owner(s) about the change.
  • Any very complicated cross areas need to be looked into by lead dev.
  • Anything that falls out of sections can be reviewed by any module owner.

How to become a module Owner

  • Show consistent interest and specialist knowledge for a particular area.
  • Have a lot of your code already reviewed and merged in that area.
  • Get agreement by the other module owners (with special vote by the current module owner).

Current Module Owners

  • Lead dev (swapped amongst the module owners)
  • Data model - David Raznick
  • Search - temporarily David Raznick (new applicants welcome)
  • Documentation - Sean Hammond
  • Tests - temporary Sean Hammond (new applicants welcome)
  • Harvesting - Adrià Mercader
  • UI & templates - currently John Martin (please apply)
  • Spatial - Adrià Mercader
  • API, logic layer, API consistency - (please apply)
  • Datastore - temporary David Raznick (replacement applicants welcome)
  • i18n (please apply)
  • User interface QA lead (please apply, does not have to be technical)
  • Visualization - (please apply)

Going forward we want to introduce a code quality champion, a user interface product owner and more dedicated QA leads. Let us know what you think about this.

Pull Request Review guidelines

  1. Deploy the fix to your local ckan instance set up.
  2. Check code is up to code guideline standards (eg tests, docs).
  3. Ensure tests pass.
  4. Check the code does what is intended.
  5. Run through user actions related to the issue as well as related actions. This includes testing out API or user interface manually.
  6. Leave comments in line or on issue for any needed changes or missed use cases etc.
  7. Once you are happy, reassign the PR to the relevant module owner and leave a comment to say you have reviewed and happy to have this merged.
  8. Module owners then merges in and closes issue, or offers feedback and reassigns back.

Contributor Licence Agreements

As CKAN matures we want to ensure that we protect the legal status of its code with clear copyright ownership of the core code, which can at a later stage be transferred to a 'CKAN Foundation' legal entity, if needed. We are in the process of drafting these agreements now and all non-trivial contributions to CKAN will need a signed CLA. Get in touch if you would like to discuss this with the CKAN Project coordinator.

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.