Community is the foundation of Chef. We believe that the best way to build software is in close collaboration with the people who use it, and the best way to use software is alongside those who build it.
To this end, we develop our software in the open and, where possible, encourage public contribution as a means to accelerate the product quality with transparency and community in mind. Where possible, we encourage that contributors use our public repositories which can be found at Chef's GitHub.
An example subset of popular public repositories you can view:
https://github.com/chef/chef-workstation
https://github.com/chef/chef-server
https://github.com/chef/automate
Making a Public Bug Submission
If you are making a public bug submission, we'd suggest that you look at GitHub's guidance on how to navigate the issues in a repository.
Once you've confirmed there is no equivalent/comparative issue to the behaviour you are experiencing, you should raise a new GitHub Issue against that repository and include/outline the following criteria:
- A summary of the issue
- The reproduction steps
- The expected behaviour/outcome
- The actual behaviour/outcome
- Any additional context including supporting code snippets, error codes and stacktraces
Our engineering teams triage publicly raised issues on the backlog and will tend to any public issue as soon as reasonably possible. This ensures that the issue is visible to any other interested parties and historically available for those that search for it at a later date.
Making a Private Bug Submission
There is a huge mutual benefit to leveraging publicly-developed open source software models like Chef's, and whilst we'd love for all of our contributors to be able to do so, we understand that not everyone will be in a position to. If you are making a Bug submission as a trackable ticket through Chef Support, then we ask that they are correctly identified by choosing the "Bug Submission" form type from the issue drop down menu:
Submission Data
Subject - A summary of the bug submission.
Description - A description of the bug submission, including:
- The scenario in which the bug is observed
- The configuration of the application/product
- At what level you perceive this behaviour (within a cookbook, a subset of nodes, a profile etc)
Product - the product you wish to see the bug submission triaged against
Product Version - the version of the product that is impacted
Business Value - the associated value this has to your business needs
GitHub Issue - if a GitHub Issue has previously been raised publicly, please provide a link to it in this field and this will be relayed internally
Reproduction Steps - the reproduction steps necessary to reproduce the bug. Please make these clear, bullet-pointed or numbered and ensure they convey the exact steps needed so we can verify the bug
Expected Behaviour/Outcome - the behaviour/outcome you expect as a result of the process
Actual Behaviour/Outcome - the actual/outcome you expect as a result of the process (include the error code and stacktrace)
Attachments - if necessary, provide UI screenshots to describe the problem the feature request would address. Feel free to annotate these for the product team's benefit