[ckan-dev] Contributing to CKAN

Tue Dec 3 15:23:42 UTC 2013

Hi everyone,

We recently wrote up our plans to make CKAN into a sustainable independent
international project <http://ckan.org/2013/10/18/project-ckan/> and the
core development of CKAN should reflect this.

Over the last few months we have been working hard to improve our contribution
guidelines <http://docs.ckan.org/en/latest/contributing.html>, our
documentation <http://docs.ckan.org/en/latest/> and test infrastructure to
support greater community contributions and involvement.

We made our roadmap
public<https://trello.com/b/MkqvtXnH/ckan-roadmap-ideas-requests> and
accessible and updated the information for our
processes<https://github.com/okfn/ckan/wiki/Contributions,-Roadmap-and-Project-Membership>
.

Now, we are detailing how to get involved and become a CKAN
Project<http://ckan.org/2013/10/18/project-ckan/> 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!).
<https://github.com/okfn/ckan/wiki/Contributor-policy-and-guidelines#core-contributors>Core
Contributors

A core contributor to CKAN is an experienced CKAN developer who contributes
significant code/documentation/tests back to the main CKAN repository.
<https://github.com/okfn/ckan/wiki/Contributor-policy-and-guidelines#core-contributor-perks>Core
contributor perks

   - Come to pull requests/dev meetings on Tuesday’s and Thursday’s -
   currently done via skype at 12 noon BST
   - 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

<https://github.com/okfn/ckan/wiki/Contributor-policy-and-guidelines#how-to-become-a-core-contributor>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

<https://github.com/okfn/ckan/wiki/Contributor-policy-and-guidelines#module-owners>Module
Owners

Module Owners take responsibility for a particular area of the code. Only
module owners should be merging new code into CKAN core.
<https://github.com/okfn/ckan/wiki/Contributor-policy-and-guidelines#what-does-it-mean-to-be-a-module-owner>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.

<https://github.com/okfn/ckan/wiki/Contributor-policy-and-guidelines#how-to-become-a-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).

<https://github.com/okfn/ckan/wiki/Contributor-policy-and-guidelines#current-module-owners>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.
<https://github.com/okfn/ckan/wiki/Contributor-policy-and-guidelines#pull-request-review-guidelines>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.

<https://github.com/okfn/ckan/wiki/Contributor-policy-and-guidelines#contributor-licence-agreements>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.

Let us know what you think by replying to this thread or emailing me. The
live updated version of this document is on our wiki here:
https://github.com/okfn/ckan/wiki/Contributor-policy-and-guidelines

Cheers,
Irina
-- 

*Irina Bolychevsky*

*Government Open Data & CKAN Manager  |  skype: flouxi  |  twitter:
@shevski <http://twitter.com/shevski>*

*The Open Knowledge Foundation <http://okfn.org/>*

*Empowering through Open Knowledge*

*http://okfn.org/ <http://okfn.org/>  |  @okfn <http://twitter.com/OKFN>  |
 OKF on Facebook <https://www.facebook.com/OKFNetwork>  |  Blog
<http://blog.okfn.org/>  |  Newsletter <http://okfn.org/about/newsletter>*

*CKAN | http://ckan.org <http://ckan.org> | @ckanproject
<http://twitter.com/ckanproject> | open source data management platform*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20131203/d9e19a30/attachment-0002.html>