[Repository Listing] / [Slicer4] / trunk / CONTRIBUTING.md

View of /trunk/CONTRIBUTING.md

Parent Directory Parent Directory Revision Log Revision Log

Revision 25838  Download Blame
File size: 6171 byte(s)
ENH: Add Contributing.md

Initial version of this document has adapted from Girder contribution
process document [1] by @jcfr and was updated during the Slicer weekly
hangouts to incorporate feedback from the community.

It includes the following sections:

* The PR Process, Circle CI, and Related Gotchas
 * How to submit a PR ?
 * How to efficiently contribute ?
 * How to integrate a PR ?
 * Automatic testing of pull requests
 * Nightly tests
 * Decision-making process
 * Benevolent dictators for life

[1] https://github.com/girder/girder/blob/master/CONTRIBUTING.md

[ci skip]

Co-authored-by: Johan Andruejol <johan.andruejol@kitware.com>
Co-authored-by: Andriy Fedorov <fedorov@bwh.harvard.edu>
Co-authored-by: Alexis Girault <alexis.girault@kitware.com>
Co-authored-by: Michael Halle <mhalle@bwh.harvard.edu>
Co-authored-by: Ron Kikinis <kikinis@bwh.harvard.edu>
Co-authored-by: Andras Lasso <lasso@queensu.ca>
Co-authored-by: Matt McCormick <matt.mccormick@kitware.com>
Co-authored-by: Isaiah Norton <inorton@bwh.harvard.edu>
Co-authored-by: Steve Pieper <pieper@isomics.com>
Co-authored-by: Csaba Pinter <csaba.pinter@queensu.ca>
Co-authored-by: Hina Shah <hina.shah@kitware.com>
Co-authored-by: Dzenan Zukic <dzenan.zukic@kitware.com>

