Added notes about pull requests and internal preview (slic3r#3354)

New notes for contributing new code via PRs to Slic3r and feature requests.
klocs · Jul 9, 2016 · 2c6e4ab · 2c6e4ab
1 parent f7e37fa
commit 2c6e4ab
Showing 1 changed file with 13 additions and 1 deletion.
diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md
@@ -13,9 +13,21 @@ If possible, please include the following information when [reporting an issue](
     * Any error messages
 * If the issue is related to G-code generation, please include the following:
     * STL, OBJ or AMF input file (please make sure the input file is not broken, e.g. non-manifold, before reporting a bug)
-    * a screenshot of the G-code layer with the issue (e.g. using [Pronterface](https://github.com/kliment/Printrun))
+    * a screenshot of the G-code layer with the issue (e.g. using [Pronterface](https://github.com/kliment/Printrun) or preferably the internal preview tab in Slic3r).
+* If the issue is a request for a new feature, be ready to explain why you think it's needed.
+    * Doing more prepatory work on your end makes it more likely it'll get done. This includes the "how" it can be done in addition to the "what". 
+    * Define the "What" as strictly as you can. Consider what might happen with different infills than simple rectilinear.
 
 Please make sure only to include one issue per report. If you encounter multiple, unrelated issues, please report them as such.
 
 Simon Tatham has written an excellent on article on [How to Report Bugs Effectively](http://www.chiark.greenend.org.uk/~sgtatham/bugs.html) which is well worth reading, although it is not specific to Slic3r.
 
+Do you want to help fix issues in or add features to Slic3r? That's also very, very welcome :)
+
+* A good place to start if you can is to look over the [Pull Request or Bust](https://github.com/alexrj/Slic3r/milestones/Pull%20Request%20or%20Bust) milestone. This contains all of the things (mostly new feature requests) that there isn't time or resources to address at this time. 
+     * Things that are probably fixable via scripts (usually marked as such) have the lowest bar to getting something that works, as you don't need to recompile Slic3r to test.
+* If you're starting on an issue, please say something in the related issues thread so that someone else doesn't start working on it too.
+* If there's nothing in the [Pull Request or Bust](https://github.com/alexrj/Slic3r/milestones/Pull%20Request%20or%20Bust) milestone that interests you, the next place to look is for issues that don't have a milestone. Lots of people commit ideas to Slic3r, and it's difficult to keep up and sort through them.
+* Before sending a pull request, please make sure that the changes you are submitting are contained in their own git branch, as PRs merge histories.
+     * A common workflow is to fork the master branch, create your new branch and do your work there. git-rebase is also helpful for separating out unrelated changes. 
+* If you are pushing Slic3r code changes that touch the main application, it is very much appreciated if you write some tests that check the functionality of the code. It's much easier to vet and merge in code that includes tests and doing so will likely speed things up.