-
Notifications
You must be signed in to change notification settings - Fork 2
/
CONTRIBUTING
109 lines (78 loc) · 4.72 KB
/
CONTRIBUTING
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
# Contributing to NeuroimgPipe
(adopted from scikit-learn)
The latest contributing guide is available in the repository at
`docs/contributing.rst`, or online at:
There are many ways to contribute to NeuroimgPipe, with the most common ones
being contribution of code or documentation to the project. Improving the
documentation is no less important than improving the pipeline itself. If you
find a typo in the documentation, or have made improvements, do not hesitate to
submit a GitHub pull request. Documentation can be found under the
[doc/](https://github.com/adam2392/neuroimg_pipeline/tree/master/doc) directory.
But there are many other ways to help. In particular answering queries on the
[issue tracker](https://github.com/adam2392/neuroimg_pipeline/issues), and
investigating bugs are very valuable contributions that decrease the burden on
the project maintainers.
Another way to contribute is to report issues you're facing, and give a "thumbs
up" on issues that others reported and that are relevant to you. It also helps
us if you spread the word: reference the project from your blog and articles,
link to it from your website, or simply star it in GitHub to say "I use it".
Another way to contribute is specifically to make additional pipelines that improve
the accuracy of contact localization for iEEG data using the T1 and CT images.
## Code of Conduct
We abide by the principles of openness, respect, and consideration of others
of the Python Software Foundation: https://www.python.org/psf/codeofconduct/.
## Submission context
### Got a question or problem?
For quick questions there's no need to open an issue as you can reach us on
[gitter.im][1].
[1]: https://gitter.im/squidfunk/mkdocs-material
### Found a bug?
If you found a bug in the source code, you can help us by submitting an issue
to the [issue tracker][2] in our GitHub repository. Even better, you can submit
a Pull Request with a fix. However, before doing so, please read the
[submission guidelines][3].
[2]: https://github.com/squidfunk/mkdocs-material/issues
[3]: #submission-guidelines
### Missing a feature?
You can request a new feature by submitting an issue to our GitHub Repository.
If you would like to implement a new feature, please submit an issue with a
proposal for your work first, to be sure that it is of use for everyone, as
the Material for MkDocs is highly opinionated. Please consider what kind of
change it is:
* For a **major feature**, first open an issue and outline your proposal so
that it can be discussed. This will also allow us to better coordinate our
efforts, prevent duplication of work, and help you to craft the change so
that it is successfully accepted into the project.
* **Small features and bugs** can be crafted and directly submitted as a Pull
Request. However, there is no guarantee that your feature will make it into
the `master`, as it's always a matter of opinion whether if benefits the
overall functionality of the project.
## Submission guidelines
### Submitting an issue
Before you submit an issue, please search the issue tracker, maybe an issue for
your problem already exists and the discussion might inform you of workarounds
readily available.
We want to fix all the issues as soon as possible, but before fixing a bug we
need to reproduce and confirm it. In order to reproduce bugs we will
systematically ask you to provide a minimal reproduction scenario using the
custom issue template. Please stick to the issue template.
Unfortunately we are not able to investigate / fix bugs without a minimal
reproduction scenario, so if we don't hear back from you we may close the issue.
### Submitting a Pull Request (PR)
Search GitHub for an open or closed PR that relates to your submission. You
don't want to duplicate effort. If you do not find a related issue or PR,
go ahead.
1. **Development**: Fork the project, set up the [development environment][4],
make your changes in a separate git branch and add descriptive messages to
your commits.
2. **Build**: Before submitting a pull requests, [build the theme][5]. This is
a mandatory requirement for your PR to get accepted, as the theme should at
all times be installable through GitHub.
3. **Pull Request**: After building the theme, commit the compiled output, push
your branch to GitHub and send a PR to `mkdocs-material:master`. If we
suggest changes, make the required updates, rebase your branch and push the
changes to your GitHub repository, which will automatically update your PR.
After your PR is merged, you can safely delete your branch and pull the changes
from the main (upstream) repository.
[4]: https://squidfunk.github.io/mkdocs-material/customization/#environment-setup
[5]: https://squidfunk.github.io/mkdocs-material/customization/#build-process