Alphabetically ordered by last name.
1 Contributing to Slicer
2 ======================
4 There are many ways to contribute to Slicer, with varying levels of effort. Do try to
5 look through the [documentation](https://www.slicer.org/wiki/Documentation/Nightly/Developers) first if something is unclear, and let us know how we can
6 do better.
8 * Ask a question on the [slicer-devel email list](http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel)
9 * Submit a feature request or bug, or add to the discussion on the [Slicer issue tracker](http://na-mic.org/Mantis)
10 * Submit a [Pull Request](https://github.com/Slicer/Slicer/pulls) to improve Slicer or its documentation
12 We encourage a range of Pull Requests, from patches that include passing tests and
13 documentation, all the way down to half-baked ideas that launch discussions.
15 The PR Process, Circle CI, and Related Gotchas
16 ----------------------------------------------
18 #### How to submit a PR ?
20 If you are new to Slicer development and you don't have push access to the Slicer
21 repository, here are the steps:
23 1. [Fork and clone](https://help.github.com/articles/fork-a-repo/) the repository.
24 3. Create a branch.
25 4. [Push](https://help.github.com/articles/pushing-to-a-remote/) the branch to your GitHub fork.
26 5. Create a [Pull Request](https://github.com/Slicer/Slicer/pulls).
28 This corresponds to the `Fork & Pull Model` mentioned in the [GitHub flow](https://guides.github.com/introduction/flow/index.html)
29 guides.
31 When submitting a PR, the developers following the project will be notified. That
32 said, to engage specific developers, you can add `Cc: @<username>` comment to notify
33 them of your awesome contributions.
34 Based on the comments posted by the reviewers, you may have to revisit your patches.
37 #### How to efficiently contribute ?
39 We encourage all developers to:
41 * review and follow the style guidelines described
42 [on the wiki](https://www.slicer.org/wiki/Documentation/Nightly/Developers/Style_Guide#Commits).
44 * add or update tests. There are plenty of existing tests to inspire from. The
45 testing [how-tos](https://www.slicer.org/wiki/Documentation/Nightly/Developers/Tutorials/Testing) are
46 also resourceful.
48 * consider potential backward compatibility breakage and discuss these on the
49 mailing list. For example, update of ITK, Python, Qt or VTK version, change to
50 core functionality, should be carefully reviewed and integrated. Ideally, several
51 developers would test that the changes don't break extensions.
53 #### How to integrate a PR ?
55 Getting your contributions integrated is relatively straightforward, here
56 is the checklist:
58 * All tests pass
59 * Consensus is reached. This usually means that at least two reviewers approved
60 the changes (or added a `LGTM` comment) and at least one business day passed
61 without anyone objecting. `LGTM` is an acronym for _Looks Good to Me_.
62 * To accommodate developers explicitly asking for more time to test the
63 proposed changes, integration time can be delayed by few more days.
65 Next, there are two scenarios:
66 * You do NOT have push access: A Slicer core developer will integrate your PR. If
67 you would like to speed up the integration, do not hesitate to send a note on
68 the mailing list.
69 * You have push access: Follow [Integrating topic from external contributor](https://www.slicer.org/wiki/Slicer:git-svn#Integrating_topic_from_external_contributor)
70 instructions on the wiki.
73 #### Automatic testing of pull requests
75 Every pull request is tested automatically using CircleCI each time you push a
76 commit to it. The Github UI will restrict users from merging pull requests until
77 the CI build has returned with a successful result indicating that all tests have
78 passed.
80 The testing infrastructure is described in details in the
81 [3D Slicer Improves Testing for Pull Requests Using Docker and CircleCI](https://blog.kitware.com/3d-slicer-improves-testing-for-pull-requests-using-docker-and-circleci/)
82 blog post.
85 #### Nightly tests
87 After changes are integrated, every evening at 10pm EST (3am UTC), Slicer build bots (aka factories)
88 will build, test and package Slicer application and all its extensions on Linux, MacOSX
89 and Windows. Results are published daily on [CDash](http://slicer.cdash.org/index.php?project=Slicer4)
90 and developers introducing changes introducing build or test failures are notified by
91 email.
94 #### Decision-making process
96 1. Given the topic of interest, initiate discussion on the [mailing list](http://massmail.spl.harvard.edu/mailman/listinfo/slicer-devel).
98 2. Identify a small circle of community members that are interested to study the
99 topic in more depth.
101 3. Take the discussion off the general list, work on the analysis of options and
102 alternatives, summarize findings on the wiki or similar. [Labs](https://www.slicer.org/wiki/Documentation/Labs)
103 page are usually a good ground for such summary.
105 4. Announce on the mailing list the in-depth discussion of the topic for the
106 [Slicer Community hangout](https://www.slicer.org/wiki/Documentation/Nightly/Developers/Meetings),
107 encourage anyone that is interested in weighing in on the topic to join the
108 discussion. If there is someone who is interested to participate in the discussion,
109 but cannot join the meeting due to conflict, they should notify the leaders of
110 the given project and identify the time suitable for everyone.
112 5. Hopefully, reach consensus at the hangout and proceed with the agreed plan.
115 *The initial version of these guidelines was established during the [winter
116 project week 2017](http://www.na-mic.org/Wiki/index.php/2017_Winter_Project_Week/UpdatingCommunityForums).*
118 #### Benevolent dictators for life
120 The [benevolent dictators](https://en.wikipedia.org/wiki/Benevolent_dictator_for_life) can
121 integrate changes to keep the platform healthy and help interpret
122 or address conflict related to the contribution guidelines.
125 These currently include:
127 * Jean-Christophe Fillion-Robin
128 * Andras Lasso
129 * Steve Pieper
131 *Alphabetically ordered by last name.*
133 The Slicer community is inclusive and welcome anyone to work to become a core
134 developer and then a BDFL. This happens with hard work and approval of the existing
135 BDFL.

  Subversion  TortoiseSVN  ViewVC