path: root/
diff options
authorJonathan L Long <>2015-07-30 03:16:31 (GMT)
committerJonathan L Long <>2015-07-30 03:16:31 (GMT)
commitccc35d361d6c90b7691b3ed8de7ea0678b488dff (patch)
tree98ff10f8244af575dc5dc72de53d750337e7e724 /
parent7f7085439cbe4eb9d5fff95b41d6345168398142 (diff)
[docs] add which will appear on GitHub new Issue/PR pages
Diffstat (limited to '')
1 files changed, 30 insertions, 0 deletions
diff --git a/ b/
new file mode 100644
index 0000000..8cd5e56
--- /dev/null
+++ b/
@@ -0,0 +1,30 @@
+# Contributing
+## Issues
+Specific Caffe design and development issues, bugs, and feature requests are maintained by GitHub Issues.
+_Please do not post usage, installation, or modeling questions, or other requests for help to Issues._
+Use the [caffe-users list](!forum/caffe-users) instead. This helps developers maintain a clear, uncluttered, and efficient view of the state of Caffe.
+When reporting a bug, it's most helpful to provide the following information, where applicable:
+* What steps reproduce the bug?
+* Can you reproduce the bug using the latest [master](, compiled with the `DEBUG` make option?
+* What hardware and operating system/distribution are you running?
+* If the bug is a crash, provide the backtrace (usually printed by Caffe; always obtainable with `gdb`).
+Try to give your issue a title that is succinct and specific. The devs will rename issues as needed to keep track of them.
+## Pull Requests
+Caffe welcomes all contributions.
+See the [contributing guide]( for details.
+Briefly: read commit by commit, a PR should tell a clean, compelling story of _one_ improvement to Caffe. In particular:
+* 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.
+* Similarly, each commit should be a small, atomic change representing one step in development. PRs should be made of many commits where appropriate.
+* 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.
+* Anything nonobvious from the code should be explained in comments, commit messages, or the PR description, as appropriate.