Skip to content

Latest commit

 

History

History
49 lines (42 loc) · 5.01 KB

CONTRIBUTING.md

File metadata and controls

49 lines (42 loc) · 5.01 KB
Raw

Issues, Tickets, however you may call them

Read the following short instructions fully and follow them if you want your ticket to be taken care of and not closed again directly! They are linked on top of every new issue form, so don't say nobody warned you afterwards.

  • Read the FAQ
  • Always create one ticket for one purpose. So don't mix two or more feature requests, support requests, bugs etc into one ticket. If you do, your ticket will be closed!
  • If you want to report a bug, READ AND FOLLOW How to file a bug report! Tickets will be automatically checked if they comply with the requirements outlined in that wiki node! Other then what's written in there (and really EVERYTHING that is written in there!) you don't have to do anything special with your ticket. Listen to what GitIssueBot might have to say to you!
  • If you want to post a request of any kind (feature request, documentation request, ...), add [Request] to your issue's title!
  • If you need support with a problem of your installation (e.g. if you have problems getting the webcam to work) or have a general question, the issue tracker is not the right place. Consult the Mailinglist or the Google+ Community instead!
  • If you are a developer that wants to brainstorm a pull request or possible changes to the plugin system, add [Brainstorming] to your issue's title! (see below).
  • If you have another reason for creating a ticket that doesn't fit any of the above categories, it's something better suited for the Mailinglist or the Google+ Community.

Following these guidelines (especially EVERYTHING mentioned in "How to file a bug report") is necessary so the tickets stay manageable - you are not the only one with an open issue, so please respect that you have to play by the rules so that your problem can be taken care of. Tickets not playing by the rules will be closed without further investigation!.

Pull Requests

  1. If you want to add a new feature to OctoPrint, please always first consider if it wouldn't be better suited for a plugin. As a general rule of thumb, any feature that is only of interest to a small sub group should be moved into a plugin. If the current plugin system doesn't allow you to implement your feature as a plugin, create a "Brainstorming" ticket to get the discussion going how best to solve this in OctoPrint's plugin system - maybe that's the actual PR you have been waiting for to contribute :)
  2. If you plan to make any large changes to the code or appearance, please open a "Brainstorming" ticket first so that we can determine if it's a good time for your specific pull request. It might be that I'm currently in the process of making heavy changes to the code locations you'd target as well, or your approach doesn't fit the general "project vision", and that would just cause unnecessary work and frustration for everyone or possibly get the PR rejected.
  3. When adding code to OctoPrint, make sure you follow the current coding style. That means tabs instead of spaces in the python files (yes, I know that this goes against PEP-8, I don't care) and space instead of tabs in the Javascript sources, english language (that means code, variables, comments!), comments where necessary (tell why the code does something like it does it, structure your code), following the general architecture. If your PR needs to make changes to the Stylesheets, change the .less files from which the CSS is compiled. PRs that contain direct changes to the compiled CSS will be closed.
  4. Test your changes thoroughly. That also means testing with usage scenarios you don't normally use, e.g. if you only use access control, test without and vice versa. If you only test with your printer, test with the virtual printer and vice versa. State in your pull request how your tested your changes.
  5. Please create all pull requests against the devel branch.
  6. Create one pull request per feature/bug fix.
  7. Create a custom branch for your feature/bug fix and use that as base for your pull request. Pull requests directly against your version of devel will be closed.
  8. In your pull request's description, state what your pull request is doing, as in, what feature does it implement, what bug does it fix. The more thoroughly you explain your intent behind the PR here, the higher the chances it will get merged fast.

History

  • 2015-01-23: More guidelines for creating pull requests, support/questions redirected to Mailinglist/G+ community
  • 2015-01-27: Added another explicit link to the FAQ