Skip to content

Commit ccc35d3

Browse files
committed
[docs] add CONTRIBUTING.md which will appear on GitHub new Issue/PR pages
1 parent 7f70854 commit ccc35d3

File tree

1 file changed

+30
-0
lines changed

1 file changed

+30
-0
lines changed

CONTRIBUTING.md

+30
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,30 @@
1+
# Contributing
2+
3+
## Issues
4+
5+
Specific Caffe design and development issues, bugs, and feature requests are maintained by GitHub Issues.
6+
7+
_Please do not post usage, installation, or modeling questions, or other requests for help to Issues._
8+
Use the [caffe-users list](https://groups.google.com/forum/#!forum/caffe-users) instead. This helps developers maintain a clear, uncluttered, and efficient view of the state of Caffe.
9+
10+
When reporting a bug, it's most helpful to provide the following information, where applicable:
11+
12+
* What steps reproduce the bug?
13+
* Can you reproduce the bug using the latest [master](https://github.com/BVLC/caffe/tree/master), compiled with the `DEBUG` make option?
14+
* What hardware and operating system/distribution are you running?
15+
* If the bug is a crash, provide the backtrace (usually printed by Caffe; always obtainable with `gdb`).
16+
17+
Try to give your issue a title that is succinct and specific. The devs will rename issues as needed to keep track of them.
18+
19+
## Pull Requests
20+
21+
Caffe welcomes all contributions.
22+
23+
See the [contributing guide](http://caffe.berkeleyvision.org/development.html) for details.
24+
25+
Briefly: read commit by commit, a PR should tell a clean, compelling story of _one_ improvement to Caffe. In particular:
26+
27+
* A PR should do one clear thing that obviously improves Caffe, and nothing more. Making many smaller PRs is better than making one large PR; review effort is superlinear in the amount of code involved.
28+
* Similarly, each commit should be a small, atomic change representing one step in development. PRs should be made of many commits where appropriate.
29+
* Please do rewrite PR history to be clean rather than chronological. Within-PR bugfixes, style cleanups, reversions, etc. should be squashed and should not appear in merged PR history.
30+
* Anything nonobvious from the code should be explained in comments, commit messages, or the PR description, as appropriate.

0 commit comments

Comments
 (0)