Skip to content

Commit 8e459a6

Browse files
mhoffmanmhoffman
committedJul 31, 2016
Added more info for contributors
·
0.3.210.3.19
1 parent 49ab868 commit 8e459a6

File tree

4 files changed

+175
-0
lines changed

4 files changed

+175
-0
lines changed
 

‎.github/CONTRIBUTING.md

+146
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,146 @@
1+
## Contributing to kmos
2+
3+
The kmos project welcomes contributions from everyone. There are a
4+
number of ways you can help:
5+
6+
## Git and Pull requests
7+
* Contributions are submitted, reviewed, and accepted using Github pull requests. [Read this article](https://help.github.com/articles/using-pull-requests) for some details. We use the _Fork and Pull_ model, as described there.
8+
* To help keep track of [your assigned issues](https://github.com/dashboard/issues/assigned), simply open an issue to be added as an [Outside Collaborator](https://github.com/orgs/drush-ops/outside-collaborators). A maintainer can now assign any issue to you at your request.
9+
* The latest changes are in the `master` branch.
10+
* Make a new branch for every feature you're working on.
11+
* Try to make clean commits that are easily readable (including descriptive commit messages!)
12+
* Test before you push. Get familiar with Nosetest, our test suite. Ideally create your own free account on [Travis](https://travis-ci.org/) and test your branch on it.
13+
* Make small pull requests that are easy to review but make sure they do add value by themselves.
14+
* We maintain branches named 7.x, 6.x, etc. These are release branches. From these branches, we make new tags for patch and minor versions.
15+
16+
## Coding style
17+
* Do write comments. You don't have to comment every line, but if you come up with something thats a bit complex/weird, just leave a comment. Bear in mind that you will probably leave the project at some point and that other people will read your code. Undocumented huge amounts of code are nearly worthless!
18+
* run `pep8` or `autopep8` or even `autopep8` again your changes
19+
* stick to [Google's Python style guide](https://google.github.io/styleguide/pyguide.html)
20+
* Don't overengineer. Don't try to solve any possible problem in one step, but try to solve problems as easy as possible and improve the solution over time!
21+
* Do generalize sooner or later! (if an old solution, quickly hacked together, poses more problems than it solves today, refactor it!)
22+
* Keep it compatible. Do not introduce changes to the public API, or configurations too lightly. Don't make incompatible changes without good reasons!
23+
24+
## Documentation
25+
* The docs are in the [docs](docs) and [examples](examples) folders in the git repository, so people can easily find the suitable docs for the current git revision.
26+
* Documentation should be kept up-to-date. This means, whenever you add a new API method, add a new hook or change the database model, pack the relevant changes to the docs in the same pull request.
27+
28+
## Bug Reports
29+
30+
When opening new issues or commenting on existing issues please make
31+
sure discussions are related to concrete technical issues with the
32+
kmos software.
33+
34+
It's imperative that issue reports outline the steps to reproduce
35+
the defect. If the issue can't be reproduced it will be closed.
36+
Please provide [concise reproducible test cases](http://sscce.org/)
37+
and describe what results you are seeing and what results you expect.
38+
39+
## Documentation
40+
41+
The official documentation of kmos resides at
42+
[**ReadTheDocs.org**](https://kmos.rtfd.org).
43+
44+
## Code Contributions
45+
46+
The kmos project welcomes new contributors. Individuals making
47+
significant and valuable contributions over time are made
48+
[_Co-developers_](http://mhoffman.github.io/kmos/)
49+
50+
This document will guide you through the contribution process.
51+
52+
### Step 1: Fork
53+
54+
Fork the project [on Github](https://github.com/mhoffman/kmos)
55+
and check out your copy locally.
56+
57+
```text
58+
% git clone git@github.com:username/kmos.git
59+
% cd kmos
60+
% git remote add upstream git://github.com/mhoffman/kmos.git
61+
```
62+
63+
#### Dependencies
64+
65+
We bundle dependencies in the _third-party/_ directory that is not
66+
part of the project proper. Any changes to files in this directory or
67+
its subdirectories should be sent upstream to the respective projects.
68+
Please don't send your patch to us as we cannot accept it.
69+
70+
We do accept help in upgrading our existing dependencies or removing
71+
superfluous dependencies. If you need to add a new dependency it's
72+
often a good idea to reach out to the committers on the IRC channel or
73+
the mailing list to check that your approach aligns with the project's
74+
ideas. Nothing is more frustrating than seeing your hard work go to
75+
waste because your vision doesn't align with the project's.
76+
77+
### Step 2: Branch
78+
79+
Create a feature branch and start hacking:
80+
81+
```text
82+
% git checkout -b feature-branch
83+
```
84+
85+
We practice HEAD-based development, which means all changes are applied
86+
directly on top of master.
87+
88+
### Step 3: Commit
89+
90+
First make sure git knows your name and email address:
91+
92+
```text
93+
% git config --global user.name 'Santa Claus'
94+
% git config --global user.email 'santa@example.com'
95+
```
96+
97+
**Writing good commit messages is important.** A commit message
98+
should describe what changed, why, and reference issues fixed (if
99+
any). Follow these guidelines when writing one:
100+
101+
1. The first line should be around 50 characters or less and contain a
102+
short description of the change.
103+
2. Keep the second line blank.
104+
3. Wrap all other lines at 72 columns.
105+
4. Include `Fixes #N`, where _N_ is the issue number the commit
106+
fixes, if any.
107+
108+
A good commit message can look like this:
109+
110+
```text
111+
explain commit normatively in one line
112+
113+
Body of commit message is a few lines of text, explaining things
114+
in more detail, possibly giving some background about the issue
115+
being fixed, etc.
116+
117+
The body of the commit message can be several paragraphs, and
118+
please do proper word-wrap and keep columns shorter than about
119+
72 characters or so. That way `git log` will show things
120+
nicely even when it is indented.
121+
122+
Fixes #141
123+
```
124+
125+
The first line must be meaningful as it's what people see when they
126+
run `git shortlog` or `git log --oneline`.
127+
128+
### Step 4: Rebase
129+
130+
Use `git rebase` (not `git merge`) to sync your work from time to time.
131+
132+
```text
133+
% git fetch upstream
134+
% git rebase upstream/master
135+
```
136+
137+
### Step 5: Test
138+
139+
Bug fixes and features **should have tests**. Look at other tests to
140+
see how they should be structured.
141+
142+
Before you submit your pull request make sure you pass all the tests:
143+
144+
```text
145+
% ./go clean test
146+
```

‎.github/ISSUE_TEMPLATE.md

+19
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,19 @@
1+
### Expected behavior
2+
3+
### Actual behavior
4+
5+
[//]: # (Besides the text description, include any screenshot(s) that help us visualize the issue you're facing)
6+
7+
### Steps to reproduce the issue
8+
1.
9+
2.
10+
3.
11+
12+
### System information
13+
14+
- result of `kmos version`, operating system, link to model file
15+
16+
```
17+
18+
```
19+
[//]: # (If you experienced crashes, segfaults please also include a stacktrace below, For how-to read: https://github.com/kvirc/KVIrc/wiki/Grabbing-a-useful-backtrace.)

‎.github/PULL_REQUEST_TEMPLATE.md

+3
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
[//]: # (If your pull request is a fix to an open issue please add fixes #9999 to the commit comments.)
2+
[//]: # (If your proposal involves GUI improvements, add screenshots of before and after to help visualise the proposal on the fly.)
3+
#### Changes proposed

‎README.rst

+7
Original file line numberDiff line numberDiff line change
@@ -102,6 +102,13 @@ Please refer to
102102

103103
or links therein for tutorials, user guide, reference, and troubleshooting hints.
104104

105+
BUGS, ISSUES, TROUBLE
106+
#####################
107+
108+
This code is research code for scientists by scientists. If you
109+
believe you have hit a bug, have a feature request get in touch
110+
with us either via the `mailing list <https://groups.google.com/forum/#!forum/kmos-users>`_, `Gitter <https://gitter.im/mhoffman/kmos?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge>`_, or open an `issue <https://github.com/mhoffman/kmos/issues/new>`_ .
111+
105112
THANKS
106113
######
107114

0 commit comments

Comments
 (0)
Please sign in to comment.