├── .expeditor └── config.yml ├── .github ├── CODEOWNERS ├── ISSUE_TEMPLATE │ ├── bug.md │ ├── feature-request.md │ └── membership.md ├── PULL_REQUEST_TEMPLATE.md └── workflows │ └── lint.yaml ├── .mdl.rb ├── .mdlrc ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── DCO.md ├── Makefile ├── README.md ├── checklists ├── managing-pull-requests.md └── new-project.md ├── communication ├── README.md ├── communication-faq.md ├── community-meetings.md ├── decider.md ├── project-eol.md ├── saying-no.md ├── support-boundaries.md ├── triage.md └── video-conferencing.md ├── contributors ├── contributor-entitlement-program.md ├── distribution-guidelines.md ├── guide │ ├── README.md │ ├── collaborative-dev.md │ ├── community-expectations.md │ ├── contributor-cheatsheet.md │ ├── design-proposals.md │ ├── help-wanted.md │ ├── project-planning.md │ ├── pull-requests.md │ └── ways-to-contribute.md └── project-forks-guidelines.md ├── cspell.json ├── distributions ├── distribution-guidelines.md └── distribution-list.md ├── governance.md ├── guilds └── README.md ├── physical-spaces-code-of-conduct.md ├── project-membership.md ├── projects-list.md ├── projects ├── builder.md ├── chef-automate.md ├── chef-desktop.md ├── chef-infra-server.md ├── chef-infra.md ├── chef-workstation.md ├── habitat-core-plans.md ├── habitat.md ├── infra-packages-team.md ├── inspec-cloud.md ├── inspec.md └── supermarket.md └── repo-management ├── README.md ├── github-labels.md ├── project-required-setup.md └── repo-states.md /.expeditor/config.yml: -------------------------------------------------------------------------------- 1 | --- 2 | github: 3 | # clean up PR branches when they've merged 4 | delete_branch_on_merge: true 5 | # DCO isn't needed because this repo isn't code. 6 | enforce_dco_signoff: false -------------------------------------------------------------------------------- /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | # Order is important. The last matching pattern has the most precedence. 2 | 3 | * @chef/chef-oss-process-and-practices 4 | .expeditor/** @chef/jex-team 5 | projects/chef-infra.md @chef/chef-infra-owners 6 | projects/chef-infra-server.md @chef/chef-infra-server-owners 7 | projects/chef-workstation.md @chef/chef-workstation-owners 8 | projects/supermarket.md @chef/supermarket-owners 9 | projects/automate.md @automate-maintainers -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/bug.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Bug Report 3 | about: Explain how the Chef Software Open Source Communities documentation is incorrect 4 | labels: 'Status: Untriaged' 5 | --- 6 | 7 | 8 | 9 | # Describe the problem 10 | 11 | 12 | 13 | ## Possible Solution 14 | 15 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/feature-request.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Feature request 3 | about: Suggest an idea for this project 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | # Redirect Alert! 11 | 12 | ## Submit your feature request via the [Chef Ideas Portal](https://chef-software.ideas.aha.io/) -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/membership.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Project Membership Request 3 | about: Request membership in a Chef Software Inc. OSS project 4 | title: 'REQUEST: New membership for ' 5 | labels: 'Status: Untriaged' 6 | 7 | --- 8 | 9 | ### GitHub Username 10 | e.g. (at)example_user 11 | 12 | ### Project you are requesting membership in 13 | e.g. chef/chef 14 | 15 | ### Requirements 16 | - [ ] I have reviewed [the community membership guidelines](https://github.com/chef/chef-oss-practices/project-membership.md) 17 | - [ ] I have enabled 2FA on my GitHub account (https://github.com/settings/security) 18 | - [ ] I have joined the project's mailing list, e.g [Chef's](https://discourse.chef.io) or [Habitat's](https://forums.habitat.sh/) 19 | - [ ] I am actively contributing to 1 or more Chef Software Inc. projects 20 | - [ ] I have two sponsors that meet the sponsor requirements listed in [the community membership guidelines](https://github.com/chef/chef-oss-practices/project-membership.md) 21 | - [ ] I have spoken to my sponsors ahead of this application, and they have agreed to sponsor my application 22 | 23 | ### Sponsors 24 | - (at)sponsor-1 25 | - (at)sponsor-2 26 | 27 | ### List of contributions to the project 28 | - PRs reviewed / authored 29 | - Issues responded to 30 | - Questions answered in GitHub/Mailing List/StackOverflow 31 | -------------------------------------------------------------------------------- /.github/PULL_REQUEST_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## Description 4 | 5 | 6 | ## Related Issue 7 | 8 | 9 | 10 | ## Types of changes 11 | 12 | - [ ] Bug fix (non-breaking change which fixes an issue) 13 | - [ ] New content (non-breaking change) 14 | - [ ] Breaking change (a content change which would break existing functionality or processes) 15 | 16 | ## Checklist: 17 | 18 | 19 | - [ ] I have read the **CONTRIBUTING** document. 20 | -------------------------------------------------------------------------------- /.github/workflows/lint.yaml: -------------------------------------------------------------------------------- 1 | --- 2 | name: markdownlint 3 | 4 | on: [push] 5 | 6 | jobs: 7 | lint: 8 | runs-on: ubuntu-latest 9 | steps: 10 | - name: Check out code 11 | uses: actions/checkout@main 12 | - name: Run mdl 13 | uses: actionshub/markdownlint@main 14 | -------------------------------------------------------------------------------- /.mdl.rb: -------------------------------------------------------------------------------- 1 | all 2 | rule 'MD013', :line_length => 200 3 | exclude_tag :line_length 4 | exclude_rule 'MD005' 5 | exclude_rule 'MD024' 6 | exclude_rule 'MD026' 7 | exclude_rule 'MD029' 8 | exclude_rule 'MD041' 9 | -------------------------------------------------------------------------------- /.mdlrc: -------------------------------------------------------------------------------- 1 | style "#{File.dirname(__FILE__)}/.mdl.rb" 2 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Code of Conduct 5 | 6 | - [Code of Conduct](#code-of-conduct) 7 | - [Summary](#summary) 8 | - [Code of Conduct](#code-of-conduct-1) 9 | - [Anti-Harassment Policy](#anti-harassment-policy) 10 | - [Participants Procedure for Incident Handling in Physical Spaces](#participants-procedure-for-incident-handling-in-physical-spaces) 11 | - [Enforcement](#enforcement) 12 | - [Consequences of Unacceptable Behavior](#consequences-of-unacceptable-behavior) 13 | - [Our Responsibilities](#our-responsibilities) 14 | - [Contact Information](#contact-information) 15 | - [Scope](#scope) 16 | - [Influences](#influences) 17 | - [Copyright](#copyright) 18 | 19 | ## Summary 20 | 21 | Diversity is one of the greatest strengths that a community can have, and many times that strength is born from the friction that can only come through sharing differing perspectives. The goal of this document is to ensure that we create spaces welcoming to new and existing participants, and that those conversations that arise from friction are productive. 22 | 23 | We are dedicated to providing an inclusive and harassment-free experience for anyone who participates in events or digital spaces that are organized, hosted, or managed by Chef – whether that is ChefConf, Community Summits, MeetUps, training, or any online space. We do not tolerate harassment in any form. 24 | 25 | We value the participation of each member of the Chef community and want all participants to have an enjoyable and fulfilling experience. Accordingly, all participants are expected to show respect and courtesy to other participants at any Chef-related events or digital spaces, whether officially sponsored by Progress or not. 26 | 27 | To make clear what is expected: all employees, delegates, participants, speakers, exhibitors, organizers, and volunteers at any Chef event or Chef-managed digital space are required to conform to the following Code of Conduct. Organizers and moderators will enforce this code wherever appropriate. 28 | 29 | ## Code of Conduct 30 | 31 | Chef is dedicated to providing a harassment-free experience for everyone, regardless of gender, sexual orientation, age, disability, physical appearance, body size, race, veteran status, immigration status, or religion. We do not tolerate harassment of event/digital community participants in any form. 32 | 33 | All communication should be appropriate for a professional audience that includes people of many different backgrounds. Sexual language and imagery is not appropriate for any Chef-managed event or online platform, including talks and digital community activities. 34 | 35 | Be kind to others. Do not insult or put down other participants. Behave professionally. Remember that harassment and sexist, racist, ageist, or exclusionary jokes are not appropriate for any event or digital activity. 36 | 37 | ## Anti-Harassment Policy 38 | 39 | Harassment comes in many forms, including but not limited to: 40 | 41 | - Offensive comments related to gender, sexual orientation, age, disability, physical appearance, body size, race, veteran status, immigration status, or religion 42 | - Posting/Exposing sexually explicit or violent images 43 | - Deliberate (or implied) intimidation 44 | - Stalking or persistent following 45 | - Intrusive or otherwise unwanted photography or recording 46 | - Sustained disruption of talks or other events 47 | - Inappropriate physical contact or unwelcome sexual attention 48 | - Posting (or threatening to post) a person's personally identifying information ("doxing") 49 | - Advocating for, or encouraging, any of the above behavior 50 | 51 | Participants asked to stop any harassing behavior are expected to comply immediately. Further unacceptable behavior will result in escalating sanctions. 52 | 53 | Exhibitors in the expo hall, sponsor or vendor booths, or similar activities are also subject to the anti-harassment policy. In particular, exhibitors should not use sexualized images, activities, or other material. Booth staff (including volunteers) should not use sexualized clothing/uniforms/costumes, or otherwise create an unprofessional environment. 54 | 55 | Be careful in the words that you choose, no matter your intention with those words. Remember that sexist, racist, ageist, and other exclusionary jokes can be offensive to those around you. If you think your conversation is making another community member uncomfortable, stop, apologize, and move forward. 56 | 57 | For physical spaces, event staff can be asked to help participants contact hotel/venue security or local law enforcement, provide escorts, or otherwise assist those experiencing harassment to feel safe for the duration of the event. We value your participation. 58 | 59 | ## Participants Procedure for Incident Handling in Physical Spaces 60 | 61 | This procedure has been adopted from the Ada Initiative's guide titled "Conference anti-harassment/Responding to Reports". 62 | 63 | All of our staff are informed of the Code of Conduct policy and guide for handling harassment at the event. Report the harassment incident (preferably in writing) to an event staff member. All reports are confidential. Please do not disclose information about the incident publicly until the staff have had sufficient time in which to address the situation. This is as much for your safety and protection as it is for the other participants. When reporting the event to staff, try to gather as much information as available, but do not interview people about the incident. Staff will assist you in writing the report/collecting information. 64 | 65 | The important information consists of: 66 | 67 | - Identifying information (eg. name) of the participant doing the harassing 68 | - The behavior that was in violation 69 | - The approximate time and date of the behavior 70 | - The circumstances surrounding the incident 71 | - Other people involved in the incident 72 | 73 | If everyone is presently safe, staff will only involve law enforcement or security at a victim's request. If you do feel your safety in jeopardy, please do not hesitate to contact local law enforcement. If you do not have a cell phone, you can use any hotel phone or simply ask a staff member. 74 | 75 | Event staff requests that they be your first resource when reporting an incident, so that they may enforce the Code of Conduct and take quick action toward a resolution. 76 | 77 | If at all possible, all reports should be made directly to the team responsible, listed under [Contact Information](#Contact-Information). 78 | 79 | ## Enforcement 80 | 81 | Instances of abusive, harassing, or otherwise unacceptable behavior should be reported by contacting any of the Community Organizers [listed below](#Contact-Information) directly. All complaints will be reviewed, investigated, and will result in a response that is deemed necessary and appropriate to the circumstances. The team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. 82 | 83 | Community Organizers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. 84 | 85 | ## Consequences of Unacceptable Behavior 86 | 87 | Anyone who is asked to stop unacceptable behavior is expected to comply immediately. 88 | 89 | Crafting a list of punitive actions would be inadequate and incomplete. Each incident will be dealt with on a case-by-case basis. 90 | 91 | Our first response should always be to ensure the immediate safety and well being of all parties involved. In the ideal case, an attempt to stop and prevent the violating behavior would be made before any punitive action is decided. 92 | 93 | When punitive action is warranted, one or more of the following remedies may be used: 94 | 95 | - Expulsion from the space where the incident occurred with no refund 96 | - Removal from the space where the incident occurred for a period of time 97 | - Banned from the space where the incident occurred indefinitely 98 | - Banned from one or more upcoming events 99 | 100 | If a community member engages in unacceptable behavior, the community organizers will take action that they deem appropriate -- up to and including a temporary ban or permanent expulsion from the community _without warning_ (and without refund, in the case of a paid event). If you have been involved in unacceptable behavior with current Chef community members outside the boundaries of the Chef Community, the Community Organizers retain the right to treat those external incidents in the same manner as internal incidents. 101 | 102 | Any physical violence _or_ intimidation, threatened or acted on, is a serious offense and will result in immediate exclusion from the community and appropriate follow up with law enforcement. 103 | 104 | ## Our Responsibilities 105 | 106 | Community Organizers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. 107 | 108 | Community Organizers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, messages, tweets, and other contributions that are not aligned with this Code of Conduct (in letter or in spirit), or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. 109 | 110 | ## Contact Information 111 | 112 | If you are being harassed, notice that someone else is being harassed, or have any other concerns, please contact a Community organizer. 113 | 114 | The following are the various roles of our Community Organizers and the person(s) assigned to each role: 115 | 116 | - The Deciders have final say on community guidelines and final authority on correct actions and appeals 117 | - The Community Organizers may be assigned for each area where the community convenes online (Slack, email list, GitHub, etc.). Community Organizers are employees of Progress. They act in good faith to help enforce our community guidelines and respond to incidents when they occur 118 | - A Community Member is anyone who participates with the community whether in-person or via online channels. Community members are responsible for following the community guidelines, suggesting updates to the guidelines when warranted, and helping enforce community guidelines 119 | 120 | | Role | Name | Contact Info | 121 | | -------------------- | ------------- | ----------------- | 122 | | Decider | benny Vasquez | bvasquez@chef.io | 123 | | Community Organizers | Various folks | community@chef.io | 124 | 125 | ## Scope 126 | 127 | Our community will convene in both physical and digital spaces. This Code of Conduct applies within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by community organizers as needed. 128 | 129 | ## Influences 130 | 131 | This Code of Conduct was originally forked from the example policy from the [Geek Feminism wiki, created by the Ada Initiative and other volunteers](http://geekfeminism.wikia.com/wiki/Conference_anti-harassment/Policy), which is under a Creative Commons Zero (CC0) license. It is also based on the following: 132 | 133 | - [Contributor Covenant](http://contributor-covenant.org/), version 1.4, available [here](http://contributor-covenant.org/version/1/4/) 134 | - [Rust Code of Conduct](https://www.rust-lang.org/en-US/conduct.html) 135 | - Citizen Code of Conduct (site no longer online) 136 | - [Django Code of Conduct](https://www.djangoproject.com/conduct/) 137 | - [PyCon Code of Conduct](https://github.com/python/pycon-code-of-conduct). 138 | 139 | ## Copyright 140 | 141 | This Code of Conduct is in the public domain. In jurisdictions that do not allow for this, this work is available under CC0. To the extent possible under law, the person who associated CC0 with this work has waived all copyright and related or neighboring rights to this work 142 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Contributing to the Community Repo 5 | 6 | Welcome to the Chef Community contributing guide. We are excited about the prospect of you joining our [community](https://github.com/chef/chef-oss-practices)! 7 | 8 | ## Getting Started 9 | 10 | This document outlines the process of contributing to this specific Community repo. See our overall community contribution documentation for more information on contributing to our various projects: 11 | 12 | - [Contributor Guide](contributors/guide/README.md) - Main contributor documentation 13 | - [Contributor Cheat Sheet](contributors/guide/contributor-cheatsheet.md) - List of resources for contributors at a glance 14 | 15 | ## Contributing to Project Specific Sections 16 | 17 | Each project may or may not have its own policies for editing their section of this repository. 18 | 19 | Edits in the Team's sub-directory should follow any additional guidelines described by the respective team leads in the sub-directory's `CONTRIBUTING.md` file (e.g. [teams/habitat/CONTRIBUTING.md](teams/habitat/CONTRIBUTING.md)). 20 | 21 | Attending a [project team meeting](projects/), or posting on their mailing list might be prudent if you want to make extensive contributions. 22 | -------------------------------------------------------------------------------- /DCO.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Developer Certificate of Origin 5 | 6 | All Chef Software Inc. projects utilize a Developer Certificate of Origin (DCO) to ensure that each commit was written by the author or that the author has the appropriate rights necessary to contribute the change. Specifically, we utilize [Developer Certificate of Origin, Version 1.1](http://developercertificate.org/) 7 | 8 | ```text 9 | Developer Certificate of Origin 10 | Version 1.1 11 | 12 | Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 13 | 660 York Street, Suite 102, 14 | San Francisco, CA 94110 USA 15 | 16 | Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. 17 | 18 | 19 | Developer's Certificate of Origin 1.1 20 | 21 | By making a contribution to this project, I certify that: 22 | 23 | (a) The contribution was created in whole or in part by me and I 24 | have the right to submit it under the open source license 25 | indicated in the file; or 26 | 27 | (b) The contribution is based upon previous work that, to the best 28 | of my knowledge, is covered under an appropriate open source 29 | license and I have the right under that license to submit that 30 | work with modifications, whether created in whole or in part 31 | by me, under the same open source license (unless I am 32 | permitted to submit under a different license), as indicated 33 | in the file; or 34 | 35 | (c) The contribution was provided directly to me by some other 36 | person who certified (a), (b) or (c) and I have not modified 37 | it. 38 | 39 | (d) I understand and agree that this project and the contribution 40 | are public and that a record of the contribution (including all 41 | personal information I submit with it, including my sign-off) is 42 | maintained indefinitely and may be redistributed consistent with 43 | this project or the open source license(s) involved. 44 | ``` 45 | 46 | Each commit must include a DCO which looks like this: 47 | 48 | `Signed-off-by: Joe Smith ` 49 | 50 | The project requires that the name used is your real name. Neither anonymous contributors nor those utilizing pseudonyms will be accepted. 51 | 52 | Git makes it easy to add this line to your commit messages. Make sure the `user.name` and `user.email` are set in your git configs. Use `-s` or `--signoff` to add the Signed-off-by line to the end of the commit message. 53 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | .PHONY: spellcheck 2 | 3 | spellcheck: 4 | cspell **/*.md *.md 5 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | - **[Project State](https://github.com/chef/chef-oss-practices/blob/master/repo-management/repo-states.md): Active** 5 | - **Issues [Response Time Maximum](https://github.com/chef/chef-oss-practices/blob/master/repo-management/repo-states.md): 7 days** 6 | - **Pull Request [Response Time Maximum](https://github.com/chef/chef-oss-practices/blob/master/repo-management/repo-states.md): 7 days** 7 | 8 | # Chef Software Open Source Communities 9 | 10 | Welcome to the Chef Software Open Source communities! 11 | 12 | This is a starting point for contributing to all of Chef's software and a wonderful spot for information on how to join in on the fun. 13 | 14 | Looking for something specific? Check out our [Table of Contents](#table-of-contents). 15 | 16 | To learn more about each of our project's structure and organization, please refer to [Governance](./governance.md). 17 | 18 | We are currently rolling out these processes to all of Chef's Open Source projects in stages and will be iterating as we go - we would love you to [contribute](./CONTRIBUTING.md)! 19 | 20 | ## Inspiration 21 | 22 | The practices in this repo are inspired by [Adam Jacob's book on Free and Sustainable Open Source Communities](https://sfosc.org/). Although we are inspired by it, this repo is not a full implementation of the practices described in that book. However, this is only the first iteration of this repo. We expect this repo to continue to evolve and grow as we learn. We may integrate more of Adam's book into this repo in the future. 23 | 24 | ## How We're Organized 25 | 26 | Chef Software (the company) produces many products such as Chef Infra, Chef InSpec, Chef Habitat, and Chef Automate. Each of these products is fully open source and comprised of one or more open source projects. For instance, the Chef Infra product is comprised of chef, ohai, various mixlib projects, and other interdependent libraries. The project and/or sub-project scope is defined in the README.md file in each individual project's GitHub repository. 27 | 28 | All Chef projects operate under governance determined by the Chef OSS Practices Committee. These policies are documented under [Governance](./governance.md); however, *Teams* can have their own [policy for contribution](./repo-management/project-required-setup.md#CONTRIBUTING.md), communication standards, etc. so long as those policies meet the base governance policy. 29 | 30 | We decide on the long term plan for projects through [Project planning](./contributors/guide/project-planning.md) and our [triage and prioritization](./contributors/guide/#issues-management-or-triage.md) processes. 31 | 32 | ## Communicating With Us 33 | 34 | The [communication](./communication/README.md) page lists communications channels such as chat, GitHub issues, mailing lists, conferences, etc. 35 | 36 | For more detailed information, check the README.md in a project's repository. 37 | 38 | ## Getting Started Contributing 39 | 40 | A first step towards contributing is to pick from the [list of Chef Software Projects](./projects-list.md). 41 | 42 | Once you've selected a project to contribute to, be sure to read the team's [contribution guide](./CONTRIBUTING.md). That guide will provide information on issues in need of contributors, team meetings schedules, and Slack channels / mailing lists where project discussions take place. 43 | 44 | The [Contributor Guide](./contributors/guide/README.md) provides detailed instructions on how to get your code accepted to Chef Software projects, including: 45 | 46 | 1. How to [file an issue](./contributors/guide/README.md#file-an-issue) 47 | 2. How to [find something to work on](./contributors/guide/README.md#find-something-to-work-on) 48 | 3. How to [open a pull request](./contributors/guide/README.md#open-a-pull-request) 49 | 50 | ## Creating a New Chef Open Source Project 51 | 52 | Creating a new project? Check out the [repo management](./repo-management/README.md) documentation for information on how to set your project up. 53 | 54 | ## Project Membership 55 | 56 | We encourage all contributors to become project members. We aim to grow an active, healthy community of contributors, reviewers, and project owners. Learn about requirements and perks of membership in our [Project Membership](./project-membership.md) page. 57 | 58 | ## Table of Contents 59 | 60 | - [README](./README.md) 61 | - [Contributing](./CONTRIBUTING.md) 62 | - [Project Membership](./project-membership.md) 63 | - [Projects List](./projects-list.md) 64 | - [Governance](./governance.md) 65 | - [Developer Certificate of Origin](./DCO.md) 66 | 67 | ### Code of Conduct 68 | 69 | - [Physical and Virtual Spaces Code of Conduct](./CODE_OF_CONDUCT.md) 70 | 71 | ### Contributors 72 | 73 | - [Contributor Licenses through the Entitlement Program](./contributors/contributor-entitlement-program.md) 74 | 75 | ### Distributions 76 | 77 | - [Distribution Guidelines](./distributions/distribution-guidelines.md) 78 | - [Distribution List](./distributions/distribution-list.md) 79 | 80 | ### Guide 81 | 82 | - [README](./contributors/guide/README.md) 83 | - [Collaborative Development](./contributors/guide/collaborative-dev.md) 84 | - [Community Expectations](./contributors/guide/community-expectations.md) 85 | - [Contributor Cheatsheet](./contributors/guide/contributor-cheatsheet.md) 86 | - [Design Proposals](./contributors/guide/design-proposals.md) 87 | - [Help Wanted](./contributors/guide/help-wanted.md) 88 | - [Project Planning](./contributors/guide/project-planning.md) 89 | - [Pull Requests](./contributors/guide/pull-requests.md) 90 | - [Ways to Contribute](./contributors/guide/ways-to-contribute.md) 91 | 92 | ### Communication 93 | 94 | - [README](./communication/README.md) 95 | - [Community Meetings](./communication/community-meetings.md) 96 | - [Decider](./communication/decider.md) 97 | - [Triage](./communication/triage.md) 98 | - [Project End of Life](./communication/project-eol.md) 99 | - [Video Conferencing](./communication/video-conferencing.md) 100 | - [Support Boundaries](./communication/support-boundaries.md) 101 | - [Saying No](./communication/saying-no.md) 102 | - [Communication FAQ](./communication/communication-faq.md) 103 | 104 | ### Repo Management 105 | 106 | - [README](./repo-management/README.md) 107 | - [Project Setup](./repo-management/project-required-setup.md) 108 | - [Repo States](./repo-management/repo-states.md) 109 | - [GitHub Labels](./repo-management/github-labels.md) 110 | 111 | ### Guilds 112 | 113 | - [README](./guilds/README.md) 114 | 115 | ### Checklists 116 | 117 | - [Managing Pull Requests](./checklists/managing-pull-requests.md) 118 | - [New Projects](./checklists/new-project.md) 119 | -------------------------------------------------------------------------------- /checklists/managing-pull-requests.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Managing Pull Requests 5 | 6 | * Respond within the committed response time maximum 7 | * Questions to ask when reviewing: 8 | * Does the PR add value? 9 | * Does it fix an existing issue? 10 | * Does it replicate work done elsewhere? 11 | * Does it affect in progress work? 12 | * Will merging it make contributions by others more difficult? 13 | * Merge conflicts 14 | * Is the code: 15 | * Functional 16 | * Safe (potentially breaking other code as well as security) 17 | * Maintainable 18 | * Compliant with _existing_ contribution and style guides 19 | * If the PR doesn't add value: 20 | * Respond 21 | * Communicate and be supportive 22 | * Both of the contributor and their work 23 | * Always say thank you 24 | * Always say why 25 | * Explicitly close the PR 26 | * Even if you might look at it again in future 27 | -------------------------------------------------------------------------------- /checklists/new-project.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # New Project Checklist 5 | 6 | * Repository configuration 7 | * Description 8 | * Github topics 9 | * Repository labels 10 | * Disable projects/wiki if unused 11 | * Documentation 12 | * README 13 | * Local installation setup instructions 14 | * Development and Testing process 15 | * Design Documentation 16 | * Style guide 17 | * Additional files 18 | * CODE_OF_CONDUCT.md 19 | * CONTRIBUTING.md 20 | * LICENSE 21 | * TEAMS.md 22 | * .github/CODEOWNERS 23 | * .github/ISSUE_TEMPLATE.md 24 | * .github/PULL_REQUEST_TEMPLATE.md 25 | * Other tasks 26 | * Slack integration (`/github` command) 27 | -------------------------------------------------------------------------------- /communication/README.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Communication 5 | 6 | The Chef Community is committed to keeping our space a fun, safe, and productive place to be, so please review the Community [Code of Conduct](../CODE_OF_CONDUCT.md) before getting started. In general: 7 | 8 | - *Be Kind.* We get more done when people are helpful and respectful of one another. Plus, it feels better. 9 | - *Listen.* Try to understand someone's position before you respond to their suggestion or idea. Ask clarifying questions if something doesn't make sense to you. Understand that others may have a perspective, experience, or technical context that is different from your own. 10 | - *Be Patient.* We have no team dedicated solely to Community support, so responses will be semi-synchronous, or, more likely, asynchronous. Know that the Community appreciates all your contributions, and we're working to be as responsive as possible. 11 | 12 | ## Reporting Code of Conduct Violations 13 | 14 | Please email the Community Advocates listed in the [Code of Conduct](../CODE_OF_CONDUCT.md#roles). 15 | 16 | ## Reporting Security Vulnerabilities 17 | 18 | Please email security@chef.io to report security vulnerabilities. 19 | 20 | ## Communication Channels 21 | 22 | We have four communication channels, each with its own specific purpose. 23 | 24 | If you have questions about why we choose to use certain channels in certain ways, please check out the [Frequently Asked Questions](communication-faq.md). 25 | 26 | ### GitHub 27 | 28 | GitHub is the Chef Community's preferred durable medium for open and transparent development of software. All development conversation must be captured in GitHub. Any decisions made in internal Chef Slack channels, Zoom sessions, or any other communication medium must be summarized in GitHub. Please also link to the GitHub issue or pull request in chat once it is opened. 29 | 30 | ### Community Slack 31 | 32 | Sometimes it will make sense to have a brief, non-durable conversation about the development of a project. Have these exchanges in Community Slack (either in a dev channel or via DM). Then, any development decisions, etc. arising from the Slack interaction should be documented in GitHub. Limit these conversations in Community Slack to development for a given project. 33 | 34 | ### Mailing Lists 35 | 36 | The Chef Community mailing lists are hosted via [Discourse](https://discourse.chef.io/). This is the best place to catch up on general and security-related announcements. 37 | 38 | ### Office Hours 39 | 40 | Individual projects may host office hours on a periodic basis. This is a great way to get some face time with other Project Members. Each project should record and archive sessions to a public location; see individual project documentation for more details. 41 | 42 | **Note:** Zoom is a good medium for office hours. More guidance on this will be coming in the near future. 43 | 44 | ## Providing Support 45 | 46 | Please see our [support boundaries](support-boundaries.md) doc regarding the types of support that are provided by maintainers and the types of support that are not. 47 | 48 | ## Get In Touch 49 | 50 | Engage like a pro. Below are some best practice uses of the Community communication channels. 51 | 52 | | As... | if I want to... | I'll... | Notes | 53 | | ---------------- | ----------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | 54 | | Anyone | become a ***Project Member*** | check out the [membership overview](../project-membership.md) | Individual project requirements may vary; see project doc for more info. | 55 | | Anyone | report a ***bug*** | create an issue in GitHub | See [sample bug template](https://raw.githubusercontent.com/chef/oss_project_boilerplate/master/.github/ISSUE_TEMPLATE/bug.md). Individual projects may have their own templates; see project documentation for details. | 56 | | Anyone | submit a ***feature request*** | create an issue in GitHub | See [sample feature request template](https://raw.githubusercontent.com/chef/oss_project_boilerplate/master/.github/ISSUE_TEMPLATE/feature-request.md). Individual projects may have their own templates; see project documentation for details. | 57 | | Anyone | report an ***outage*** | email [email address tbd] | --- | 58 | | Anyone | report a ***security vulnerability*** in a Chef OSS project | email [security@chef.io](mailto:security@chef.io) | Encryption? | 59 | | A Project Member | join a ***mailing list*** | head over to [Discourse](https://discourse.chef.io/) & sign up | See **unsubscribe** instructions [here](https://discourse.chef.io/t/update-on-notifications-from-discourse/7063). | 60 | | A Project Member | join a ***Community Slack*** channel | head over to [Community Slack](https://community-slack.chef.io/) | --- | 61 | | A Project Member | discuss ***technical issues*** | post in GitHub | For ***general, non-technical questions & issues*** head over to [Community Slack](https://community-slack.chef.io/). Use the project's general channel. | 62 | | A Project Member | get ***technical help*** | ask on GitHub | If the discussion requires a quick, non-durable, real-time sync, move it to the project's dev channel on [Community Slack](https://community-slack.chef.io/). | 63 | | A Project Member | find ***something to work on*** | check out GitHub | Get confirmation via a post in GitHub before expending too much effort to avoid duplicate PRs & PRs that won't be merged. | 64 | | A Project Member | check out the latest Chef **announcements** | head over to [Discourse](https://discourse.chef.io/) | --- | 65 | | A Project Member | regain ***access to your account*** | [tbd] | --- | 66 | | A Project Member | request a ***PR review*** | use GitHub | --- | 67 | | A Project Member | have a ***brief non-durable chat*** | [Community Slack](https://community-slack.chef.io/) | For technical topics, use the project's dev channel. Non-technical topics belong in the general channel. | 68 | | A Project Member | become a ***Reviewer*** | checkout an overview of Reviewer [responsibilities](../project-membership.md#reviewer) & [requirements](../project-membership.md#requirements) | Individual project requirements may vary; see project doc for more info. | 69 | | A Project Member | report a ***CoC violation*** | email [tbd] | --- | 70 | | A Project Member | talk to a ***human*** | request access to Zoom office hours in [Community Slack](https://community-slack.chef.io/). | --- | 71 | | A Reviewer | become an ***Approver*** | check out an overview of Approver [responsibilities & requirements](../project-membership.md#approver) | Individual project requirements may vary; see project doc for more info. | 72 | | An Approver | ***vote*** on a new Project Member, Reviewer, or Approver | review the general [requirements](../project-membership.md) and consult my project's documentation | General Approver information is [here](../project-membership.md#approver). Individual project requirements may vary; please see project doc for more info. | 73 | -------------------------------------------------------------------------------- /communication/communication-faq.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Communication FAQs 5 | 6 | ## Why can't all development discussion be in private Chef Slack? 7 | 8 | When working in open source, it's essential to be as transparent about technical decisions as possible with external contributors - particularly as we work with them on our projects, etc. If we were to only do development discussion in Chef internal slack (and not document decisions, etc. somewhere that external contributors can access them), we would seriously hinder any contributions from the community outside of Chef. The beauty of Open Source is with so many eyes on the code, the design, etc., it results in better products and a higher impact on the world. This greater potential carries its own challenges. The practices defined in this repository are to help us navigate those challenges and achieve our goals. 9 | 10 | **Note**: There are things that will need to stay private - including when work we are doing is for specific customers or for business strategy reasons that have not been made public. This will be addressed in a separate issue 11 | 12 | ## Why can't all development discussion be in public Community Slack? 13 | 14 | The main reason is that we use the free version of Slack, which limits records of conversations to 10,000 messages. Crucial information can be lost. If someone is away for a day or two and then comes back, they will not be able to catch up on conversations, messages, etc. 15 | 16 | ### Why don't we just pay for Community Slack? 17 | 18 | The lowest price Slack will charge a for-profit organization is $5 per active user. (Chef IT has talked extensively with Slack on this.) As anyone can join Community Slack (and we want to keep it that way), it would be an uncontrolled cost, which is a non-starter for Chef as a business. 19 | 20 | ### Why don't we just use a bot to export the chats from the Community Slack to some other archive? 21 | 22 | This is a possibility for specific channels in Slack, but channel chat is not the only place the 10,000 message limit applies. It also applies to DMs. If someone DMs someone else and they are on vacation, or otherwise not able to access Slack for a bit, then that DM will be unreadable once the entire Slack goes over the 10,000 message limit. With a fairly active Slack, the 10,000 message limit is reached fairly rapidly. There is nothing more frustrating than to see that you received a DM - potentially a very high value one! - and not be able to access the content. Additionally, it is common for critical information to be exchanged in DMs. Unless whoever is sending/receiving the DMs is very diligent about documenting them elsewhere (and if they see the DM before the 10,000 message limit is hit), that information will be lost. 23 | 24 | ## Why don't we just go back to IRC? 25 | 26 | There were two major reasons we moved from IRC to Slack in the first place. 27 | 28 | - IRC is blocked completely on many corporate networks - this comes directly from Chef's Customer Facing teams, and is a matter of codified security policy in Federal and Financial organizations. Slack has managed to achieve enough usage in the corporate world with corresponding security approvals that it is usually allowed. 29 | - IRC isn't as user-friendly as other options - we want our community to be as accessible and inclusive as possible. 30 | 31 | ## Why don't we use Discord/Gitter/some other chat tool instead? 32 | 33 | Discord also is blocked on many corporate networks. 34 | 35 | Gitter has been considered as a possibility, but dividing development conversations between two real time chat tools quickly leads to loss of context and "Slack overload". 36 | 37 | This does bring us to the larger question: should our development conversations be happening in a synchronous matter at all, where replies are often expected to be immediate? 38 | 39 | ## Why don't we use a self hosted solution like MatterMost? 40 | 41 | [MatterMost](https://mattermost.com/download/) is certainly intriguing, especially as it offers an Open Source, self hosted version, but we do not have the resources to dedicate to supporting and maintaining a self hosted version of MatterMost at this time. 42 | 43 | ## Why wouldn't we use a synchronous chat tool? 44 | 45 | There are a few clear issues with synchronous chat tools, which have the tendency to alienate parts of our community. 46 | 47 | - Synchronous chat works best when all participants are within close time zones. We have contributors in Europe, Asia, and Australia (at least) and it's very easy for them to lose the development conversation when it is held in a synchronous matter. They often do not have a chance to interact with us, or before decisions are made. 48 | - Synchronous chat is difficult for non-native English speakers. Due to the high volume and speed of synchronous chat, it can be easy for non-native English speakers to quickly lose the context. When there is a language barrier, it's much easier to hold conversations in an async matter when translation tools can be used and there is just more time for comprehension to happen. 49 | - Synchronous chat is also difficult for those who do not have the time or resource to keep up. Some people prefer to think more slowly and carefully. The pace of conversation in a synchronous context is often set by the quickest thinking, quickest typing users. We value deliberation and thoughtfulness. 50 | - Non-majority contributors (women, Non-binary folks, etc.) face unique challenges when interacting on the web, especially about technology. People who don't know them personally have a tendency to assume them incompetent until proven otherwise - which significantly hinders their ability to drive conversation around technical topics. Chef has, in fact, observed distinct and clear examples of this problem happening within our own community. Async communication forces more thought into the responses and relieves the pressure of being questioned constantly while trying to formulate a response. The less-personal nature of async communication encourages a focus on the the germane technical content posted versus the author, allowing better freedom of expression and articulation of ideas. 51 | 52 | ## So when would we use a synchronous chat tool? 53 | 54 | Synchronous chat is immensely useful for short, ephemeral real-time interactions - e.g. assisting a contributor with setting up their development environment (the quicker someone can contribute, the more likely they are to stay engaged) or having short conversations that either don't need to be recorded or are logged elsewhere. It should not be used as a system of record of development decisions, etc. 55 | 56 | ## What are our options for async communication with contributors? 57 | 58 | - GitHub - this should be used wherever possible as the system of record - not only for the code, but for decisions related to the code. Internal and external contributors are already in GitHub. This way, contributors don't have to split their attention between too many tools. 59 | - Discourse - this is another possibility. We have one for both the Chef community and for the Habitat community. (We may want to consider combining them in the future.) 60 | -------------------------------------------------------------------------------- /communication/community-meetings.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Community Meetings 5 | 6 | Community Meetings are held in text form in the #community-meetings channel of the Chef Community Slack every Thursday at 9 AM Pacific. 7 | 8 | Meetings are scheduled for 45 minutes. 9 | 10 | ## Requirements 11 | 12 | - Meetings are open to anyone who is interested. 13 | - Each meeting is lead by a member of the Developer Relations team in the Chef business unit at Progress. 14 | - Each meeting will follow a general structure of release notifications, team updates, and community updates. 15 | - The meeting leader will start the meeting with a greeting and any Chef announcements (ChefConf, Community Summits, etc.). 16 | - Each meeting must have at least one representative from Chef's major Open Source projects - including Infra, Habitat, InSpec, and Automate. 17 | - Each representative will give a brief update on the project - what is being worked on, issues that they would like to solicit input on, etc. 18 | - The meeting will then open for general discussion. 19 | - As an agenda item nears its time limit, the moderator will give a 2 minute warning, then close the topic. 20 | - All Chef engineers - engineers working on Chef software employed by Progress Software - are highly encouraged to attend. 21 | -------------------------------------------------------------------------------- /communication/decider.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Role of Decider 5 | 6 | Chef's previous "decider" for all Chef Open Source projects was Adam Jacob. This worked extremely well when Chef had a single major open source project. With the expansion of Chef's Open Source footprint, having one person in charge of decisions for all projects is no longer sustainable or desirable. Due to this, the role has been eliminated. 7 | 8 | Decisions about the direction of Chef Open Source projects (including but not limited to Infra, InSpec, Habitat, and Automate) are now at the discretion of the individual project owner(s) and the product manager(s) assigned to those projects. We welcome input from all and encourage community members to express opinions on the directions of projects through GitHub or the Chef Discourse forums. We will gladly consider any input and feedback that is offered, but reserve the right to decide whether and how to act on that feedback. 9 | -------------------------------------------------------------------------------- /communication/project-eol.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # The End of a Project's Life 5 | 6 | As covered in our [governance documentation](../governance.md), there can come a time in the life of a software project where it needs to be figuratively put out to pasture. This document focuses on what communication looks like for a project entering that End of Life (EoL) status, rather than the process of EoLing a project. 7 | 8 | ## Repo Content 9 | 10 | It is possible that Chef Software Inc. might decide to EoL a project when: 11 | 12 | - A project lays dormant for a long enough period of time, 13 | - A project has entered into maintenance mode and remained there for a long period of time, or 14 | - A project has no active maintainers, no active development, no known users and is not a project that is depended upon by software we ship to our users/community/customers 15 | 16 | When that happens and the repo(s) have been transferred to the Chef-Boneyard GitHub Org, we should update the readme with some words about the project's status and our expectations of that codebase in the future. 17 | 18 | It is preferred that we use the following default statement: 19 | 20 | ```text 21 | This project has officially been EoL'd by Chef Software Inc. but, have no fear! While we are no longer actively maintaining this codebase and have archived the repository, we have no intention of permanently deleting this code at any point. All repositories under the Chef-Boneyard Organization are fully available to be forked. Thus, should you want to have a new feature, bug-fix, or code change merged to this codebase, we suggest forking the repository and operating it from within your own org. If you have any further concerns, please send an email over to community@chef.io! 22 | ``` 23 | 24 | ## Discourse Announcement 25 | 26 | If you believe the project transitioning to EOL status may have active users, a post should be made to the [Chef Discourse](https://discourse.chef.io) announcing the EOL of the project. 27 | 28 | ## Archival and Boneyarding 29 | 30 | After a period of time -- the length of which will be determined by the project owners -- the repository should be transferred to the `chef-boneyard` GitHub organization and archived. When a repository is in the boneyard, it is still available for anyone to reference, clone, or fork. 31 | 32 | The time it takes before a repository is archived and transferred to the chef-boneyard can be highly variable. For example, if a repository is a library that project owners are confident is only used internally by Chef, they may choose to archive and move the repository immediately. Alternately, if there needs to be a transfer of ownership of the repository and management responsibilities, it may take several months before the repository is ready to be archived and transferred. 33 | -------------------------------------------------------------------------------- /communication/saying-no.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Saying No 5 | 6 | One of the hardest challenges of Open Source development is saying no either on an issue or a pull request in an empathetic way. Sometimes an issue is something that cannot or will not be worked on for a variety of reasons - including timing, product roadmap, and more. Sometimes a pull request is just not right for the project at that specific time - again including timing, product roadmap, and more. When issues or pull requests have remained open for years, it's also sometimes necessary to declare bankruptcy on issues that have been open > a certain number of years and close them. 7 | 8 | Regardless of why something must be closed, it is crucial to always, always, always say thank you and always, always, always say why. It is an awful experience for a contributor or any community member to see an issue or pull request closed without some indication of why (leaving an issue or pull request hanging open without a response is also an awful experience). This leads to community negativity and disengagement. It is crucial to acknowledge that someone took effort to submit an issue or (especially) submit a pull request and, even if we cannot act on it, we value it and encourage them to continue contributing to our projects and interacting with our community. 9 | 10 | ## Templates 11 | 12 | Knowing how to say no can be a challenge, here are some templates that you can feel free to use as is or modify however you see fit. 13 | 14 | ### Issues 15 | 16 | #### Needs more information 17 | 18 | Sometimes when we request more information so we can diagnose an issue, the community member will not respond due to a variety of factors. If they do not respond within a reasonable amount of time (what "a reasonable amount of time" means is up to each team), it may be necessary to close the issue until they are able to respond. 19 | 20 | ```text 21 | Thank you for filing this issue! 22 | 23 | We do still need more information in order to diagnose on it and work on a fix. 24 | We requested this, but haven't seen a response yet, so we are closing the issue for now. 25 | Please feel free to re-open it with more information and we will take a look then! 26 | ``` 27 | 28 | #### Not on Roadmap 29 | 30 | Sometimes an issue will request some sort of enhancement, alteration, or fix that is not on the roadmap. If an issue is not likely to be worked on in the next year, it's often best to either label it with "Help Wanted" or close it. 31 | 32 | ```text 33 | Thank you for taking time time to file this issue. 34 | 35 | Unfortunately, this is not something we can address at this time due to 36 | <>. 37 | If this is something you would like to contribute, however, 38 | please feel free to open a pull request! 39 | ``` 40 | 41 | #### Issue has gotten too old or concerns older versions of the software 42 | 43 | The InSpec team uses this template for old, legacy issues that are > 1 year old and/or involve earlier versions of InSpec. 44 | 45 | ```tex 46 | __What’s happening? Why was this issue closed?__ 47 | This issue was closed due to some much needed review of legacy issues or issues that were spawned in older versions of InSpec, i.e. < v3. 48 | __Why do I care?__ 49 | You would care about this if this was an issue that you are still seeing and/or feel needs to be addressed in the current version of InSpec. 50 | __What do I need to do?__ 51 | If this issue is no longer important, no further action is necessary. However, if you think this is something that should be addressed, please open a new issue and refer to the original issue in the description. 52 | ``` 53 | 54 | #### Issue is not something we will ever do 55 | 56 | ```text 57 | Thank you for taking the time to file this issue. 58 | 59 | We understand and appreciate your reason for this request. However, at this time, it does not align with our core direction and is not something we’re looking at doing. 60 | 61 | Thank you again for filing this, however, we greatly appreciate your interest in this project! 62 | ``` 63 | 64 | #### Issue is an interesting idea, but we do not have the resources right now 65 | 66 | ```text 67 | Thank you for taking the time to file this issue. 68 | 69 | We understand your request and the reasoning behind it. Unfortunately, we don’t have any resources at this time to look into this further. 70 | 71 | Thank you again for filing this, however, we greatly appreciate your interest in this project! 72 | ``` 73 | 74 | #### Issue is an interesting idea, would you like to contribute? 75 | 76 | ```text 77 | Thanks for providing your input. Your idea sounds interesting to us but we currently do not have the resources to investigate further. We would, however, welcome a contribution implementing this idea. Are you interested in contributing this? 78 | ``` 79 | 80 | ### Pull Requests 81 | 82 | #### Contributor has not responded to review 83 | 84 | Like GitHub issues, occasionally when we review pull requests and request changes to them, the contributor will not respond in a reasonable amount of time (again, there are plenty of reasons why this may happen). When changes have been requested but not made, it's often best to close the pull request until those changes can be made. 85 | 86 | ```text 87 | Thank you for submitting this pull request! 88 | 89 | We've requested some changes to this pull request on code review 90 | and cannot re-review it until we receive a response. We haven't received 91 | a response yet - though we understand there are many reasons for this, 92 | especially if you are contributing on your own time - and cannot move 93 | forward until we do, so we are closing this pull request for now. 94 | 95 | Should you be able to respond to the changes that have been requested 96 | in the future, please feel free to re-open it and we will review it then. 97 | ``` 98 | 99 | #### Pull Request is not right for the project at this time 100 | 101 | Sometimes a pull request will take a project in a direction that the owners do not wish it to, or add something to the project before the project is ready to take on the responsibility of maintaining it. These are some of the most difficult cases to deal with, but again it's crucial to acknowledge the effort that went into the pull request when saying no - it's also crucial to show empathy and respect not just for the person who opened the pull request but also for the person's work. 102 | 103 | ```text 104 | Thank you for submitting this pull request! 105 | 106 | While we acknowledge and value the effort and interest you have shown 107 | by filing this pull request, this is unfortunately not something we can 108 | merge due to <>. Therefore, we are closing it, but 109 | again thank you for taking this interest and putting in this effort and 110 | would welcome future contributions from you. 111 | ``` 112 | 113 | ## Locking Issues 114 | 115 | [Locking a GitHub issue or pull request](https://help.github.com/en/articles/locking-conversations) means that no one other than people with write access, repository owners, and repository collaborators will be able to add, hide, and delete comments. There are a few places where this can be appropriate. 116 | 117 | ### Heated Conversations 118 | 119 | This may be done when conversation on an issue or pull request becomes unproductive or devolves into trolling. In this case, it is up to the Project Owners and Approvers to lock the issue or pull request. There does not need to be consensus to act - if the conversation is turning toxic it is far better to lock the issue early than to wait. Conversations can be unlocked when appropriate or necessary. 120 | 121 | ### Older Issues/Pull Requests 122 | 123 | Some Chef Open Source projects may choose to lock conversation on issues or pull requests that are beyond a certain age (for example, one year). Whether or not to do this is up to the Project Owners. If someone wishes to re-open conversation around an old issue or pull request that has been locked, they should create a new one and link to the old issue or pull request. This ensures that issues/pull requests - even when they resurface after a long time - are all written within current context. This also avoids massive merge conflicts in the case of aged pull requests. 124 | -------------------------------------------------------------------------------- /communication/support-boundaries.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Support Boundaries 5 | 6 | ## What Technical Support are Contributors Expected To Do? 7 | 8 | Contributors are expected to provide support around the **development** of a project. Contributors are not expected to provide support for **use** of the product produced by that project. 9 | 10 | ### Supporting Development of a Project 11 | 12 | Requests for development support include questions such as: 13 | 14 | - Why did you choose this Rust crate over this other one? 15 | - Can I get some help understanding what this particular section of code does? 16 | - If I were looking for this functionality in the code, where would I start? 17 | 18 | These questions may come in through GitHub, the Community Slack, and other places. Responding to these questions is the duty of the project members, especially Chef employees who are project members. 19 | 20 | ### Supporting the Use of a Product 21 | 22 | Request for use of a product support include questions such as: 23 | 24 | - How do I use Habitat? 25 | - Why isn't my Chef Infra Cookbook working? 26 | - How would I do this with Chef InSpec? 27 | 28 | Commercial customers (with Support contracts) should expect to receive help directly from Chef Software via Support, Customer Architects, etc. The paid Support channel is the only way to receive “official” Chef support from Chef employees on using Chef products. We will provide channels for - and encourage! - external Community members to assist each other. However, there is no expectation of support from Chef on using Chef products without a valid commercial licenses. 29 | 30 | If someone requests help for the use of a Product from a Chef Engineer, here is a suggested response. 31 | 32 | Thank you for your interest in Chef! 33 | 34 | While Chef engineers do provide support with the development of our products, we do not provide direct support for the usage of our products. There are two avenues to get support with using our products - one is through the commercial support channel (which does require a commercial relationship with Chef) at , the other is from other community members through the Community Slack at or the Discourse Forums at . We encourage you to check out one of these resources for support with using Chef products. 35 | -------------------------------------------------------------------------------- /communication/triage.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Public Triage 5 | 6 | The long-running OSS projects at Chef have found that hosting a public triage call on a set cadence positively increases the activity level of a project. It's an opportunity for internal project members to have virtual face time with the larger community, as well as an opportunity for external project members to stay aware on what's happening on the team. All Chef Inc. top-level OSS projects going forward are required to adopt a public triage process. The cadence can follow whatever frequency the team sees as reasonable. Our recommendation is weekly, or bi-weekly. 7 | 8 | ## Process 9 | 10 | The triage process is focused on identifying and categorizing issues and pull requests for a project. Chef utilizes GitHub labels to track the status of issues and PRs, and maintains a list of [recommended GitHub labels](../repo-management/github-labels.md) that greatly improve the triaging process. GitHub Issue and PR templates should be setup to apply the 'Status: Untriaged' label to all new issues and PRs. During triage, this label is removed and replaced with more descriptive labels. This allows us to track the untriaged, as well as triaged, work at a GitHub organization level. 11 | 12 | ### Suggested Process 13 | 14 | Following this process is not required, but it is suggested here as a place to start. 15 | 16 | - **1 hr prior to call** - Announce that triage will happen soon in the Chef Community Slack or Habitat Slack (choose whichever Slack and whichever channel is most appropriate). Mention that if anyone wants to join, please DM the person posting the announcement for the Zoom link (_do not share the zoom link publicly, especially on social media_). 17 | - **At time for call** - start Zoom call. Invite any community members who requested to be a part of it using the Zoom url. _Make sure to start recording the call - recording to the cloud usually works better than recording to your workstation_.Conduct triage as outlined above. 18 | - **After the call** - when the recording finishes processing, send a link to Garth Avery in Marketing through the Chef internal Slack. His staff will add intro and outro bumpers, then post the video the [Triage Playlist](https://www.youtube.com/playlist?list=PL11cZfNdwNyMMffxAIvH3bfTVv6W65oIh). 19 | 20 | ### Tools 21 | 22 | Each team should feel free to use whatever tools they want so long as they can meet the following requirements: 23 | 24 | - The call should be held live in a manner that allows external project members and contributors to join or provide context to issues they've submitted _while_ the call is occurring. 25 | - The call should be recorded each time the call occurs. 26 | - Following the end of the call, the recording must be published to a public location. 27 | 28 | ### Representation 29 | 30 | Some projects at Chef are larger than others. Some projects have a few repositories attached to them, others have tens or hundreds of repositories. Depending on how each project decides to roll out their public triage, this may have an effect on the number of project or sub-project repos that are covered by a single triage. For example in Habitat, we have a single triage call for core-plans, habitat cli, habitat supervisor, builder, on-prem depot, hab k8s modules, hab studio, etc. This is a significant number of repositories and a significant number of projects and sub-projects. Because of the decision to operate this way, we have a responsibility to have appropriate project representation on each call. What this means is - if your public triage call cross-cuts an organization, a representative from each team/vertical/project/sub-project within that organization **must be present on the call** and one person will likely need to act as a meeting host. 31 | 32 | ## Prioritization 33 | 34 | When issues are triaged and added to the backlog, then they must be prioritized. Factors in an issue's assigned priority include current workload, business strategy, customer impact, etc. 35 | 36 | Because customer impact and business strategy may be confidential, prioritizing issues on Chef projects may be done in private by both the Product manager and Engineering manager associated with the project. 37 | 38 | ### Sifting and Sorting 39 | 40 | The actual activity of triage is relatively simple. The host of the call will walk the group through inbound issues. Generally, we recommend fully labeling (within reason) each accepted issue and adding them to the backlog. There are 3 primary statuses an inbound issue can take: 41 | 42 | - _Accepted_ issues are issues that we validate as being work project team wants to undertake. Typically these are a mix of bug fixes, enhancements, and chores that require a healthy level of context to the project. Accepted issues are typically issues assigned to people in project roles. These issues are added to the backlog. 43 | - _Rejected_ issues are issues that the project team has determined as being either not useful, not in line with project goals, or something that if implemented it would be far out in the project's future due to impact. These issues are closed. 44 | - _Help Wanted_ issues are bits of work that the project team agree would be useful and within the scope of the project however that aren't likely to get prioritized on the immediate. Help Wanted issues are added to the backlog and labeled as help-wanted. 45 | 46 | If an issue is rejected, a project member should leave a comment on the issue explaining why it was closed, then close the issue. Additionally, if project members are using the "will-not-fix" label on issues in that repository, they should make sure to attach that label to the issue before closing it. 47 | 48 | **Some important notes on this process:** 49 | 50 | Features and bugs can move between being help-wanted and prioritized by the responsible team. As any project evolves, things will definitely be re-prioritized, which means potentially having items shift between buckets. 51 | 52 | The “Help Wanted” issue classification is to encourage community development. If you have bugs or features you want to see in an upcoming release, we would love to have you contribute PRs for those things! 53 | -------------------------------------------------------------------------------- /communication/video-conferencing.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Video Conferencing 5 | 6 | Video conferencing is a fantastic tool for collaborating in realtime and sparking organic conversations that often don't emerge in a chat environment. This document outlines when video conferencing is appropriate and when a more durable medium should be used instead. 7 | 8 | ## Ideal Video Conferencing Uses 9 | 10 | - Community meet and greet meetings 11 | - Office hours 12 | - Brainstorming activities 13 | 14 | ## Video Conferencing Downsides 15 | 16 | - Difficult for non-native English speakers 17 | - Difficult to quickly catch up on after the fact 18 | - Attendance is difficult for those not in common timezones (e.g. Pacific Time (PT) versus Marquesas Time (MART)) 19 | 20 | ## Video Conferencing Best Practices 21 | 22 | - The organizer needs to act as the moderator to make sure all voices are heard. It is often particularly difficult to speak up in a large video conference where there are few / no pauses in the discussion. Consider letting participants know they can raise their hand if they want to queue up to speak. 23 | - If the discussion has a particular outcome, this should be summarized and documented elsewhere. Meeting notes can be committed to GitHub repos or posted to mailing lists if appropriate. 24 | - Video should be recorded and posted in a place where community members can both view and easily find it. 25 | -------------------------------------------------------------------------------- /contributors/contributor-entitlement-program.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Contributor Entitlement Program 5 | 6 | Continuing our commitment to work in partnership with the Chef Community, Chef offers a Contributor Entitlement program. At Chef, we recognize and value our community's involvement and we are dedicated to enabling our contributors to use the very software they are helping to build. 7 | 8 | Chef considers any of the following contributions to be qualifying to apply to the Contributor Entitlement program: 9 | 10 | ```text 11 | Publish and maintain at least 5 distinct content items 12 | This could include Habitat Core Plans, InSpec Profiles, or Chef Community Cookbooks 13 | Submit, and have approved and merged, at least 5 PRs or Patches for the core Chef projects per year 14 | We consider the core projects to be Chef Infra, Chef InSpec, Chef Habitat, and Chef Automate 15 | Contribute and publish at least 10 meaningful contributions to official Chef documentation per year 16 | ``` 17 | 18 | Each qualifying account will be granted the equivalent of $15,000 USD of license entitlement (subject to review of your commercial relationship with Chef, should one exist). This gives our contributors the flexibility of deciding how best to apply the credit as it works for their business. So feel free to use it on any combination of Chef products; we ask only that it be declared as part of the contract. We also require that entitlements be claimed within 12 months of the most recent qualifying contribution and be renewed annually. Thus, even though the entitlement expires annually, any ongoing contributions would qualify contributors to renew their contributor entitlement. 19 | 20 | To apply for the program, simply fill out the requested information here: . 21 | -------------------------------------------------------------------------------- /contributors/distribution-guidelines.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | See the [guidelines for distribution](../distributions/distribution-guidelines.md) in its new location. -------------------------------------------------------------------------------- /contributors/guide/README.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Chef Software Inc. Contributor Guide 5 | 6 | This document is a guide on how to contribute to and maintain Chef Software Inc. projects. 7 | Feel free to browse the [open issues](https://github.com/chef/chef-oss-practices/issues?q=is%3Aissue+is%3Aopen) and file new ones, all feedback welcome! 8 | 9 | Contributing to any of Chef's projects should be easy. If you find a rough edge, let us know! Better yet, join the community and help us fix it. 10 | 11 | ## Welcome 12 | 13 | Welcome to the Chef Software Inc. OSS Community! 14 | 15 | - [Chef Software Inc. Contributor Guide](#chef-software-inc-contributor-guide) 16 | - [Welcome](#welcome) 17 | - [Before You Get Started](#before-you-get-started) 18 | - [Code of Conduct](#code-of-conduct) 19 | - [Community Expectations and Roles](#community-expectations-and-roles) 20 | - [Your First Contribution](#your-first-contribution) 21 | - [Find Something To Work On](#find-something-to-work-on) 22 | - [Find a Good First Issue](#find-a-good-first-issue) 23 | - [Contributing Without Coding](#contributing-without-coding) 24 | - [Documentation](#documentation) 25 | - [File or Triage Issues](#file-or-triage-issues) 26 | - [Learn About the Project's Team](#learn-about-the-projects-team) 27 | - [Team Structure](#team-structure) 28 | - [Find the Project's Team](#find-the-projects-team) 29 | - [Claiming Your Issue](#claiming-your-issue) 30 | - [Contributing](#contributing) 31 | - [Signing the DCO](#signing-the-dco) 32 | - [Communication](#communication) 33 | - [Open a Pull Request](#open-a-pull-request) 34 | - [Code Review](#code-review) 35 | - [Testing](#testing) 36 | - [Security](#security) 37 | - [Issues Management or Triage](#issues-management-or-triage) 38 | - [Community](#community) 39 | - [Community Communication](#community-communication) 40 | - [Events](#events) 41 | - [Mentorship](#mentorship) 42 | - [More Ways to Contribute](#more-ways-to-contribute) 43 | 44 | ## Before You Get Started 45 | 46 | ## Code of Conduct 47 | 48 | Please make sure to read and observe our [Code of Conduct](https://community.chef.io/code-of-conduct/)). 49 | 50 | ## Community Expectations and Roles 51 | 52 | All Chef Software, Inc. OSS projects are operated as community projects. Consequently, it is wholly dependent on its community to provide a productive, friendly, and collaborative environment for all contributors. 53 | 54 | - Read and review the [Community Expectations](community-expectations.md) for an understanding of code and review expectations. 55 | - See [Project Membership](../project-membership.md) for information on project roles and responsibilities. 56 | 57 | Please be aware that due to the large number of issues, repos, and projects our teams administer, we do not offer technical support in GitHub issues or on Slack. 58 | 59 | ## Your First Contribution 60 | 61 | We're glad you're interested in contributing to a Chef project! We're here to do everything we can to make your first contribution experience a great one. 62 | 63 | We hope this guide will help you to choose where to contribute, and show you the ropes of crafting your first contribution. If you have questions about the development process, or are feeling stuck with your first contribution, feel free to jump into specific project's public development Slack channel, or join a project-specific mailing list. The specific channels and mailing list URLs can be found in the CONTRIBUTING.md file found in each project repository. 64 | 65 | ### Find Something To Work On 66 | 67 | Help is always welcome! For example, documentation -- like the text you are reading now -- can always use improvement. There's always a need for more test coverage. There are surely un-prioritized features, which could use your work. Commenting on an issue that a bug or error is reproducible and including the environment and steps to reproduce will help with issue triage. Blog posts and example projects don't hack themselves! You get the idea - if you ever see something you think should be fixed, you should own it. 68 | 69 | #### Find a Good First Issue 70 | 71 | Chef Software maintains over 500 software repositories in multiple GitHub organizations such as [chef](https://github.com/chef), [inspec](https://github.com/inspec), and [habitat-sh](https://github.com/habitat-sh). Each repository has beginner-friendly issues that have been labeled to help new contributors. 72 | 73 | Chef uses labels to tag issues we believe are ideal for first time contributors as well as those ideal for outside contributors. See [Help Wanted](help-wanted.md) documentation for more information on how those tags are used and where you can see complete lists of tagged issues. 74 | 75 | #### Contributing Without Coding 76 | 77 | Not ready to contribute code, but still interested in helping? There are many non-coding ways to contribute to the community. 78 | 79 | ##### Documentation 80 | 81 | Documentation is critical to the success of any project and can always use expansion and improvement. Many Chef projects include documentation directly in their repository, and we also maintain the code for [docs.chef.io](https://docs.chef.io) in our [chef-web-docs](https://github.com/chef/chef-web-docs) repository. Documentation contributions are an excellent exposure to the code submission/review process without the added complication of technical depth. Please see [Contributing](#contributing) below for the workflow. 82 | 83 | ##### File or Triage Issues 84 | 85 | Both filing issues and triaging existing issues are incredibly helpful to maintain high quality software. Finding new issues in projects and filing detailed issues help the maintainers to provide the best possible experience to users. Be sure to adhere to the prompted submission guidelines when opening an issue to give the maintainers all the information necessary to resolve your issue. 86 | 87 | Even more useful than filing new issues is confirming existing issues. Providing reproduction cases or more detailed information to existing issues smooths [the triage process](../../communication/triage.md) and ensures issues can be more easily resolved by developers. 88 | 89 | ### Learn About the Project's Team 90 | 91 | Once you've found your first project and an issue, it's important to learn about the team responsible for that project. 92 | 93 | #### Team Structure 94 | 95 | We organize our community into teams in order to improve our workflow and more easily manage what amounts to multiple very large community projects. The developers within each team have autonomy and ownership over that team's project(s) and frequently a team will be working on more than one project at once. 96 | 97 | All projects at Chef are operated as open, community efforts supported with internal development teams. Anyone is welcome to jump into a project or engage with a specific team and begin filing/updating issues, writing/updating documentation, fixing issues, participating in design discussions, or reviewing code. Each team should have a public Slack channel for development discussions though any team is welcome to share a public development channel with any other team. 98 | 99 | #### Find the Project's Team 100 | 101 | Finding the appropriate team for your contribution and asking your questions in the correct place can give your contribution higher visibility and a faster community response. We do our best to have a swift response time on any of our projects, but engaging a team directly on a contribution is a great way to get connected and have a more direct interaction around your contribution. 102 | 103 | The readme file in each project repository will contain information on the team responsible for the code. Some teams also have their own `CONTRIBUTING.md` files, which may contain extra information or guidelines in addition to these general ones. These are located in the team-specific community directories in _this repository_ and will be linked from any repository that team owns. For example, the contributor's guide for the Habitat supervisor is located in the *chef/chef-oss-practices* repo, as [`../../teams/hab-sup/CONTRIBUTING.md`](../teams/hab-sup/CONTRIBUTING.md), as well as in the root of _habitat-sh/habitat_ as `CONTRIBUTING.md`. 104 | 105 | ### Claiming Your Issue 106 | 107 | You've found the issue you want to work on and now you want to make sure that no one else beats you too it. Often, new contributors ask to be assigned an issue they are willing to take on. Unfortunately, due to GitHub limitations we can only assign issues to [org members](#community) or repo collaborators. Instead, leave a comment that you're going to start work on the issue and others will make sure to give you space. 108 | 109 | ## Contributing 110 | 111 | All Chef Software Inc. projects are open source, but many of the people working on it do so as their day job. In order to avoid forcing people to be "at work" effectively 24/7, we want to establish some semi-formal protocols around development. Hopefully, these rules make things go more smoothly. If you find that this is not the case, please open an Issue on this repository. 112 | 113 | As a potential contributor, your changes and ideas are welcome at any hour of the day or night, weekdays, weekends, and holidays. Please do not ever hesitate to ask a question or send a pull request. Don't assume that a contribution is 'too small' or 'not important' - all inputs are welcome, and will be discussed in a friendly and inclusive manner. 114 | 115 | Check out our [Collaborative Development Principles](collaborative-dev.md) on how to create great code as a big group. 116 | 117 | Beginner focused information can be found below in [Open a Pull Request](#open-a-pull-request) and [Code Review](#code-review). 118 | 119 | For quick reference on contributor resources, we have a handy [contributor cheatsheet](contributor-cheatsheet.md). 120 | 121 | ### Signing the DCO 122 | 123 | Chef requires that all commits to projects be signed for the DCO. See [Developer Certificate of Origin](../../DCO.md) for more information on why we use the DCO and how to sign a commit for the DCO. 124 | 125 | #### Communication 126 | 127 | It is best to contact a project's team for issues related to the projects operated by that team. Your team will be able to help you much more quickly than a general question would. 128 | 129 | For information on finding the team responsible for a project see [Find the Project's Team](#find-the-projects-team). 130 | 131 | For general questions and troubleshooting, see the [standard lines of communication](../../communication/README.md). 132 | 133 | ### Open a Pull Request 134 | 135 | Pull requests are often called simply "PR"s. Our community generally follows the standard [GitHub pull request](https://help.github.com/articles/about-pull-requests/) process, but there is a layer of additional project specific (and sometimes team specific) differences: 136 | 137 | - [Chef-specific GitHub workflow](pull-requests.md#the-testing-and-merge-workflow). 138 | 139 | Common new contributor PR conflicts are: 140 | 141 | - not having correctly signed the DCO on the commits of your first PR (see [Signing the DCO](#signing-the-dco) section) 142 | - finding the right team or reviewer(s) for the PR (see [Code Review](#code-review) section) and following any team or repository specific contributing guidelines (see [Team Structure](#team-struture) section) 143 | - dealing with test cases which fail on your PR, unrelated to the changes you introduce 144 | 145 | ### Code Review 146 | 147 | It is critical that all code changes to projects be reviewed to promote high quality work, foster development norms, and keep contributors and community members engaged and apprised of changes. 148 | 149 | Please read the [Code Review](collaborative-dev.md#code-reviews) section of the Collaborative Development Principles guide for further information on helping project members to better review your changes. 150 | 151 | ### Testing 152 | 153 | Testing is critical to preventing regressions and for the general maintenance of high quality software over time. All Chef projects require testing and that testing is the responsibility of all contributors. 154 | 155 | Refer to the [Testing section](collaborative-dev.md#testing) of the Collaborative Development Principles guide for further information. 156 | 157 | ### Security 158 | 159 | - [Security Release Page](https://github.com/chef/chef-oss-practices/communication/security-release-process.md) - outlines the procedures for the handling of security issues. 160 | - [Security and Disclosure Information](https://chef.io/security/) - check this page if you wish to report a security vulnerability. 161 | 162 | ### Issues Management or Triage 163 | 164 | Helping to manage or triage open issues can be a great contribution and a great opportunity to learn about the various areas of the project. Triaging is the word we use to describe the process of adding multiple types of descriptive labels to GitHub issues, in order to speed up routing issues to the right folks. 165 | Refer to the [issue triage guide](../communication/triage.md) for more information. 166 | 167 | ## Community 168 | 169 | If you haven't noticed by now, we have a large, lively, and friendly open-source community. 170 | We depend on new people becoming project members and regular code contributors, so we would like you to join us! 171 | 172 | The [Project Membership Document](../../project-membership.md) covers membership processes and roles. 173 | 174 | ### Community Communication 175 | 176 | - [General Information](../communication) on communication can be found here. 177 | 178 | ### Events 179 | 180 | Chef Inc. participates in an extremely diverse and distributed list of events every year across Asia, Europe and North America. Information about these and other community events is available on the Chef [events](https://events.chef.io/) pages. 181 | 182 | ### Mentorship 183 | 184 | Please learn about our mentoring initiatives [here](/mentoring/README.md). 185 | 186 | ### More Ways to Contribute 187 | 188 | Code is certainly not the only way to contribute, check out [this list of ways to contribute](ways-to-contribute.md) 189 | -------------------------------------------------------------------------------- /contributors/guide/collaborative-dev.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Collaborative Development Principles 5 | 6 | Collaboration is key to ensuring high quality code for any project. In order to promote a collaborative coding environment, Chef utilizes testing, code reviews, and pairing. 7 | 8 | ## Open Design Process 9 | 10 | For a software community to be engaged, they must have visibility and say in the process and direction of a project. 11 | 12 | In order to promote visibility into our projects, we have outlined communication standards that focus on durable mediums and public facing discussions (See [Communication](../../communication/README.md)). Except in the case of confidential customer or business strategy information, we aim to present our community with full insight into our day-to-day project development process. 13 | 14 | We also want our community to be able to participate in that process. To offer input beyond a feature request, each project implements a 'Design Proposal' process. Design Proposals allow community members to propose a change that _they_ plan to implement, and gives both the community and project maintainers the ability to discuss the potential change before a PR is opened. See the [Design Proposal](design-proposals.md) document for more details on this process. 15 | 16 | ## Code Reviews 17 | 18 | As a community, we believe in the value of code review for all contributions. Code review increases both the quality and readability of our codebase, which in turn produces high quality software. 19 | 20 | All contributions to a Chef project must be reviewed. This applies not only to submissions from outside authors, but also also to project members with reviewer / approver status. All changes should be reviewed by at least one project member familiar with the changing code. For significant changes, _two_ reviewers may be required at the discretion of a project approver. Except for trivial changes, PRs should not be merged until relevant parties have had a reasonable chance to look at PR in their local business hours. 21 | 22 | ### Who Performs a Review 23 | 24 | Most PRs will find reviewers/approvers organically. If a maintainer intends to be the primary approver of a PR, they should set themselves as the assignee on GitHub and say so in a reply to the PR. Only the primary approver of a change should actually do the merge, except in rare cases (e.g. they are unavailable in a reasonable timeframe). 25 | 26 | Project Approvers can delegate approvals to other project members when appropriate. The assignee becomes the shepherd for that PR and is responsible for merging the PR once they are satisfied with it, or else closing it. The assignee might request reviews from non-maintainers. 27 | 28 | Except for rare cases, such as trivial changes (e.g. typos, comments) or emergencies (e.g. broken builds), project members should not approve their own changes. 29 | 30 | ### Writing PRs for Review 31 | 32 | To make it easier for your PR to receive reviews, consider the reviewers will need you to: 33 | 34 | - follow the project coding conventions, which are typically defined by a [language specific guild](../../guilds/README.md) 35 | - write [good commit messages](https://chris.beams.io/posts/git-commit/) 36 | - break large changes into a logical series of smaller commits, which individually make easily understandable changes, and in aggregate, solve a broader issue 37 | - label PRs appropriately: check out our section on [GitHub labels](/repo-management/github-labels.md) 38 | 39 | ### Performing Quality Reviews 40 | 41 | Reviewers, the people giving the review, are highly encouraged to revisit the [Code of Conduct](../../CODE_OF_CONDUCT.md) and must go above and beyond to promote a collaborative, respectful community. 42 | When reviewing PRs from others, [The Gentle Art of Patch Review](http://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/) suggests an iterative series of focuses, which is designed to lead new contributors to positive collaboration without inundating them initially with nuances: 43 | 44 | - Is the idea behind the contribution sound? 45 | - Is the contribution architected correctly? 46 | - Is the contribution polished? 47 | 48 | ## Pairing 49 | 50 | Pair programming is an excellent way to not only increase the quality of code, but also to transfer knowledge from experienced developers to those new to a codebase. Chef encourages pair programming between its employees and with community members. 51 | 52 | ## Testing 53 | 54 | Each Chef-maintained project includes testing that helps ensure high software that can be released at any point in time. Testing is the responsibility of all project contributors with infrastructure assistance from Chef's Release Engineering team. 55 | 56 | ### Types of Testing 57 | 58 | - Unit: These tests confirm that a particular function behaves as intended. Various languages handle unit testing differently. It will be best to discuss with the team responsible for the project you're targeting on how best to write, run, and validate these before opening a PR. It is a requirement for Chef Software, Inc. projects to have unit tests that is easily run locally by any developer on any supported OS. 59 | - Integration: These tests cover interactions of package components or interactions between components and some other separate system resource (e.g. chef + Hashi Vault, or similar). An example would be testing whether a piece of code can correctly store data to or retrieve data from a Vault. Running these tests can require the developer set up additional functionality on their development system, but if integration tests are available, we highly recommend you running them before opening your PR. 60 | - End-to-end ("e2e"): These tests are broad tests of overall system behavior and coherence. These are more complicated as they could require multiple services or tools built from the sources to be tested. 61 | 62 | The location of the test code varies with type, as do the specifics of the environment needed to successfully run the test. Our continuous integration systems will run these tests either as pre-submits on PRs, post-submits against master/release branches, or both. 63 | -------------------------------------------------------------------------------- /contributors/guide/community-expectations.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Community Expectations 5 | 6 | All Chef Software Inc. code is open-source and operated as community projects. Consequently, it is wholly dependent on its community to provide a productive, friendly and collaborative environment. 7 | 8 | The first and foremost goal of the greater Chef community is to develop automation technologies that streamline the process of building, deploying, and managing software systems. The second and equally important goal is the creation of a community that fosters low-friction development of such tools. 9 | 10 | We therefore describe the expectations for members of the Chef Software Inc. community. This document is intended to be a living document that evolves as the community evolves via the same PR and code review process that shapes the rest of the projects. It currently covers the expectations of conduct that govern all members of the community as well as the expectations around code review that govern all active contributors to all Chef Software Inc. projects. 11 | 12 | ## Code Review 13 | 14 | As a community, we believe in the value of code review for all contributions. Code review increases both the quality and readability of our codebase, which in turn produces high quality software. 15 | 16 | Consequently, as a community, we expect that all active participants in the community will also be active reviewers. The [project membership](/project-membership.md) outlines the responsibilities of the different contributor roles. 17 | 18 | Expect reviewers to request that your PRs follow the specific project's style and testing requirements. 19 | 20 | For more information on the review process, see the [Code Reviews section](collaborative-dev.md#code-reviews) of the Collaborative Development Principles guide. 21 | 22 | ## Expectations of reviewers: Review comments 23 | 24 | Because reviewers are often the first point of contact between new members of the community and can significantly impact the first impression of the community, reviewers are especially important in shaping the Chef Software Inc. community. Reviewers are required to abide by the [Code of Conduct](/governance.md#code-of-conduct) and are strongly encouraged to go above and beyond the Code of Conduct to promote a collaborative, respectful community. 25 | 26 | ## Expectations of reviewers: Review latency 27 | 28 | Reviewers are expected to respond in a timely fashion to pull requests that are assigned to them. All pull requests should receive a response (though not necessarily be merged) within the Response Time Maximum (RTM) specified for that project. When a reviewer is assigned to an *active* PR, they are expected to respond as soon as possible. If reviewers fail to respond, those PRs may be assigned to other reviewers. 29 | 30 | A PR is considered active when all commits have a proper DCO signature and there are no merge conflicts. PRs are considered inactive when they do not have a proper DCO or have merge conflicts that require a rebase. PRs are also considered inactive when they have the WIP label or title prefix. 31 | 32 | **Note:** PRs being held with an `Incomplete` label are not considered active until the contributor responds to the Reviewer or Approver feedback. 33 | 34 | ## Thanks 35 | 36 | Many thanks in advance to everyone who contributes their time and effort to making the Chef OSS community successful. Our software's success and strength come entirely from your efforts. 37 | -------------------------------------------------------------------------------- /contributors/guide/contributor-cheatsheet.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Chef OSS Contribution Cheat Sheet 5 | 6 | A list of common resources when contributing to Chef Software Inc. Projects. 7 | 8 | | Repo | PRs | Issues | Notes | 9 | | ---- | --- | ------ | ----- | 10 | | [Chef](https://github.com/chef/chef) | [PRs](https://github.com/chef/chef/pulls) | [Issues](https://github.com/chef/chef/issues) | [Meeting Notes](https://github.com/chef/chef-community-slack-meetings) 11 | | [Habitat](https://github.com/habitat-sh/habitat) | [PRs](https://github.com/habitat-sh/habitat/pulls) | [Issues](https://github.com/habitat-sh/habitat/issues) 12 | | [InSpec](https://github.com/inspec/inspec) | [PRs](https://github.com/inspec/inspec/pulls) | [Issues](https://github.com/inspec/inspec/pulls) 13 | | [Community](https://github.com/chef/chef-oss-practices) | [PRs](https://github.com/chef/chef-oss-practices/pulls) | [Issues](https://github.com/chef/chef-oss-practices/issues) | 14 | | [Chef Docs](https://github.com/chef/chef-web-docs) | [PRs](https://github.com/chef/chef-web-docs/pulls) | [Issues](https://github.com/chef/chef-web-docs/issues) 15 | | [Habitat Docs](https://github.com/habitat-sh/habitat/tree/master/www/source/docs) | [PRs](https://github.com/habitat-sh/habitat/pulls?q=is%3Aopen+is%3Apr+label%3AA-documentation) | [Issues](https://github.com/habitat-sh/habitat/labels/A-documentation) 16 | | [InSpec Docs](https://github.com/inspec/inspec/tree/master/docs) | [PRs](https://github.com/inspec/inspec/issues?utf8=%E2%9C%93&q=ir%3Apr+is%3Aopen+label%3A%22Aspect%3A+Docs%22+) | [Issues](https://github.com/inspec/inspec/labels/Aspect%3A%20Docs) 17 | 18 | ## Getting Started 19 | 20 | - [Code of Conduct](https://github.com/chef/chef-oss-practices/blob/master/CODE_OF_CONDUCT.md) 21 | - [Contributor Guide](https://github.com/chef/chef-oss-practices/blob/master/contributors/guide/README.md) 22 | - [Repository Management](https://github.com/chef/chef-oss-practices/tree/master/repo-management) 23 | 24 | ## Workflow 25 | 26 | - [GitHub labels](https://github.com/chef/chef-oss-practices/blob/master/repo-management/github-labels.md) 27 | - [Chef Releases](https://discourse.chef.io/c/chef-release) 28 | - [Habitat Releases](https://discourse.chef.io/c/habitat) 29 | - [InSpec Releases](https://discourse.chef.io/c/chef-release) 30 | 31 | ## Community 32 | 33 | - [Events](https://events.chef.io) 34 | - [chef-dev](https://discourse.chef.io/c/dev) 35 | - [Chef Forums](https://discourse.chef.io) 36 | - [Chef Slack channels](http://slack.chef.io/) 37 | - [habitat-dev](https://forums.habitat.sh/c/core-development) 38 | - [Habitat Forums](https://forums.habitat.sh) 39 | - [Habitat Slack channels](http://slack.habitat.sh) 40 | - [StackOverflow: Chef](https://stackoverflow.com/questions/tagged/chef) 41 | - [StackOverflow: InSpec](https://stackoverflow.com/questions/tagged/inspec) 42 | - [Chef OSS YouTube Channel](https://www.youtube.com/channel/UCvwl5-yXsQR5zluYPl8NEeQ) 43 | - [Habitat YouTube Channel](https://www.youtube.com/channel/UC0wJZeP2dfPZaDUPgvpVpSg/) 44 | 45 | ## Email Aliases 46 | 47 | - community@chef.io - Mail someone on the Chef Software Inc. community advocacy team about a community issue. 48 | - humans@habitat.sh - Contact the Habitat team - inquiries, website, partnerships etc. 49 | - security@chef.io - Submit your findings on a security bug/vulnerability in any of our OSS projects. 50 | - docs@chef.io - Get in touch with the Chef Software, Inc. docs team. 51 | 52 | ## Other 53 | 54 | - [Chef Dashboard - Development Metrics](https://chef.biterg.io/) 55 | - [Habitat Dashboard - Development Metrics](https://habitat.biterg.io/) 56 | - [Inspec Dashboard - Development Metrics](https://inspec.biterg.io/) 57 | - [Security reporting](https://www.chef.io/security/) 58 | -------------------------------------------------------------------------------- /contributors/guide/design-proposals.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Design Proposals 5 | 6 | Chef uses Design Proposals to discuss significant changes to a project before opening a PR. 7 | 8 | ## Why Design Proposals 9 | 10 | - Allows all interested parties (including any community member) to discuss large impact changes to a project. 11 | - Serves as a durable paper trail for discussions regarding project architecture. 12 | - Forces design discussions to occur before PRs are created. 13 | - Reduces PR refactoring and rejected PRs. 14 | 15 | ## When to Open a Design Proposal 16 | 17 | A design proposal should be opened any time a change meets one of the following qualifications: 18 | 19 | - Significantly changes the user experience of a project in a way that impacts users. 20 | - Significantly changes the underlying architecture of the project in a way that impacts other developers. 21 | - Changes the development or testing process of the project such as a change of CI systems or test frameworks. 22 | 23 | ## The Design Proposal Process 24 | 25 | 1. User opens a "Design Proposal" type issue against the project on GitHub using the project-specific issue template. 26 | 2. User posts a link to the issue in the Slack development channel for the project. 27 | 3. Community members and project owners review and discuss the proposal directly in the issue. 28 | 4. User potentially revises the proposal based on community/owner feedback. 29 | 5. After a minimum of 2 business days and a maximum of 7 business days, the project owners will either close the issue or set the label as accepted. 30 | 6. If accepted, the user begins development of their PR. 31 | 7. If no PR is received within 60 days, the proposal issue may be closed as inactive by the project owners. 32 | 33 | ## How Does This Differ From RFCs 34 | 35 | Previously, the Chef project used a RFC process. This RFC process involved proposal documents that were discussed over multiple community meetings and then voted on by the community. This process proved to be overly complex for most of our project needs and also incredibly lengthy as a debated proposal could easily take over a month. 36 | 37 | The Design Proposal process is built to revolve around individual projects in a way that gives more autonomy and speed to the process, and in general, makes it easier on both the user submitting the proposal and other community members. All discussion is contained within issues in the individual GitHub repositories, which makes it easier to reference in the future. Also, as the discussion happens in GitHub Issues, it's easier for those throughout the world to participate in the process. 38 | 39 | ## Structure of a Design Proposal 40 | 41 | ```markdown 42 | # Title 43 | 44 | Description and rationale. 45 | 46 | ## Motivation 47 | 48 | As a <>, 49 | I want to <>, 50 | so that <>. 51 | 52 | ## Specification 53 | 54 | A detailed description of the planned implementation. 55 | 56 | ## Downstream Impact 57 | 58 | Which other tools will be impacted by this work? 59 | ``` 60 | -------------------------------------------------------------------------------- /contributors/guide/help-wanted.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Overview 5 | 6 | We use two labels [Status: Help Wanted](#help-wanted) and [Status: Good First Issue](#good-first-issue) to flag issues that have been identified as well-suited for community contributors. The `Status: Good First Issue` label is a subset of `Status: Help Wanted` label, and indicates that project members have committed to providing extra assistance for new contributors. All `Good First Issue` issues also have the `Help Wanted` label applied. 7 | 8 | We also have some [suggestions](#suggestions) for using these labels to help 9 | grow and improve our community. 10 | 11 | Chef's core projects also have tools to help expose these issues in a meaningful way: 12 | 13 | - [Chef First Issues](https://chef.github.io/jump-in/) 14 | - [Habitat First Issues] 15 | - [InSpec First Issues] 16 | - [Automate First Issues] 17 | 18 | ## Help Wanted 19 | 20 | Issues marked with the `Status: Help Wanted` label need to ensure that they are: 21 | 22 | - **Low (enough) Barrier to Entry** 23 | 24 | It should be tractable for external contributors who don't have 100% context on a project. Documentation on how that type of change should be made should already exist. 25 | 26 | - **Clear Task** 27 | 28 | The task is agreed upon and does not require further discussions in the community. Call out if that area of code is untested and requires new fixtures. 29 | 30 | API / CLI behavior is decided and included in the original issue, for (a completely fabricated and unrealistic) example: _"The new command syntax is `hab origin duplicate NAME [--url] [--auth ]`"_, with expected validations called out. 31 | 32 | - **Priority** 33 | 34 | Not too high that a core contributor should do it, but not so low that it isn't useful enough for a core contributor to spend time to review it, answer questions, help get it into a release, etc. 35 | 36 | - **Up-To-Date** 37 | 38 | Often these issues become obsolete and have already been done, are no longer desired, no longer make sense, have changed priority or difficulty, etc. Project members are encouraged to groom the backlog of `Help Wanted` issues on some regular cadence. 39 | 40 | ## Good First Issue 41 | 42 | Issues marked with the `Status: Good First Issue` label are intended for _first-time contributors_. It indicates that members will keep an eye out for these pull requests and shepherd it through our processes. 43 | 44 | **New contributors should not be left to find an approver, ping for reviews, or identify that their build had a transitive or irreproducible failure.** This makes new contributors feel welcome, valued, and assures them that they will have an extra level of help with their first contribution. 45 | 46 | These issues need to ensure that they follow the guidelines for `Status: Help Wanted` labels (above) in addition to meeting the following criteria: 47 | 48 | - **No Barrier to Entry** 49 | 50 | The task is something that a new contributor can tackle without advanced setup, or domain knowledge. 51 | 52 | - **Solution Explained** 53 | 54 | The recommended solution is clearly described in the issue. 55 | 56 | - **Provides Context** 57 | 58 | If background knowledge is required, this should be explicitly mentioned and a list of suggested readings included. 59 | 60 | - **Gives Examples** 61 | 62 | Link to examples of similar implementations so new contributors have a reference guide for their changes. 63 | 64 | - **Identifies Relevant Code** 65 | 66 | The relevant code and tests to be changed should be linked in the issue. 67 | 68 | - **Ready to Test** 69 | 70 | There should be existing tests that can be modified, or existing test cases fit to be copied. If the area of code doesn't have tests, before labeling the issue, add a test fixture. This prep often makes a great `Help Wanted` task! 71 | 72 | ## Suggestions 73 | 74 | We encourage our more experienced members to help new contributors, so that our community can continue to grow and maintain the kind, inclusive community that we all enjoy today. 75 | 76 | The following suggestions go a long way toward preventing "drive-by" PRs, and ensure that our investment in new contributors is rewarded by them coming back and becoming regulars. 77 | 78 | Provide extra assistance during reviews on `Good First Issue` pull requests: 79 | 80 | - Answer questions and identify useful docs. 81 | - Offer advice such as _"One way to reproduce this in a cluster is to do use docker compose then you can use curl to poke around"_, or _"Did you know that you can use fake clients to setup and test this easier?"_ etc. 82 | - Help new contributors learn enough about the project, setting up their environment, running tests, and navigating this area of the code so that they can tackle a related `Help Wanted` issue next time. 83 | 84 | - Encourage new contributors to seek help on the appropriate Slack channels, introduce them, and include them in your conversations. 85 | - Invite them to Team meetings. 86 | - Give credit to new contributors so that others get to know them, _"Hey, would someone help give a second LGTM on @newperson's first PR on Chef Client?"_. Mention them in the team channel/meeting and/or thank them on twitter! 87 | - Feel free to use all the GIFs as you wish in your approve or LGTM comments. 88 | - If someone opens a PR that fixes an issue labeled `Good First Issue`, let them know their PR is getting extra attention to make the process easier. Additionally, once the PR is merged, help them find a follow-up issue. 89 | - Suggest a related `Help Wanted` issue so that they can build up experience in an area. 90 | - People are more likely to continue contributing when they know what to expect, what's the acceptable way to ask for people to review a PR, or how to nudge things along when a PR is stalled. Show them how we operate by helping move their first PR along. 91 | - If you have time, let the contributor know that they can DM you with questions that they aren't yet comfortable asking the wider group. 92 | -------------------------------------------------------------------------------- /contributors/guide/project-planning.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Project Planning 5 | 6 | Long term project planning, which is different from [triage and prioritization](../../communication/triage.md), is done through Aha! and GitHub. 7 | 8 | ## Aha! 9 | 10 | [Aha!](https://www.aha.io/) is an internal Chef tool used by our Product, Product Operations, and Engineering Leadership teams. This is a place to track high level work and the state of that work. Features are prioritized in Aha! based on business priorities, as well as feedback from our customers and community. Roadmaps created in Aha! will be shared publicly. Feedback on the roadmap is welcome through GitHub as well as other ways, which are still to be decided. 11 | 12 | Aha! does have integrations with GitHub, which are still being tested at this time, so that work can be synced between the two tools. 13 | 14 | Any work involving confidential customer information or confidential business strategy is tracked in Aha! 15 | 16 | ## GitHub 17 | 18 | [GitHub](http://www.github.com) tracks all work from the Engineering level down. Once work is turned into features/tasks/etc. in Aha!, it must be synced to GitHub. There is automation that allows this, though it is still being proven out. Work can also be manually synced if necessary. No confidential customer or business strategy information should ever be placed in GitHub. 19 | 20 | ### ZenHub 21 | 22 | [ZenHub](https://www.zenhub.com/) is a wrapper around GitHub issues that allows for epic tracking and multi-repo boards. Epics must be synced between ZenHub and Aha! and the GitHub integration should allow for this syncing. 23 | -------------------------------------------------------------------------------- /contributors/guide/pull-requests.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Pull Request Process 5 | 6 | This document explains the process and best practices for submitting a pull request to any of the Chef Software, Inc. projects and their associated sub-repositories. It should serve as a reference for all contributors, and be useful, especially to new and infrequent submitters. 7 | 8 | - [Pull Request Process](#pull-request-process) 9 | - [Before You Submit a Pull Request](#before-you-submit-a-pull-request) 10 | - [Run Local Verifications](#run-local-verifications) 11 | - [The Pull Request Submit Process](#the-pull-request-submit-process) 12 | - [The Testing and Merge Workflow](#the-testing-and-merge-workflow) 13 | - [Marking Unfinished Pull Requests](#marking-unfinished-pull-requests) 14 | - [Pull Requests and the Release Cycle](#pull-requests-and-the-release-cycle) 15 | - [Automation](#automation) 16 | - [Why was my pull request closed?](#why-was-my-pull-request-closed) 17 | - [Why is my pull request not getting reviewed?](#why-is-my-pull-request-not-getting-reviewed) 18 | - [Best Practices for Faster Reviews](#best-practices-for-faster-reviews) 19 | - [0. Familiarize yourself with project conventions](#0-familiarize-yourself-with-project-conventions) 20 | - [1. Is the feature wanted? File an Enhancement Proposal](#1-is-the-feature-wanted-file-an-enhancement-proposal) 21 | - [2. Smaller Is Better: Small Commits, Small Pull Requests](#2-smaller-is-better-small-commits-small-pull-requests) 22 | - [Breaking up commits](#breaking-up-commits) 23 | - [Breaking up Pull Requests](#breaking-up-pull-requests) 24 | - [3. Open a Different pull request for Fixes and Generic Features](#3-open-a-different-pull-request-for-fixes-and-generic-features) 25 | - [Put changes that are unrelated to your feature into a different pull request](#put-changes-that-are-unrelated-to-your-feature-into-a-different-pull-request) 26 | - [Look for opportunities to pull out generic features](#look-for-opportunities-to-pull-out-generic-features) 27 | - [4. Comments Matter](#4-comments-matter) 28 | - [5. Test](#5-test) 29 | - [6. Squashing and Commit Titles](#6-squashing-and-commit-titles) 30 | - [General squashing guidelines:](#general-squashing-guidelines) 31 | - [7. KISS, YAGNI, MVP, DRY, etc.](#7-kiss-yagni-mvp-dry-etc) 32 | - [8. It's OK to Push Back](#8-its-ok-to-push-back) 33 | - [9. Common Sense and Courtesy](#9-common-sense-and-courtesy) 34 | - [10. Trivial Edits](#10-trivial-edits) 35 | - [Some questions to consider](#some-questions-to-consider) 36 | 37 | ## Before You Submit a Pull Request 38 | 39 | This guide is for contributors who already have a pull request to submit, or contributors looking for suggestions on how we interact with the larger community. If you're looking for information on setting up your developer environment and creating code to contribute to a specific project, we would suggest viewing that projects CONTRIBUTING.md file. 40 | 41 | First time contributors should head to the [Contributor Guide](README.md) to get started. 42 | 43 | **Make sure your pull request adheres to our best practices. These include following project conventions, making small pull requests, and commenting thoroughly. Please read the more detailed section on [Best Practices for Faster Reviews](#best-practices-for-faster-reviews) at the end of this doc.** 44 | 45 | ### Run Local Verifications 46 | 47 | If a project's CONTRIBUTING.md covers local verifications, you should _absolutely_ run them before you submit your pull request. Often these verifications help predict the pass or fail of automated continuous integration, which will be a requirement for merge in 99.9% of cases. 48 | 49 | ## The Pull Request Submit Process 50 | 51 | Merging a pull request requires the following steps to be completed before the pull request will be merged: 52 | 53 | - [Sign your commits with a DCO](DCO.md) (pre-requisite) 54 | - [Open a pull request](https://help.github.com/articles/about-pull-requests/) 55 | - Pass all End to End (e2e) tests (Check the project's CONTRIBUTING.md for more information.) 56 | - Get all necessary approvals from Reviewers and Approvers 57 | 58 | ### The Testing and Merge Workflow 59 | 60 | Each Chef project could have slightly different merge workflows, but all use a [set of labels](../../repo-management/github-labels.md) to flag various aspects of a pull request. Different projects _could_ require different labels on the path to approval. A generic explanation of how labels are used in pull requests can be found [here](owners.md#code-review-using-codeowners-files). In fully automated projects, an expeditor bot will also automatically apply and/or suggest labels. 61 | 62 | *NOTE: For pull requests that are in progress, but not ready for review, please open the pull request using GitHub's [Draft Pull Request](https://help.github.com/en/articles/about-pull-requests#draft-pull-requests) functionality. 63 | 64 | **************************************************************************************** 65 | 66 | Here's the process the pull request goes through from submission to merging: 67 | 68 | 1. Make the pull request 69 | 2. Reviewers are assigned automatically based on `CODEOWNERS` 70 | 3. Pre-submit tests will run: 71 | 72 | 1. Automatic tests run 73 | 2. If tests fail, resolve issues by pushing edits to your pull request branch 74 | 3. If the failure is a flake, anyone with build system access can simply click retry 75 | 76 | 4. Reviewer suggests edits 77 | 5. Push edits to your pull request branch 78 | 6. Repeat the prior two steps as needed until reviewer(s) approve the pull request. 79 | 7. (Optional) Some reviewers prefer that you squash commits at this step - whether or not this is required is at the discretion of the individual project and team. This repository takes no position on this, other than requiring that projects decide to do or not to do this consistently. 80 | 8. Approver will add the `Approved` label (as well as any other labels unique to their merge process). When applied by someone listed as an Approver in the corresponding project `TEAMS` file, the `Approved` label is a signal that the code has passed final review and the Approver is free to merge the PR 81 | 82 | **************************************************************************************** 83 | 84 | ## Marking Unfinished Pull Requests 85 | 86 | If you want to solicit reviews before the implementation of your pull request is complete, you should open the pull request using GitHub's [Draft Pull Request](https://help.github.com/en/articles/about-pull-requests#draft-pull-requests) functionality. This will prevent incomplete code from being merged into a project. 87 | 88 | ## Pull Requests and the Release Cycle 89 | 90 | If a pull request has been reviewed, but held or not approved, it might be due to the current phase in the [Release Cycle](/contributors/devel/release.md). Occasionally, a team may freeze their own code base when working towards a specific feature or goal that could impact other development. During this time, your pull request could remain unmerged while their release work is completed. 91 | 92 | If you feel your pull request is in this state, contact the appropriate [team](teams/team-list.md) for clarification. 93 | 94 | ## Automation 95 | 96 | The Chef Software, Inc. OSS community uses a variety of automation to manage pull requests. This automation is described in detail [in the automation doc](devel/automation.md). 97 | 98 | ## Why was my pull request closed? 99 | 100 | Pull requests older than 90 days will be closed. Exceptions can be made for pull requests that have active review comments, or that are awaiting other dependent pull requests. Closed pull requests are easy to recreate, and little work is lost by closing a pull request that subsequently needs to be reopened. We want to limit the total number of pull requests in flight to: 101 | 102 | - Maintain a clean project 103 | - Remove old pull requests that would be difficult to rebase as the underlying code has changed over time 104 | - Encourage code velocity 105 | 106 | ## Why is my pull request not getting reviewed? 107 | 108 | A few factors affect how long your pull request might wait for review. 109 | 110 | If it is the last few weeks of a milestone, a team may prefer to reduce churn and stabilize. 111 | 112 | Or, it could be related to best practices. One common issue is that the pull request is too big to review. Let's say that you've touched 39 files and have 8657 insertions. When your would-be reviewers pull up the diffs, they run away - this pull request is going to take 4 hours to review and they don't have 4 hours right now. They'll get to it later, just as soon as they have more free time (ha!). 113 | 114 | There is a detailed rundown of best practices, including how to avoid too-lengthy pull requests, in the next section. 115 | 116 | But, if you've already followed the best practices and you still aren't getting any pull request attention, here are some things you can do to move the process along: 117 | 118 | - Make sure that your pull request has an assigned reviewer (assignee in GitHub). If not, reply to the pull request comment stream asking for a reviewer to be assigned. 119 | 120 | - Ping the assignee (@username) on the pull request comment stream, and ask for an estimate of when they can get to the review. 121 | 122 | - Ping the assignee in [Slack](https://community-slack.chef.io/). Remember that a person's GitHub username might not be the same as their Slack username. 123 | 124 | - Ping the assignee by email. Many of us have publicly available email addresses. 125 | 126 | - If you're a member of the organization, ping the [team](https://github.com/orgs/chef/teams) (via @team-name) that works in the area you're submitting code. 127 | 128 | - If you have fixed all the issues from a review, and you haven't heard back, you should ping the assignee on the comment stream with a "please take another look" (`PTAL`), or similar comment indicating that you are ready for another review. 129 | 130 | Read on to learn more about how to get faster reviews by following best practices. 131 | 132 | ## Best Practices for Faster Reviews 133 | 134 | Most of this section is not specific to Chef, but it's good to keep these best practices in mind when you're making a pull request. 135 | 136 | You've just had a brilliant idea on how to make a Chef Software Inc. project better. Let's call that idea: Feature-X. Feature-X is not even that complicated. You have a pretty good idea of how to implement it. You jump in and implement it, fixing a bunch of stuff along the way. You send your pull request - this is awesome! And it sits. And sits. A week goes by and nobody reviews it. Finally, someone offers a few comments, which you fix up and wait for more review. And you wait. Another week or two go by. This is horrible. 137 | 138 | Let's talk about best practices so your pull request gets reviewed quickly. 139 | 140 | ## 0. Familiarize yourself with project conventions 141 | 142 | - [Development guide](devel/development.md) 143 | - [Coding conventions](coding-conventions.md) 144 | - [API conventions](devel/api-conventions.md) 145 | 146 | ## 1. Is the feature wanted? File an Enhancement Proposal 147 | 148 | Are you sure Feature-X is something the project team wants or will accept? Is it implemented to fit with other changes in flight? Are you willing to bet a few days or weeks of work on it? 149 | 150 | It's better to get confirmation beforehand. 151 | 152 | Even for small changes, it is often a good idea to gather feedback on an issue you filed, or even simply ask in the appropriate team's Slack channel to invite discussion and feedback from project owners. Here's a [list of teams](../../team-list.md). 153 | 154 | ## 2. Smaller Is Better: Small Commits, Small Pull Requests 155 | 156 | Small commits and small pull requests get reviewed faster and are more likely to be correct than big ones. 157 | 158 | Attention is a scarce resource. If your pull request takes 60 minutes to review, the reviewer's eye for detail is not as keen in the last 30 minutes as it was in the first. It might not get reviewed at all if it requires a large continuous block of time from the reviewer. 159 | 160 | ### Breaking up commits 161 | 162 | Break up your pull request into multiple commits, at logical break points. 163 | 164 | Making a series of discrete commits is a powerful way to express the evolution of an idea or the 165 | different ideas that make up a single feature. Strive to group logically distinct ideas into separate commits. 166 | 167 | For example, if you found that Feature-X needed some prefactoring to fit in, make a commit that JUST does that prefactoring. Then, make a new commit for Feature-X. 168 | 169 | Strike a balance with the number of commits. A pull request with 25 commits is still very cumbersome to review, so use your best judgment. 170 | 171 | ### Breaking up Pull Requests 172 | 173 | Or, going back to our prefactoring example, you could also fork a new branch, do the prefactoring there and send a pull request for that. If you can extract whole ideas from your pull request and send those as pull requests of their own, you can avoid the painful problem of continually rebasing. 174 | 175 | Open source software projects are usually fast-moving codebases - lock in your changes ASAP with your small pull request and avoid merge headaches. 176 | 177 | Multiple small pull requests are often better than multiple commits. Don't worry about flooding us with pull requests. We'd rather have 100 small, obvious pull requests than 10 unreviewable monoliths. 178 | 179 | We want every pull request to be useful on its own, so use your best judgment on what should be a pull request vs. a commit. 180 | 181 | As a general rule, if your pull request is directly related to Feature-X and nothing else, it should probably be part of the Feature-X pull request. If you can explain why you are doing seemingly no-op work - "it makes the Feature-X change easier, I promise" - we'll probably be OK with it. If you can imagine someone finding value independently of Feature-X, try it as a pull request. (Do not link pull requests by `#` in a commit description, because GitHub creates lots of spam. Instead, reference other pull requests via the pull request your commit is in.) 182 | 183 | ## 3. Open a Different pull request for Fixes and Generic Features 184 | 185 | ### Put changes that are unrelated to your feature into a different pull request 186 | 187 | Often, as you are implementing Feature-X, you will find bad comments, poorly named functions, bad structure, weak type-safety, etc. 188 | 189 | You absolutely should fix those things -- or at least file issues, please -- but not in the same pull request as your feature. Otherwise, your diff will have way too many changes, and your reviewer won't see the forest for the trees. 190 | 191 | ### Look for opportunities to pull out generic features 192 | 193 | For example, if you find yourself touching a lot of modules, think about the dependencies you are introducing between packages. Can some of what you're doing be made more generic, and moved up and out of the Feature-X package? Do you need to use a function or type from an otherwise unrelated package? If so, let us know! We have places for hosting more generic code. 194 | 195 | Likewise, if Feature-X is similar in form to Feature-W, which was checked in last month, and you're duplicating some tricky stuff from Feature-W, consider prefactoring the core logic out and using it in both Feature-W and Feature-X. (Do that in its own commit or pull request, please.) 196 | 197 | ## 4. Comments Matter 198 | 199 | In your code, if someone might not understand why you did something (or you won't remember why later), comment it. Many code-review comments are about this exact issue. 200 | 201 | If you think there's something pretty obvious that we could follow up on, add a TODO. 202 | 203 | ## 5. Test 204 | 205 | Nothing is more frustrating than starting a review, only to find that the tests are inadequate or absent. Very few pull requests can touch code and NOT touch tests. If the code you are adding does not touch existing tests, consider adding test coverage. 206 | 207 | If you don't know how to test Feature-X, please ask! We'll be happy to help you design things for easy testing, or to suggest appropriate test cases. 208 | 209 | ## 6. Squashing and Commit Titles 210 | 211 | Your reviewer has finally sent you feedback on Feature-X. 212 | 213 | Make the fixups, and don't squash yet. Put them in a new commit, and re-push. That way your reviewer can look at the new commit on its own, which is much faster than starting over. 214 | 215 | We might still ask you to clean up your commits at the very end for the sake of a more readable history, but don't do this until asked: typically at the point where the pull request would otherwise be tagged `LGTM`. 216 | 217 | Each commit should have a good title line (<70 characters) and include an additional description paragraph describing in more detail the change intended. 218 | 219 | ### General squashing guidelines: 220 | 221 | - Sausage => squash 222 | 223 | Do squash when there are several commits to fix bugs in the original commit(s), address reviewer feedback, etc. Really we only want to see the end state and commit message for the whole pull request. 224 | 225 | - Layers => don't squash 226 | 227 | Don't squash when there are independent changes layered to achieve a single goal. For instance, writing a code munger could be one commit, applying it could be another, and adding a precommit check could be a third. One could argue they should be separate pull requests, but there's really no way to test/review the munger without seeing it applied, and there needs to be a precommit check to ensure the munged output doesn't immediately get out of date. 228 | 229 | A commit, as much as possible, should be a single logical change. 230 | 231 | ## 7. KISS, YAGNI, MVP, DRY, etc. 232 | 233 | Sometimes we need to remind each other of core tenets of software design - Keep It Simple, You Aren't Gonna Need It, Minimum Viable Product, Don't Repeat Yourself, and so on. Adding a feature "because we might need it later" is antithetical to software that ships. Add the things you need NOW and (ideally) leave room for things you might need later - but don't implement them now. 234 | 235 | ## 8. It's OK to Push Back 236 | 237 | Sometimes reviewers make mistakes. It's OK to push back on changes your reviewer requested. If you have a good reason for doing something a certain way, you are absolutely allowed to debate the merits of a requested change. Both the reviewer and reviewee should strive to discuss these issues in a polite and respectful manner. 238 | 239 | You might be overruled, but you might also change someone's mind. Working to better understand each other can sometimes be challenging, but often leads to better solutions. 240 | 241 | Another phenomenon of open-source projects (where anyone can comment on any issue) is the dog-pile - your pull request gets so many comments from so many people it becomes hard to follow. In this situation, you can ask the primary reviewer (assignee) whether they want you to fork a new pull request to clear out all the comments. You don't HAVE to fix every issue raised by every person who feels like commenting, but you should answer reasonable comments with an explanation. 242 | 243 | ## 9. Common Sense and Courtesy 244 | 245 | No document can take the place of common sense and good taste. Use your best judgment, while you put 246 | a bit of thought into how your work can be made easier to review. If you do these things your pull requests will get merged with less friction. 247 | 248 | ## 10. Trivial Edits 249 | 250 | Each incoming Pull Request needs to be reviewed, checked, and then merged. 251 | 252 | While automation helps with this, each contribution also has an engineering cost. Therefore it is appreciated if you do NOT make trivial edits and fixes, but instead focus on giving the entire file a review. 253 | 254 | If you find one grammatical or spelling error, it is likely there are more in that file, you can really make your Pull Request count by checking formatting, checking for broken links, and fixing errors and then submitting all the fixes at once to that file. 255 | 256 | ## Some questions to consider 257 | 258 | - Can the file be improved further? 259 | - Does the trivial edit greatly improve the quality of the content? 260 | -------------------------------------------------------------------------------- /contributors/guide/ways-to-contribute.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # More Ways to Contribute 5 | 6 | ## GitHub 7 | 8 | - Interact with the community through Issue and Pull Request triage. 9 | - Help educate users on code standards in the project. 10 | - Help keep documentation and README's updated. 11 | 12 | ## Slack and Discourse 13 | 14 | Interact with existing community members on Slack and Discourse and inform others of their existence. Its helpful to educate users by answering questions about how our software works and how the community can help improve it. 15 | 16 | ## Learn Chef Rally 17 | 18 | Many community members learn about Chef products through [Learn Chef Rally](https://learn.chef.io) and you can help create or update content. 19 | 20 | ## Writing 21 | 22 | Write an article about software for a blog, magazine, or book. Make sure to mention software version and include a date. 23 | 24 | ## Speaking 25 | 26 | Speak at a local meetup, conference, or on a podcast. 27 | -------------------------------------------------------------------------------- /contributors/project-forks-guidelines.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | See the [guidelines for distribution](./distribution-guidelines.md). -------------------------------------------------------------------------------- /cspell.json: -------------------------------------------------------------------------------- 1 | { 2 | // Version of the setting file. Always 0.1 3 | "version": "0.1", 4 | // language - current active spelling language 5 | "language": "en", 6 | // words - list of words to be always considered correct 7 | "words": [ 8 | "adamhjk", 9 | "adamleff", 10 | "afiune", 11 | "alam", 12 | "aleer", 13 | "alexpop", 14 | "appbundle", 15 | "appbundler", 16 | "apriofrost", 17 | "aronsohn", 18 | "authn", 19 | "bcmdarroch", 20 | "berkshelf", 21 | "binstubs", 22 | "blakestier", 23 | "boneyarding", 24 | "brenna", 25 | "cating", 26 | "certstore", 27 | "cheatsheet", 28 | "cheeseplus", 29 | "cheffish", 30 | "chefsalim", 31 | "chefstyle", 32 | "chisamore", 33 | "christophermaier", 34 | "christopherson", 35 | "cinc", 36 | "clintoncwolfe", 37 | "cloke", 38 | "codebases", 39 | "codeowners", 40 | "coderanger", 41 | "cookstyle", 42 | "cowie", 43 | "crae", 44 | "cragun", 45 | "cwolfe", 46 | "danielsdeleo", 47 | "danna", 48 | "darroch", 49 | "davymcaleer", 50 | "devs", 51 | "dibowitz", 52 | "didrichsen", 53 | "digitalocean", 54 | "distro", 55 | "distros", 56 | "doxing", 57 | "duffield", 58 | "eeyun", 59 | "efast", 60 | "epgsql", 61 | "erlzmq", 62 | "eventlog", 63 | "fauxhai", 64 | "finfrock", 65 | "fixie", 66 | "fujin", 67 | "garmoe", 68 | "gavindidrichsen", 69 | "gitter", 70 | "goiardi", 71 | "granquist", 72 | "gugan", 73 | "httpc", 74 | "ibrowse", 75 | "inspec", 76 | "itmustbejj", 77 | "jaym", 78 | "jaymzh", 79 | "jeremymv", 80 | "jhudson", 81 | "jinglewski", 82 | "jkeiser", 83 | "johnmccrae", 84 | "johnshow", 85 | "jonlives", 86 | "jonsmorrow", 87 | "jtimberman", 88 | "kagarmoe", 89 | "kallistec", 90 | "kantrowitz", 91 | "kartik", 92 | "keiser", 93 | "kmacgugan", 94 | "krasnow", 95 | "ksubrama", 96 | "kyleen", 97 | "lancefw", 98 | "leff", 99 | "lellan", 100 | "libarchive", 101 | "libyajl", 102 | "linode", 103 | "macfarlane", 104 | "magwalk", 105 | "maier", 106 | "mandi", 107 | "marcparadise", 108 | "markan", 109 | "mikedodge", 110 | "mixlib", 111 | "mjingle", 112 | "mmap", 113 | "moser", 114 | "mparadise", 115 | "mshafique", 116 | "msorens", 117 | "mudash", 118 | "mudassar", 119 | "mundrawala", 120 | "murawksi", 121 | "mutex", 122 | "mware", 123 | "mwrock", 124 | "ohai", 125 | "omnifetch", 126 | "oneview", 127 | "onlyhavecans", 128 | "openstack", 129 | "opscoderl", 130 | "orgs", 131 | "outro", 132 | "phiggins", 133 | "prajakta", 134 | "prajaktapurohit", 135 | "purohit", 136 | "ranjib", 137 | "raskchanky", 138 | "rdavis", 139 | "reindex", 140 | "renatus", 141 | "repoman", 142 | "repos", 143 | "rickmarry", 144 | "roadmap", 145 | "robb", 146 | "robbkidd", 147 | "ryancragun", 148 | "salim", 149 | "schisamo", 150 | "schwad", 151 | "schwaderer", 152 | "scottopherson", 153 | "scripter", 154 | "sdelano", 155 | "shadae", 156 | "shafique", 157 | "shellout", 158 | "signoff", 159 | "skpaterson", 160 | "smacfarlane", 161 | "smarshall", 162 | "smurawski", 163 | "sorens", 164 | "sqerl", 165 | "srenatus", 166 | "stevendanna", 167 | "stevenmurawski", 168 | "stocksy", 169 | "stuartpreston", 170 | "subproject", 171 | "subramanian", 172 | "susanev", 173 | "symlink", 174 | "symlinked", 175 | "symlinks", 176 | "tarablack", 177 | "taskscheduler", 178 | "tball", 179 | "tduffield", 180 | "teknofire", 181 | "thom", 182 | "thommay", 183 | "timberman", 184 | "toolchain", 185 | "trello", 186 | "triaged", 187 | "triaging", 188 | "tylercloke", 189 | "untriaged", 190 | "vcenter", 191 | "vjeffrey", 192 | "vmware", 193 | "vsphere", 194 | "webhooks", 195 | "wrock", 196 | "yajl", 197 | "zenspider" 198 | ], 199 | // flagWords - list of words to be always considered incorrect 200 | // This is useful for offensive words and common spelling errors. 201 | // For example "hte" should be "the" 202 | "flagWords": [ 203 | "hte" 204 | ] 205 | } 206 | -------------------------------------------------------------------------------- /distributions/distribution-guidelines.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Guidelines for Distributions 5 | 6 | So you want to create a new distro of a Chef product…. 7 | 8 | Excellent! Welcome aboard! 9 | 10 | Anyone is welcome to make a distribution of Chef’s Open Source products, but must remove Chef trademarks from the code base (see the full [Chef trademark policy](https://www.chef.io/trademark-policy/) for details). 11 | 12 | ## Why does Chef require removal of Trademarks? 13 | 14 | The purpose of Chef’s Trademark Policy is to avoid any confusion about which distributions come from Chef the company (which are supported, warrantied, and indemnified) and which distributions come from somewhere else (which are not supported, warrantied, or indemnified by Chef). 15 | 16 | ## How does this affect you? 17 | 18 | If you offer products or services related to Chef products, you may use the Chef name in describing and advertising your product so long as you don't mislead customers into thinking that either your website, service, or product is a Chef Software website, service, or product, or that Chef has any direct relationship with your organization. For example: "Nell's Management Dashboard for Chef Habitat" is okay. "Nell's Chef" is not okay, nor is "Nell's Chef Automate Dashboard". 19 | 20 | Additionally, commands used to execute the distribution - if they include trademarks of Chef - must be different from those in Chef Software's distribution. For example, if you create a distribution of Chef, the command to use your distribution's binary cannot be "chef", though it can be something like "kitty" - the goal is prevent confusion about which distributions come from Chef Software and which come from another source. 21 | 22 | That said, it is ok to symlink a command to a distribution's equivalent command. If you have created a distribution of "chef" called "kitty", it is fine to symlink "chef-client" to call "kitty-client". In these cases. you do need to make it clear that the user is using "kitty" and not "chef". If someone uses "chef-client" and it calls "kitty-client" - the command output should display words to the user reminding them that they are using "kitty" and a symlinked command, rather that the official "chef" distribution. 23 | 24 | ## What are some examples of removing trademarks? 25 | 26 | The Chef community has begun the process of creating a Community distribution of Chef itself - beginning with implementing a way to handle Chef’s trademarks throughout the code. They created a Chef::Dist namespace and replaced all Chef trademarks in the code with a configurable variable - i.e. “Chef Server” became “Chef::Dist::SERVER_PRODUCT” 27 | 28 | This pull request was created in collaboration and reviewed by Chef Software and is a good implementation of what we are looking for when requiring that distros remove Chef’s trademarks. Please feel free to use it as a reference: 29 | 30 | You can also see the conversation around the decisions of that pull request in this design proposal: 31 | 32 | ## What about Chef code libraries used in distributions? 33 | 34 | You do not have to remove Chef from the existing Ruby class names, e.g. Chef::Log or Chef::Dist. 35 | 36 | However, if you add a new class or create a derived class, the name of that new class should not include Chef. 37 | 38 | For example: 39 | 40 | Chef::Dist::Kitty is absolutely fine. 41 | 42 | Chef::Dist::ChefKitty is not fine. 43 | 44 | We do recognize that sometimes it is necessary to make modifications to existing class names that include Chef trademarks - especially when you are monkey patching a class to add new behavior. It is fine to restart existing module/class namespaces to make behavior modifications. 45 | 46 | ## Do you need to change the installation paths for distributions? 47 | 48 | Yes, do not reuse /opt/chef, /etc/chef, etc. as installation paths. It is fine if the distribution uses symlinks or other tools to make migration easier. 49 | 50 | ## Can you reference the Chef gem? 51 | 52 | Yes. Chef is currently removing binstubs from the Chef gem to allow it to function as a library, rather than an executable. It is fine to reference the Chef gem as a library from your code, but derived and modified class names should not include Chef trademarks. 53 | 54 | ## Do you need to change config variables? 55 | 56 | No, so long as it is still clear which distribution the user is using. 57 | 58 | For example 59 | 60 | ```shell 61 | cinc-client --chef_server_url 62 | ``` 63 | 64 | is fine, because it is still very clear from the command that the user is using "cinc-client" rather than "chef-client". 65 | 66 | Generally, if it's still clear where the origin of the distribution is, and if changing the config files would break compatibility, it is ok to leave them as they are. If you have specific questions about this, please ask! 67 | 68 | ## Can Chef evaluate my distribution to make sure its following the trademark guidelines? 69 | 70 | While Chef is happy to answer questions and provide advice related to our guidelines, it is ultimately the responsibility of the maintainers of the distribution to ensure it follows our trademark policy. If you have questions about these policies or whether something would potentially violate them, please feel free to ask in the #community-distros channel in Community Slack. 71 | 72 | In the past, we have evaluated a community distribution by comparing the experience of using it to the experience of using the official Chef distribution. The main thing we look for is that it is clear which distribution a user is using. In that case, we were able to communicate to the maintainers that we saw nothing which violated our trademark guidelines at that time. 73 | 74 | ## Can Chef endorse my distribution as following the trademark guidelines? 75 | 76 | Chef will not be endorsing any distributions or versions of distributions of our source code except our own. 77 | 78 | ## Will these guidelines ever change? 79 | 80 | Yes, they will likely change as we learn from creating distributions and iterate on the process. Additionally, the purpose of the Chef Trademark Policy is to avoid confusion in the market about which distributions come from Chef and which distributions come from other sources. If we find that these guidelines are not sufficient to avoid that confusion, we may need to revisit them. We will, of course, give ample notice of any changes to these guidelines to allow for plenty of time to implement them. 81 | -------------------------------------------------------------------------------- /distributions/distribution-list.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Distributions 5 | 6 | Along with the [official Chef distributions](https://downloads.chef.io/) of our Open Source projects, members of our community have created alternative distributions of Chef's Open Source products. These are listed below. 7 | 8 | ## Cinc 9 | 10 | The Cinc project currently includes community distributions of Chef Infra Client (Cinc Client) and Chef InSpec (Cinc Auditor). 11 | 12 | - [Source Code](https://gitlab.com/cinc-project) 13 | - [Builds](http://downloads.cinc.sh/) 14 | - [Project Site](https://cinc.sh/) 15 | 16 | ## Biome 17 | 18 | This is a community distribution of Habitat. 19 | 20 | - [Source Code](https://github.com/biome-sh/biome) 21 | - [Project Site](https://biome.sh/) 22 | 23 | ## Goiardi 24 | 25 | Not technically a community distribution, Goiardi is a feature-limited implementation of Chef Server, written in [Go](https://golang.org/). 26 | 27 | - [Source Code](https://github.com/ctdk/goiardi) 28 | - [Project Site](http://goiardi.gl/) 29 | 30 | If you have any updates or corrections, please feel free to email community@chef.io or open a pull request to update this page! 31 | -------------------------------------------------------------------------------- /governance.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | This is a Work in Progress, documenting approximately how we believe we should be operating. 5 | 6 | # Principles 7 | 8 | The Chef OSS communities adhere to the following principles: 9 | 10 | - Open: All Chef software is open source. See [repository guidelines](#repository-guidelines) and [DCO](#dco) information below. 11 | - Welcoming and respectful: See [Code of Conduct](#code-of-conduct) below. 12 | - Transparent and accessible: Work and collaboration should be done in public. See [community groups](#community-groups) below. 13 | - Inclusiveness: Ideas and contributions are welcome from all those willing to participate in alignment with project objectives. We value the power of different perspectives and enjoy working to understand one another so we can create better solutions than we would separately. 14 | 15 | ## Code of Conduct 16 | 17 | All members of the Chef community, including employees, must abide by the Chef Code of Conduct. For the complete text, see the [Chef Code of Conduct](CODE_OF_CONDUCT.md). 18 | 19 | ## Project Membership 20 | 21 | Please refer to [Project Membership](project-membership.md) for more information. 22 | 23 | ## Community Groups 24 | 25 | The Chef OSS Communities have 3 main types of groups: 26 | 27 | - Teams 28 | - Guilds 29 | - Committees 30 | 31 | ### Teams 32 | 33 | Teams are sets of people within an individual project that focus on various parts of that project. Teams _must_ have open and transparent proceedings and communication. Anyone is welcome to participate and contribute to a team, provided they follow the Chef OSS Code of Conduct and read to understand the team's governance policy. 34 | 35 | ### Guilds 36 | 37 | [Guilds](guilds/README.md) are groups of individuals with shared interests in specific subjects that may be tangential to the project they are a member of. The purpose of guilds is to provide knowledge cross-pollination as well as establish standards and practices within the scope of the interest to the larger community. These can be anything from a group sharing knowledge on a specific language - e.g. the Go guild - to a group discussing the merits of various web frameworks - e.g. the Web Guild - and anything in between. 38 | 39 | ### Committees 40 | 41 | Committees are named sets of people that are chartered to take on sensitive or specific topics. This group type is encouraged to be as open as possible while achieving its mission, but some private communication is expected because of the potential sensitive nature of the topics discussed. 42 | 43 | ## Repository Guidelines 44 | 45 | All new repositories under the Chef, Habitat, or Inspec GitHub orgs should follow the processes outlined in the [Chef OSS repository guidelines](repo-management/README.md). 46 | 47 | ## DCO 48 | 49 | This project uses a [Developer Certificate of Origin (DCO)](DCO.md) to ensure that each commit was written by the author or that the author has the appropriate rights necessary to contribute the change. 50 | 51 | ## End of Life for a Project 52 | 53 | Sometimes in the life of a project, there comes a time where the humans contributing to it have reasons to stop. Maybe a new project is developed that solves the original problem better. Maybe the humans have other priorities in their life. Whatever the reason, we intend for the project to clearly communicate how well-supported it is. 54 | 55 | For Chef Software (the company) to continue providing resources to a project, there must be two or more Chef employees active in the project. At a point where Chef Software has decided to reduce or end involvement with a project under its purview, the project owners will make announcements, post notices, and archive the repository in according to the [communication plan for project end-of-life](communication/project-eol.md). 56 | -------------------------------------------------------------------------------- /guilds/README.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Guilds 5 | 6 | ## Summary 7 | 8 | Guilds have formed in the Chef OSS community in order to foster a culture of learning and empathy. These guilds serve as a place where like-minded people can gather and discuss shared interests that are tangential to their projects. Currently, Chef has formed several language specific guilds (ruby, rust, go). 9 | 10 | ## Goals of the Language Guilds 11 | 12 | - Help establish recommended standards and styles for the language 13 | - Answer questions about the guild's language use within projects 14 | - (Mentor?)Assist new users and developers in learning the language and increasing skills 15 | 16 | These guilds consist of multiple people, so that decisions are made democratically. The guilds also focus on creating recommended practices, though _not_ enforcement of those practices. Adoption and adherence should occur with the project teams, with documentation written about deviations from a standard or recommendation. 17 | 18 | ## Recommended Implementation 19 | 20 | Successful language-specific guilds: 21 | 22 | - Have a channel for communication (e.g. #rust-guild) 23 | - Have periodic meetings where topics can be discussed 24 | - Catalog information and results of conversations in a discoverable and accessible way 25 | -------------------------------------------------------------------------------- /physical-spaces-code-of-conduct.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Code of Conduct 5 | 6 | This document has been merged into, and is now superseded by, the [Code of Conduct](https://github.com/chef/chef-oss-practices/blob/master/CODE_OF_CONDUCT.md). 7 | -------------------------------------------------------------------------------- /project-membership.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Project Membership 5 | 6 | ## New Contributors 7 | 8 | [New contributors] should be welcomed to the community by existing project members, helped with PR workflow, and directed to relevant documentation and communication channels. 9 | 10 | ## Established Project Members 11 | 12 | Established project members are expected to demonstrate their adherence to the principles in this document, familiarity with project organization, roles, policies, procedures, conventions, etc., and technical and/or writing ability. Role-specific expectations, responsibilities, and requirements are enumerated below. 13 | 14 | **Note:** This document is in progress, it outlines the various responsibilities of project roles in the Chef Software Inc. OSS Communities. Chef's software is organized into projects under teams. Responsibilities/Privileges for most roles are scoped to a project or subproject. 15 | 16 | | Project Role | Responsibilities | Requirements | Defined by | 17 | | ------------- | ------------------------------------------------------------------- | ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | 18 | | contributor | you become a contributor to the project by opening a PR or an Issue | No requirements | Having your GitHub handle recognized in the project changelog and/or release notes | 19 | | reviewer | review contributions from other members | history of review and authorship in a project | project [CODEOWNERS] entry, Chef OSS [PROJECTS] file *reviewer* entry | 20 | | approver | final approval and acceptance of contributions | highly experienced and active reviewer + contributor to a project | project [CODEOWNERS] entry, Chef OSS [PROJECTS] file *approver* entry | 21 | | project owner | set direction and priorities for a project | demonstrated responsibility and excellent technical judgment for the project | project [CODEOWNERS] entry, Chef OSS [PROJECTS] file *owners* entry | 22 | 23 | ## Reviewer 24 | 25 | Project Reviewers are continuously active contributors in the community. They can have issues and PRs assigned to them, participate in project development. Reviewers are expected to remain active contributors to the project. In the case that a reviewer becomes inactive their review privileges will be removed. 26 | 27 | Reviewers are able to review code for quality and correctness on some part of a project. They are knowledgeable about both the codebase and software engineering principles. 28 | 29 | *Note*: All Chef Software lives in open repos, and we welcome contribution and code reviews from anyone! The reviewer project role specifically refers to the following outlined responsibilities and privileges. Acceptance of code contributions requires at least one approver in addition to the assigned reviewers. 30 | 31 | **Defined by:** An entry in a CODEOWNERS file in a repo owned by the specific Chef Software Inc. Project. A *reviewer* entry in the Chef OSS [TEAMS] file. 32 | 33 | Reviewer status is scoped to a project. 34 | 35 | ### Requirements 36 | 37 | - Enabled [two-factor authentication] on their GitHub account 38 | - Actively contributes to the project. Contributions may include, but are not limited to: 39 | - Authoring or reviewing PRs on GitHub 40 | - Filing or commenting on issues on GitHub 41 | - Have read the [Chef Software Inc. Contributor Guide] 42 | - Subscribed to the project's core-development mailing list and/or chat channel 43 | - Sponsored by 2 reviewers (or approvers). **Note the following requirements for sponsors**: 44 | - Sponsors must have close interactions with the prospective member - e.g. code/design/proposal review, coordinating on issues, etc. 45 | - Sponsors must be reviewers or approvers in the related Chef Software Inc. OSS project 46 | - **Open a membership request issue against the project repo** 47 | - Ensure your sponsors are @mentioned on the issue 48 | - Complete every item on [the checklist](.github/ISSUE_TEMPLATE/membership.md) in the issue template 49 | - Make sure that the list of contributions included is representative of your work on the project. 50 | - Have your sponsoring reviewers confirm their sponsorship with a GitHub PR approval 51 | - Once your sponsors have responded, your request will be reviewed by the project's approvers, within the response time maximum defined by the project. Any missing information will be requested. 52 | 53 | ### Chef Software Ecosystem 54 | 55 | There are many interrelated [Chef Software GitHub organizations], such as [habitat-sh](https://github.com/habitat-sh/habitat), [chef](https://github.com/chef), and [inspec](https://github.com/chef/inspec). Membership to one of these organizations doesn't inherently grant membership to another, however the perks and membership process are uniform no matter what organization or Chef Software Inc. project you contribute to. 56 | 57 | ### Responsibilities and Privileges 58 | 59 | The following applies to the codebases for which one is listed as a reviewer in a [CODEOWNERS] file. 60 | 61 | - Responsible for project quality control via [code reviews] 62 | - Focus on code quality and correctness, including [testing](contributors/guide/README.md#testing) 63 | - Encouraged to review for more holistic issues, but not a requirement 64 | - Expected to be responsive to review requests, issues, and mentions and as per [community expectations] 65 | - Assigned PRs to review related to a reviewer's areas of interest or experience 66 | - Assigned test bugs related to a reviewer's areas of interest or experience 67 | - Granted "read access" to appropriate project repos 68 | 69 | **Note:** Reviewers have no expectation of transitioning to an Approver role. The expectations for approver are quite high comparatively. If a reviewer drops below a reasonable threshold of activity (definable, project to project) their privileges as a reviewer may be revoked, they will remain listed as a contributor and alum. 70 | 71 | ## Approver 72 | 73 | Code approvers are able to both review and approve code contributions. While code review is focused on code quality and correctness, approval is focused on holistic acceptance of a contribution including: backwards / forwards compatibility, adhering to API and flag conventions, subtle performance and correctness issues, interactions with other parts of the system, etc. 74 | 75 | **Defined by:** an entry in a CODEOWNERS file in a repo owned by the Chef Software Inc. project AND merge rights to a project's trunk. An *approver* entry in the Chef OSS [TEAMS] file. 76 | 77 | Approver status is scoped to a project. 78 | 79 | ### Requirements 80 | 81 | The following requirements apply to the portions of a project for which one would be an approver. 82 | 83 | - Enabled [two-factor authentication] on their GitHub account 84 | - Must already be a reviewer of the codebase (each project may define a minimum reviewer tenure requirement to qualify) 85 | - Primary reviewer for several substantial PRs to the codebase (each project may define a minimum to qualify) 86 | - Nominated by an approver _and_ seconded by a project owner 87 | - With no objections from other project owners or approvers 88 | - Accomplished through a PR to update the CODEOWNERS file 89 | - On Merge project owner grants merge privileges to project trunk 90 | 91 | ### Responsibilities and Privileges 92 | 93 | The following apply to the portions of a project for which one would be an approver. 94 | 95 | - Demonstrate sound technical judgment 96 | - Responsible for project quality control via [code reviews] 97 | - Focus on holistic acceptance of contribution such as dependencies with other features, backwards / forwards compatibility, API and flag definitions, etc 98 | - Expected to be responsive to review requests as per [community expectations] 99 | - Mentor contributors and reviewers 100 | - May approve and merge code contributions 101 | - Approver status may be a precondition to accepting large code contributions 102 | 103 | ## Project Owner 104 | 105 | **Note:** This is a generalized high-level description of the role, and the specifics of the project owner role's responsibilities and related processes *MUST* be defined for individual teams or projects. 106 | 107 | Project Owners are the technical authority for all Chef Software Inc. OSS projects. They *MUST* have demonstrated both good judgment and responsibility towards the health of that project. Project Owners *MUST* set _technical_ direction and make or approve _technical_ design decisions for their project - either directly or through delegation of these responsibilities. 108 | 109 | **Defined by:** *owners* entry in project [CODEOWNERS] files. An *owner* entry in the Chef OSS [TEAMS] file *project.owners* 110 | 111 | ### Requirements 112 | 113 | The process for becoming a project Owner should be defined in the team charter of the team owning the project. Unlike the roles outlined above, the Owners of a project are typically limited to a relatively small group of decision makers and updated as fits the needs of the project. More often than not these individuals are Principal Engineers @ Chef Software Inc. and have a connection to an internal product owner with whom they are closely collaborating. 114 | 115 | The following apply to the project for which one would be an owner. 116 | 117 | - Enabled [two-factor authentication] on their GitHub account 118 | - Deep understanding of the technical goals and direction of the project 119 | - Deep understanding of the technical domain of the project 120 | - Sustained contributions to design and direction by doing all of: 121 | - Authoring and reviewing proposals 122 | - Initiating, contributing and resolving discussions (emails, GitHub issues, meetings) 123 | - Identifying subtle or complex issues in designs and implementation PRs 124 | - Directly contributed to the project through implementation and / or review 125 | 126 | ### Responsibilities and Privileges 127 | 128 | The following apply to the project for which one would be an owner. 129 | 130 | - Make and approve technical design decisions for the project. 131 | - Set technical direction and priorities for the project. 132 | - Define milestones and releases. 133 | - Mentor and guide approvers, reviewers, and contributors to the project. 134 | - Ensure continued health of project 135 | - Adequate test coverage to confidently release 136 | - Tests pass reliably (i.e. not flaky) and are fixed when they fail 137 | - Ensure a healthy process for open discussion and public decision making is in place. 138 | - Work with other project owners to holistically maintain the project's health and success 139 | 140 | ## Alums 141 | 142 | Alums to the Chef Inc OSS Projects is an individual who was formerly a member and has for any reason dropped their activity below a project's accepted threshold. This covers all cases of dropped activity and any case in which the individual has stated their decision to terminate their involvement in a project. Alums no longer have responsibilities or privileges to the project of which they were formerly a member. Their rights to project repos and tooling are revoked and they are added to an Alums list in thanks of their previous contributions. 143 | 144 | Alum status is straightforward - Thank you for being involved. An alum is welcome to re-engage a project for membership, however it is at the discretion of the team as to whether the returning alum will directly resume their previous role. 145 | 146 | ## ~~Maintainer~~ 147 | 148 | **Status:** Removed 149 | 150 | The Maintainer role has been removed and replaced with a greater focus on explicit roles as defined in the [TEAMS] file. 151 | 152 | [Chef Software Inc. Contributor Guide]: contributors/guide/README.md 153 | [community expectations]: contributors/guide/community-expectations.md 154 | 155 | [code reviews]: contributors/? 156 | 157 | [CODEOWNERS]: contributors/guide/owners.md 158 | [PROJECTS]: projects/ 159 | [two-factor authentication]: https://help.github.com/articles/about-two-factor-authentication 160 | -------------------------------------------------------------------------------- /projects-list.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Chef Software Projects 5 | 6 | Software projects at Chef are made up many libraries and sub-projects managed by Chef. There are currently over 500 such software repositories, which together make up our core projects: 7 | 8 | - [Chef Infra Client](https://github.com/chef) - A systems integration framework, built to bring the benefits of configuration management to your entire infrastructure. 9 | - [Chef Infra Server](https://github.com/chef) - The hub for configuration data; storing cookbooks, node policies and metadata of managed nodes. 10 | - [Chef InSpec](https://github.com/inspec/inspec) - A testing framework for infrastructure with a human- and machine-readable language for specifying compliance, security and policy requirements. 11 | - [Chef Habitat](https://github.com/habitat-sh) - Software that creates platform-independent build artifacts and provides built-in deployment and management capabilities. 12 | - [Chef Automate](https://github.com/chef/automate) - Automate gives users actionable data about their applications and infrastructure automation as well as the tools to take action based on that data. 13 | - [Chef Workstation](https://github.com/chef/chef-workstation) - Everything you need to get started using Chef products on Windows, Mac and Linux. 14 | 15 | ## Ecosystem Projects 16 | 17 | There are many Chef ecosystem projects, which are sponsored by Chef Software, but not directly managed by the company. As these are not official Chef Software projects, they will have their own GitHub organizations as well as contribution processes. See the individual projects for more information on getting involved. 18 | 19 | - [Test Kitchen](https://github.com/test-kitchen/) 20 | - [ChefSpec/Fauxhai](https://github.com/chefspec/chefspec) 21 | - [Berkshelf](https://github.com/berkshelf/) 22 | -------------------------------------------------------------------------------- /projects/builder.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Habitat Builder 5 | 6 | Includes all code for the Habitat Depot and Builder. 7 | 8 | [**Slack Channel**](https://habitat-sh.slack.com/messages/general) 9 | 10 | **Triage Schedule**: Weekly, Tuesdays 11am PST 11 | 12 | ## Project Members 13 | 14 | ### Project Owners 15 | 16 | ### Project Approvers 17 | 18 | Christopher Maier 19 | 20 | - Github: [christophermaier](https://github.com/christophermaier) 21 | 22 | Jeremy Miller 23 | 24 | - Github: [jeremymv2](https://github.com/jeremymv2) 25 | 26 | Mark Anderson 27 | 28 | - Github: [markan](https://github.com/markan) 29 | 30 | ### Project Reviewers 31 | 32 | Kimberley Garmoe 33 | 34 | - Github: [kagarmoe](https://github.com/kagarmoe) 35 | 36 | Mary Jinglewski 37 | 38 | - Github: [mjingle](https://github.com/mjingle) 39 | 40 | Matt Wrock 41 | 42 | - Github: [mwrock](https://github.com/mwrock) 43 | 44 | ## Project Alums 45 | 46 | Ian Henry 47 | 48 | - Github: [eeyun](https://github.com/eeyun) 49 | 50 | Salim Alam 51 | 52 | - Github: [chefsalim](https://github.com/chefsalim) 53 | 54 | Josh Black 55 | 56 | - Github: [raskchanky](https://github.com/raskchanky) 57 | 58 | Liz Chen 59 | 60 | - Github: [apriofrost](https://github.com/apriofrost) 61 | 62 | Scott Macfarlane 63 | 64 | - Github: [smacfarlane](https://github.com/smacfarlane) 65 | 66 | ## Project Repositories 67 | 68 | - [builder](https://github.com/habitat-sh/builder) 69 | - [on-prem-builder](https://github.com/habitat-sh/on-prem-builder) 70 | -------------------------------------------------------------------------------- /projects/chef-automate.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Chef Automate Project 5 | 6 | The Chef Automate project includes Chef Automate and all related 7 | deployment topologies supported by `chef-automate deploy`. 8 | 9 | **Slack Channel** #automate-dev 10 | 11 | **Triage Schedule**: TBD 12 | 13 | ## Project Members 14 | 15 | ### Project Owners 16 | 17 | - Vivek Kumar 18 | - Github:[vivekvardwaz](https://github.com/vivekvardwaz) 19 | - Kallol Roy 20 | - Github: [kalroy](https://github.com/kalroy) 21 | - Punit Mundra 22 | - Github: [punitmundra](https://github.com/punitmundra) 23 | - Vivek Yadav 24 | - Github: [vivek-yadav](https://github.com/vivek-yadav) 25 | - Ankur Mundra 26 | - Github: [AnkurMundhra](https://github.com/AnkurMundhra) 27 | - Karunesh Kumar 28 | - Github: [karunesh-tech](https://github.com/karunesh-tech) 29 | - Durga Sarat Chandra Maddu 30 | - Github: [Dmaddu](https://github.com/Dmaddu) 31 | 32 | ### Project Approvers 33 | 34 | - Vivek Shankar 35 | - Github: [vivekshankar1](https://github.com/vivekshankar1) 36 | - Shaik Mudassir 37 | - Github: [shaik80](https://github.com/shaik80) 38 | - Rick Marry 39 | - GitHub: [rickmarry](https://github.com/rickmarry) 40 | - Vinay Sharma 41 | - Github: [vinay033](https://github.com/vinay033) 42 | - Abdul Azeez 43 | - Github: [Abdul-Az](https://github.com/Abdul-Az) 44 | - Pappu Kumar 45 | - Github: [dave-augustus](https://github.com/dave-augustus) 46 | - Yashvi Jain 47 | - Github: [YashviJain01](https://github.com/YashviJain01) 48 | 49 | ### Project Reviewers 50 | 51 | ## Project Repositories 52 | 53 | - [automate](https://github.com/chef/automate) 54 | 55 | ## Project Alums 56 | 57 | - Seth Chisamore 58 | - GitHub: [schisamo](https://github.com/schisamo) 59 | - Tom Duffield 60 | - GitHub: [tduffield](https://github.com/tduffield) 61 | - Stephan Renatus 62 | - GitHub: [srenatus](https://github.com/srenatus) 63 | - Brenna Hewer-Darroch 64 | - GitHub: [bcmdarroch](https://github.com/bcmdarroch) 65 | - Ryan Cragun 66 | - GitHub: [ryancragun](https://github.com/ryancragun) 67 | - susan evans 68 | - GitHub: [susanev](https://github.com/susanev) 69 | - Scott Christopherson 70 | - GitHub: [scottopherson](https://github.com/scottopherson) 71 | - Stephen Delano 72 | - GitHub: [sdelano](https://github.com/sdelano) 73 | - Slack: @stephen 74 | - Victoria Jeffrey 75 | - GitHub: [vjeffrey](https://github.com/vjeffrey) 76 | - Slack: @vj 77 | - Pete Higgins 78 | - GitHub: [phiggins](https://github.com/phiggins) 79 | - Salim Afiune 80 | - GitHub: [afiune](https://github.com/afiune) 81 | - Maggie Walker 82 | - GitHub: [magwalk](https://github.com/magwalk) 83 | - Tyler Cloke 84 | - GitHub: [tylercloke](https://github.com/tylercloke) 85 | - Steven Danna 86 | - GitHub: [stevendanna](https://github.com/stevendanna) 87 | - Lance Finfrock 88 | - GitHub: [lancefw](https://github.com/lancefw) 89 | - Blake Johnson 90 | - GitHub: [blakestier](https://github.com/blakestier) 91 | - Yvonne Lam 92 | - GitHub: [yzl](https://github.com/yzl) 93 | - Mary Jinglewski 94 | - GitHub: [mjingle](https://github.com/mjingle) 95 | - Alex Pop 96 | - Github: [alexpop](https://github.com/alexpop) 97 | - Tara Black 98 | - GitHub: [tarablack01](https://github.com/tarablack01) 99 | - Daniel DeLeo 100 | - GitHub: [danielsdeleo](https://github.com/danielsdeleo) 101 | - Shadae Holmes 102 | - GitHub: [shadae](https://github.com/shadae) 103 | - Kyleen MacGugan 104 | - GitHub: [kmacgugan](https://github.com/kmacgugan) 105 | - Jay Mundrawala 106 | - GitHub: [jaym](https://github.com/jaym) 107 | - Michael Sorens 108 | - GitHub: [msorens](https://github.com/msorens) 109 | -------------------------------------------------------------------------------- /projects/chef-desktop.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Chef Desktop team 5 | 6 | The Chef Desktop team is responsible for desktop related projects and repositories. 7 | 8 | **Slack Channel**: #chef-desktop-community 9 | 10 | **Triage Schedule**: TBD 11 | 12 | ## Project Members 13 | 14 | ### Project Owners 15 | 16 | - Chaithra Mailankody 17 | 18 | * Github: [cmailank](https://github.com/cmailank) 19 | * Slack: @Chaithra Mailankody 20 | 21 | - Nischal Reddy 22 | 23 | * Github: [nischalsrinivas](https://github.com/nischalsrinivas) 24 | * Slack: @Nischal 25 | 26 | - Sabyasachi Ghosh 27 | 28 | * Github:[saghoshprogress](https://github.com/saghoshprogress) 29 | * Slack: @Sabyasachi Ghosh 30 | 31 | ### Project Approvers 32 | 33 | - Amulya Tomer 34 | 35 | * Github: [logwolvy](https://github.com/logwolvy) 36 | * Slack: @Amulya 37 | 38 | - Rishi Chawda 39 | 40 | * Github: [rishichawda](https://github.com/rishichawda) 41 | * Slack: @rishi 42 | 43 | - Sabyasachi Ghosh 44 | 45 | * Github:[saghoshprogress](https://github.com/saghoshprogress) 46 | * Slack: @Sabyasachi Ghosh 47 | 48 | ### Project Reviewers 49 | 50 | - Amulya Tomer 51 | 52 | * Github: [logwolvy](https://github.com/logwolvy) 53 | * Slack: @Amulya 54 | 55 | - Rishi Chawda 56 | 57 | * Github: [rishichawda](https://github.com/rishichawda) 58 | * Slack: @rishi 59 | 60 | - Sabyasachi Ghosh 61 | 62 | * Github:[saghoshprogress](https://github.com/saghoshprogress) 63 | * Slack: @Sabyasachi Ghosh 64 | 65 | ## Project Repositories 66 | 67 | - [chef-desktop-quick-setup](https://github.com/chef/chef-desktop-quick-setup) 68 | - [corefoundation](https://github.com/chef/corefoundation) 69 | 70 | ## Project Alums 71 | 72 | - Avinash Raghuthu 73 | 74 | * Github: [avinashraghuthu](https://github.com/avinashraghuthu) 75 | * Slack: @Avinash Raghuthu 76 | 77 | - Vivek Kumar 78 | 79 | * Github:[vivekvardwaz](https://github.com/vivekvardwaz) 80 | * Slack: @vivek kumar 81 | -------------------------------------------------------------------------------- /projects/chef-infra-server.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Chef Infra Server Team 5 | 6 | The Chef Infra Server team is responsible for common libraries and applications used to support Chef Infra Server. 7 | 8 | **Slack Channel**: #chef-server 9 | 10 | **Triage Schedule**: TBD 11 | 12 | ## Project Members 13 | 14 | ### Project Owners 15 | 16 | Prajakta Purohit 17 | 18 | - Github: [PrajaktaPurohit](https://github.com/PrajaktaPurohit) 19 | - Slack: @prajakta 20 | 21 | Sudharshan Kaushikk 22 | 23 | - Github: [skkprogress](https://github.com/skkprogress) 24 | - Slack: @skkprogress 25 | 26 | Lincoln Baker 27 | 28 | - Github: [lbakerchef](https://github.com/lbakerchef) 29 | - Slack: @Lincoln Baker 30 | 31 | Vinay Satish 32 | 33 | - Github: [vinay-satish](https://github.com/vinay-satish) 34 | - Slack: @Vinay Satish 35 | 36 | Jan Shahid Shaik 37 | 38 | - Github: [jashaik](https://github.com/jashaik) 39 | - Slack: Jan Shahid Shaik 40 | 41 | ### Project Approvers 42 | 43 | Marc Paradise 44 | 45 | - Github: [marcparadise](https://github.com/marcparadise) 46 | - Slack: @mparadise 47 | 48 | Lincoln Baker 49 | 50 | - Github: [lbakerchef](https://github.com/lbakerchef) 51 | - Slack: @Lincoln Baker 52 | 53 | ### Project Reviewers 54 | 55 | ### Project Alums 56 | 57 | Tim Smith 58 | 59 | - Github: [tas50](https://github.com/tas50) 60 | - Slack: @tas50 61 | 62 | Bryan McLellan 63 | 64 | - Github: [btm](https://github.com/btm) 65 | - Slack: @btm 66 | 67 | Tyler Cloke 68 | 69 | - Github: [tylercloke](https://github.com/tylercloke) 70 | - Slack: @tylercloke 71 | 72 | Ryan Cragun 73 | 74 | - Github: [ryancragun](https://github.com/ryancragun) 75 | 76 | Stephen Delano 77 | 78 | - Github: [sdelano](https://github.com/sdelano) 79 | - Slack: @stephen 80 | 81 | Mark Anderson 82 | 83 | - Github: [markan](https://github.com/markan) 84 | - Slack: @mark 85 | 86 | Stephan Renatus 87 | 88 | - Github: [srenatus](https://github.com/srenatus) 89 | 90 | Steven Danna 91 | 92 | - Github: [stevendanna](https://github.com/stevendanna) 93 | - Slack: @ssd 94 | 95 | Nolan Davidson 96 | 97 | - Github: [nsdavidson](https://github.com/nsdavidson) 98 | 99 | Oliver Ferrigni 100 | 101 | - Github: [oferrigni](https://github.com/oferrigni) 102 | 103 | ## Major Projects 104 | 105 | [chef-server](https://github.com/chef/chef-server) 106 | 107 | ## Project Repositories 108 | 109 | - [bcrypt](https://github.com/chef/erlang-bcrypt) 110 | - [chef_authn](https://github.com/chef/chef_authn) 111 | - [chef_req](https://github.com/chef/chef_req) 112 | - [chef_secrets](https://github.com/chef/chef_secrets) 113 | - [efast_xs](https://github.com/chef/efast_xs) 114 | - [epgsql](https://github.com/chef/epgsql-1) 115 | - [erlzmq2](https://github.com/chef/erlzmq2) 116 | - [fixie](https://github.com/chef/fixie) 117 | - [folsom_graphite](https://github.com/chef/folsom_graphite) 118 | - [ibrowse](https://github.com/chef/ibrowse) 119 | - [mini_s3](https://github.com/chef/mini_s3) 120 | - [mixer](https://github.com/chef/mixer) 121 | - [moser](https://github.com/chef/moser) 122 | - [opscoderl_folsom](https://github.com/chef/opscoderl_folsom) 123 | - [opscoderl_httpc](https://github.com/chef/opscoderl_httpc) 124 | - [opscoderl_wm](https://github.com/chef/opscoderl_wm) 125 | - [sqerl](https://github.com/chef/sqerl) 126 | - [stats_hero](https://github.com/chef/stats_hero) 127 | - [knife-ec-backup](https://github.com/chef/knife-ec-backup) -------------------------------------------------------------------------------- /projects/chef-infra.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Chef Infra Project 5 | 6 | The Chef Infra project includes Chef Infra Client and all directly related projects. 7 | 8 | **Slack Channel** #chef-infra-dev 9 | 10 | **Triage Schedule**: Mondays at 10:00am PST 11 | 12 | ## Project Members 13 | 14 | ### Project Owners 15 | 16 | Lamont Granquist 17 | 18 | - Github: [lamont-granquist](https://github.com/lamont-granquist) 19 | - Slack: @lamont 20 | 21 | Phil Dibowitz 22 | 23 | - Github: [jaymzh](http://github.com/jaymzh) 24 | - Slack: @phil 25 | 26 | Prajakta Purohit 27 | 28 | - Github: [PrajaktaPurohit](https://github.com/PrajaktaPurohit) 29 | - Slack: @prajakta 30 | 31 | Sudharshan Kaushikk 32 | 33 | - Github: [skkprogress](https://github.com/skkprogress) 34 | - Slack: @skkprogress 35 | 36 | ### Project Approvers 37 | 38 | Marc Paradise 39 | 40 | - Github: marcparadise 41 | - Slack: @mparadise 42 | 43 | Matt Wrock 44 | 45 | - Github: [mwrock](https://github.com/mwrock) 46 | - Slack: @mwrockx 47 | 48 | ### Project Reviewers 49 | 50 | John McCrae 51 | 52 | - Github: [johnmccrae](http://github.com/johnmccrae) 53 | - Slack: @John McCrae 54 | 55 | Neha Pansare 56 | 57 | - Github: [neha-p6](https://github.com/neha-p6) 58 | - Slack: @neha 59 | 60 | ## Project Repositories 61 | 62 | - [chef](https://github.com/chef/chef) 63 | - [cheffish](https://github.com/chef/cheffish) 64 | - [cookstyle](https://github.com/chef/cookstyle) 65 | - [cookstylist](https://github.com/chef/cookstylist) 66 | - [ohai](https://github.com/chef/ohai) 67 | - [vscode-chef](https://github.com/chef/vscode-chef) 68 | 69 | Plus everything listed in: [community_pr_review_checklist](https://github.com/chef/chef/blob/main/docs/dev/how_to/community_pr_review_checklist.md). 70 | 71 | ## Project Alums 72 | 73 | Tim Smith 74 | 75 | - Github: [tas50](https://github.com/tas50) 76 | - Slack: @tas50 77 | 78 | Bryan McLellan 79 | 80 | - Github: [btm](https://github.com/btm) 81 | - Slack: @btm 82 | 83 | Robb Kidd 84 | 85 | - Github: [robbkidd](https://github.com/robbkidd) 86 | - Slack: @robbkidd 87 | 88 | Adam Jacob 89 | 90 | - Github: [adamhjk](https://github.com/adamhjk) 91 | - Slack: @adam 92 | 93 | Adam Leff 94 | 95 | - Github: [adamleff]((https://github.com/adamleff)) 96 | - Slack: @adamleff 97 | 98 | AJ Christensen 99 | 100 | - Github: [fujin](https://github.com/fujin) 101 | - Slack: @fujin 102 | 103 | Amy Aronsohn 104 | 105 | - Github: [OnlyHaveCans](https://github.com/OnlyHaveCans) 106 | - Slack: @onlyhavecans 107 | 108 | Daniel DeLeo 109 | 110 | - Github: [danielsdeleo](https://github.com/danielsdeleo) 111 | - Slack: @kallistec 112 | 113 | Jay Mundrawala 114 | 115 | - Github: [jaym](https://github.com/jaym) 116 | - Slack: @jaym 117 | 118 | John Keiser 119 | 120 | - Github: [jkeiser](https://github.com/jkeiser) 121 | - Slack: @jkeiser 122 | 123 | Jon Cowie 124 | 125 | - Github: [jonlives](https://github.com/jonlives) 126 | - Slack: @jonlives 127 | 128 | Josh Hudson 129 | 130 | - Github: [itmustbejj](https://github.com/itmustbejj) 131 | - Slack: @jhudson 132 | 133 | Joshua Timberman 134 | 135 | - Github: [jtimberman](https://github.com/jtimberman) 136 | - Slack: @jtimberman 137 | 138 | Kartik Cating-Subramanian 139 | 140 | - Github: [ksubrama](https://github.com/ksubrama) 141 | - Slack: @ksubrama 142 | 143 | Mark Anderson 144 | 145 | - Github: [markan](https://github.com/markan) 146 | - Slack: @mark 147 | 148 | Mike Dodge 149 | 150 | - Github: [mikedodge04](https://github.com/mikedodge04) 151 | - Slack: @mikedodge04 152 | 153 | Noah Kantrowitz 154 | 155 | - Github: [coderanger](https://github.com/coderanger) 156 | - Slack: @coderanger 157 | 158 | Ranjib Dey 159 | 160 | - Github: [ranjib](https://github.com/ranjib) 161 | - Slack: @cha0s 162 | 163 | Ryan Davis 164 | 165 | - Github: [zenspider](https://github.com/zenspider) 166 | - Slack: @Ryan Davis 167 | 168 | Salim Alam 169 | 170 | - Github: [chefsalim](https://github.com/chefsalim) 171 | - Slack: @Salim Alam 172 | 173 | Seth Thomas 174 | 175 | - Github: [cheeseplus](https://github.com/cheeseplus) 176 | - Slack: @cheeseplus 177 | 178 | Steven Murawksi 179 | 180 | - Github: [smurawski](https://github.com/smurawski) 181 | - Slack: @stevenmurawski 182 | 183 | Steven Danna 184 | 185 | - Github: [stevendanna](https://github.com/stevendanna) 186 | - Slack: @ssd 187 | 188 | Stuart Preston 189 | 190 | - Github: [stuartpreston](https://github.com/stuartpreston) 191 | - Slack: @stuart 192 | 193 | Thom May 194 | 195 | - Github: [thommay](https://github.com/thommay) 196 | - Slack: @thom 197 | 198 | Tom Duffield 199 | 200 | - Github: [tduffield](https://github.com/tduffield) 201 | - Slack: @tduffield 202 | 203 | Tyler Ball 204 | 205 | - Github: [tyler-ball](https://github.com/tyler-ball) 206 | - Slack: @tball 207 | 208 | Pete Higgins 209 | 210 | - Github: [phiggins](http://github.com/phiggins) 211 | - Slack: @pete 212 | 213 | Rahul Goel 214 | 215 | - Github: [rahulgoel1](https://github.com/rahulgoel1) 216 | - Slack: @Rahul.Goel 217 | -------------------------------------------------------------------------------- /projects/chef-workstation.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Chef Workstation Project 5 | 6 | The Chef Workstation project includes Chef Workstation and all related repositories. 7 | 8 | **Slack Channel** #chef-workstation-dev 9 | 10 | **Triage Schedule**: Alternate Tuesday at 8:30am Pacific Time 11 | 12 | ## Project Members 13 | 14 | ### Project Owners 15 | 16 | Marc Paradise 17 | 18 | - Github: [marcparadise](https://github.com/marcparadise) 19 | - Slack: @mparadise 20 | 21 | Vikram Karve 22 | 23 | - Github: [vkarve-chef](https://github.com/vkarve-chef) 24 | - Slack: @Vikram Karve 25 | 26 | Nikhil Gupta 27 | 28 | - Github: [nikhil2611](https://github.com/nikhil2611) 29 | - Slack: @Nikhil Gupta 30 | 31 | Kasif Adnan 32 | 33 | - Github: [kasif-adnan](https://github.com/kasif-adnan) 34 | - Slack: @Kasif Adnan 35 | 36 | ### Project Approvers 37 | 38 | Sudharshan Kaushikk 39 | 40 | - Github: [skkprogress](https://github.com/skkprogress) 41 | - Slack: @skkprogress 42 | 43 | Pranay Singh 44 | 45 | - Github: [i5pranay93](https://github.com/i5pranay93) 46 | - Slack: @Pranay Singh 47 | 48 | Ashique Saidalavi 49 | 50 | - Github: [ashiqueps](https://github.com/ashiqueps) 51 | - Slack: @Ashique Saidalavi 52 | 53 | Sachin Jain 54 | 55 | - Github: [sanjain-progress](https://github.com/sanjain-progress) 56 | - Slack: @Sachin Jain 57 | 58 | Nitin Sanghi 59 | 60 | - Github: [sanghinitin](https://github.com/sanghinitin) 61 | - Slack: @Nitin Sanghi 62 | 63 | ### Project Reviewers 64 | 65 | ### Project Alums 66 | 67 | Tim Smith 68 | 69 | - Github: [tas50](https://github.com/tas50) 70 | - Slack: @tas50 71 | 72 | Snehal Dwivedi 73 | 74 | - Github: [snehaldwivedi](https://github.com/snehaldwivedi) 75 | - Slack: @Snehal Dwivedi 76 | 77 | Smisha M 78 | 79 | - Github: [SmishaM](https://github.com/SmishaM) 80 | - Slack: @SmishaM 81 | 82 | Mudassar Shafique 83 | 84 | - Github: [mudash](https://github.com/mudash) 85 | - Slack: @mshafique 86 | 87 | John Snow 88 | 89 | - Github: [TheLunaticScripter](https://github.com/TheLunaticScripter) 90 | - Slack: @johnshow 91 | 92 | Clinton Wolfe 93 | 94 | - Github: [clintoncwolfe](https://github.com/clintoncwolfe) 95 | - Slack: @cwolfe 96 | 97 | Jon Morrow 98 | 99 | - Github: [jonsmorrow](https://github.com/jonsmorrow) 100 | - Slack: @Jon Morrow 101 | 102 | Mike Krasnow 103 | 104 | - Github: [krasnow](https://github.com/krasnow) 105 | - Slack: @krasnow 106 | 107 | Tyler Ball 108 | 109 | - Github: [tyler-ball](https://github.com/tyler-ball) 110 | - Slack: @tball 111 | 112 | Salim Afiune 113 | 114 | - Github: [afiune](https://github.com/afiune) 115 | - Slack: @afiune 116 | 117 | Robb Kidd 118 | 119 | - Github: [robbkidd](https://github.com/robbkidd) 120 | - Slack: @robbkidd 121 | 122 | ### Project Repositories 123 | 124 | - [chef-analyze](https://github.com/chef/chef-analyze) 125 | - [chef-apply](https://github.com/chef/chef-apply) 126 | - [chef-cli](https://github.com/chef/chef-cli) 127 | - [chef-vault](https://github.com/chef/chef-vault) 128 | - [chef-workstation-app](https://github.com/chef/chef-workstation-app) 129 | - [chef-workstation](https://github.com/chef/chef-workstation) 130 | - [cookbook-omnifetch](https://github.com/chef/cookbook-omnifetch) 131 | - [go-chef](https://github.com/chef/go-chef) 132 | - [go-libs](https://github.com/chef/go-libs) 133 | - [knife-azure](https://github.com/chef/knife-azure) 134 | - [knife-cloud](https://github.com/chef/knife-cloud) 135 | - [knife-ec2](https://github.com/chef/knife-ec2) 136 | - [knife-google](https://github.com/chef/knife-google) 137 | - [knife-opc](https://github.com/chef/knife-opc) 138 | - [knife-openstack](https://github.com/chef/knife-openstack) 139 | - [knife-push](https://github.com/chef/knife-push) 140 | - [knife-tidy](https://github.com/chef/knife-tidy) 141 | - [knife-vcenter](https://github.com/chef/knife-vcenter) 142 | - [knife-vrealize](https://github.com/chef/knife-vrealize) 143 | - [knife-vsphere](https://github.com/chef/knife-vsphere) 144 | - [knife-windows](https://github.com/chef/knife-windows) 145 | -------------------------------------------------------------------------------- /projects/habitat-core-plans.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Habitat Core Plans 5 | 6 | Habitat Core Plans are currently transitioning to the Content Team so the below is likely to evolve. 7 | 8 | **Slack Channel** 9 | 10 | **Triage Schedule**: Weekly, Tuesdays 11am PST (Currently triaged as part of Habitat teams triage) 11 | 12 | ## Project Members 13 | 14 | ### Project Owners 15 | 16 | [Habitat Team] (habitat.md) 17 | 18 | Gavin Didrichsen 19 | 20 | - Github: [gavindidrichsen](https://github.com/gavindidrichsen) 21 | - Slack: @gavindidrichsen 22 | 23 | Steven Marshall 24 | 25 | - Github: [MindNumbing](https://github.com/MindNumbing) 26 | - Slack: @smarshall 27 | 28 | Russell Seymour 29 | 30 | - Github: [russellseymour](https://github.com/russellseymour) 31 | - Slack: @Russell 32 | 33 | ### Project Approvers 34 | 35 | Gavin Didrichsen 36 | 37 | - Github: [gavindidrichsen](https://github.com/gavindidrichsen) 38 | - Slack: @gavindidrichsen 39 | 40 | Steven Marshall 41 | 42 | - Github: [MindNumbing](https://github.com/MindNumbing) 43 | - Slack: @smarshall 44 | 45 | Russell Seymour 46 | 47 | - Github: [russellseymour](https://github.com/russellseymour) 48 | - Slack: @Russell 49 | 50 | ### Project Reviewers 51 | 52 | ### Project Alums 53 | 54 | Davy McAleer 55 | 56 | - Github: [davymcaleer](https://github.com/davymcaleer) 57 | - Slack: @davy 58 | 59 | Stuart Paterson 60 | 61 | - Github: [skpaterson](https://github.com/skpaterson) 62 | - Slack: @skpaterson 63 | 64 | ## Project Repositories 65 | 66 | - [core-plans](https://github.com/habitat-sh/core-plans) 67 | - [base-plans](https://github.com/chef-base-plans) 68 | -------------------------------------------------------------------------------- /projects/habitat.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Habitat 5 | 6 | Includes all code for the Habitat Supervisor, CLI, Studio, exporters, etc. 7 | 8 | **Slack Channel** TBD 9 | 10 | **Triage Schedule**: TBD 11 | 12 | ## Project Members 13 | 14 | ### Project Owners 15 | 16 | Christopher Maier 17 | 18 | - Github: [christophermaier](https://github.com/christophermaier) 19 | 20 | ### Project Approvers 21 | 22 | Jeremy Miller 23 | 24 | - Github: [jeremymv2](https://github.com/jeremymv2) 25 | 26 | Mark Anderson 27 | 28 | - Github: [markan](https://github.com/markan) 29 | 30 | Matt Wrock 31 | 32 | - Github: [mwrock](https://github.com/mwrock) 33 | 34 | ### Project Reviewers 35 | 36 | Kimberley Garmoe 37 | 38 | - Github: [kagarmoe](https://github.com/kagarmoe) 39 | 40 | Liz Chen 41 | 42 | - Github: [apriofrost](https://github.com/apriofrost) 43 | 44 | Mary Jinglewski 45 | 46 | - Github: [mjingle](https://github.com/mjingle) 47 | 48 | ### Project Alums 49 | 50 | Salim Alam 51 | 52 | - Github: [chefsalim](https://github.com/chefsalim) 53 | 54 | Ian Henry 55 | 56 | - Github: [eeyun](https://github.com/eeyun) 57 | 58 | Josh Black 59 | 60 | - Github: [raskchanky](https://github.com/raskchanky) 61 | 62 | ## Project Repositories 63 | 64 | - [habitat](https://github.com/habitat-sh/habitat) 65 | - [homebrew-habitat](https://github.com/habitat-sh/homebrew-habitat) 66 | -------------------------------------------------------------------------------- /projects/infra-packages-team.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Infra Packages Team 5 | 6 | The Infra Packages Team team is responsible for components in the Chef Infra stack that produce builds including Omnibus and Omnibus software definitions. 7 | 8 | **Slack Channel**: TBD 9 | 10 | **Triage Schedule**: TBD 11 | 12 | ## Project Members 13 | 14 | ### Project Owners 15 | 16 | Jeremiah Snapp 17 | 18 | - Github: [jeremiahsnapp](https://github.com/jeremiahsnapp) 19 | - Slack: jsnapp 20 | 21 | ### Project Reviewers 22 | 23 | Poornima Suresh 24 | 25 | - Github: [poorndm](https://github.com/poorndm) 26 | - Slack: TBD 27 | 28 | Jayashri Garud 29 | 30 | - Github: [jayashrig158](https://github.com/jayashrig158) 31 | - Slack: TBD 32 | 33 | Swati Keshari 34 | 35 | - Github: [skeshari12](https://github.com/skeshari12) 36 | - Slack: TBD 37 | 38 | ## Project Repositories 39 | 40 | - [omnibus](https://github.com/chef/omnibus) 41 | - [omnibus-software](https://github.com/chef/omnibus-software) 42 | - [omnibus-toolchain](https://github.com/chef/omnibus-toolchain) 43 | -------------------------------------------------------------------------------- /projects/inspec-cloud.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # InSpec Cloud Resource Packs 5 | 6 | This includes the InSpec resource packs for AWS, GCP and Azure. 7 | 8 | ## Slack Channels 9 | 10 | - 11 | - 12 | - 13 | 14 | **Triage Schedule**: 15 | 16 | NA 17 | 18 | ## Project Members 19 | 20 | ### Project Owners 21 | 22 | UdayKumar Khatua 23 | 24 | - Github: [udaykhatua](https://github.com/udaykhatua) 25 | - Slack: @UdayKumar Khatua 26 | 27 | ### Project Alums 28 | 29 | Stuart Paterson 30 | 31 | - Github: [skpaterson](https://github.com/skpaterson) 32 | - Slack: @skpaterson 33 | 34 | Davy McAleer 35 | 36 | - Github: [davymcaleer](https://github.com/davymcaleer) 37 | - Slack: @davy 38 | 39 | ### Project Approvers 40 | 41 | InSpec Cloud Resource Pack Maintainers 42 | 43 | - Github: [inspec-cloud-devs](https://github.com/orgs/inspec/teams/inspec-cloud-devs) 44 | 45 | ### Project Reviewers 46 | 47 | ## Project Repositories 48 | 49 | - [inspec-aws](https://github.com/inspec/inspec-aws) 50 | - [inspec-azure](https://github.com/inspec/inspec-azure) 51 | - [inspec-gcp](https://github.com/inspec/inspec-gcp) 52 | -------------------------------------------------------------------------------- /projects/inspec.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # InSpec Project 5 | 6 | The InSpec project includes InSpec as well as several resource packs and plugins. 7 | 8 | **Slack Channel** TBD 9 | 10 | **Triage Schedule**: TBD 11 | 12 | ## Project Members 13 | 14 | ### Project Owners 15 | 16 | Clinton Wolfe 17 | 18 | - Github: [clintoncwolfe](https://github.com/clintoncwolfe) 19 | - Slack: @cwolfe 20 | 21 | ### Project Approvers 22 | 23 | ### Project Reviewers 24 | 25 | ### Project Alums 26 | 27 | Nick Schwaderer 28 | 29 | - Github: [Schwad](https://github.com/Schwad) 30 | - Slack: @schwad 31 | 32 | Ryan Davis 33 | 34 | - Github: [zenspider](https://github.com/zenspider) 35 | - Slack: @rdavis 36 | 37 | James Stocks 38 | 39 | - Github: [james-stocks](https://github.com/james-stocks) 40 | - Slack: @Stocksy 41 | 42 | ## Project Repositories 43 | 44 | - [inspec](https://github.com/inspec/inspec) 45 | - [inspec-digitalocean](https://github.com/inspec/inspec-digitalocean) 46 | - [inspec-habitat](https://github.com/inspec/inspec-habitat) 47 | - [inspec-oneview](https://github.com/inspec/inspec-habitat) 48 | - [inspec-vmware](https://github.com/inspec/inspec-vmware) 49 | - [kitchen-inspec](https://github.com/inspec/kitchen-inspec) 50 | - [train-aws](https://github.com/inspec/train-aws) 51 | - [train-habitat](https://github.com/inspec/train-habitat) 52 | - [train-digitalocean](https://github.com/inspec/train-digitalocean) 53 | -------------------------------------------------------------------------------- /projects/supermarket.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Supermarket Project 5 | 6 | The Supermarket project includes Supermarket and all related repositories. 7 | 8 | **Slack Channel** #supermarket 9 | 10 | **Triage Schedule**: TBD 11 | 12 | ## Project Members 13 | 14 | ### Project Owners 15 | 16 | Sabyasachi Ghosh 17 | 18 | - Github: [saghoshprogress](https://github.com/saghoshprogress) 19 | - Slack: Sabyasachi Ghosh 20 | 21 | ### Project Approvers 22 | 23 | Sudharshan Kaushikk 24 | 25 | - Github: [skkprogress](https://github.com/skkprogress) 26 | - Slack: @skkprogress 27 | 28 | ### Project Reviewers 29 | 30 | Dheeraj Singh Dubey 31 | 32 | - Github: [dheerajd-msys](https://github.com/dheerajd-msys) 33 | - Slack: @ddubey 34 | 35 | Rajesh Paul 36 | 37 | - Github: [RajeshPaul38](https://github.com/RajeshPaul38) 38 | - Slack: Rajesh Paul 39 | 40 | Marc Paradise 41 | 42 | - Github: [marcparadise](https://github.com/marcparadise) 43 | - Slack: @mparadise 44 | 45 | Will Fisher 46 | 47 | - Github: [teknofire](https://github.com/teknofire) 48 | - Slack: @teknofire 49 | 50 | ### Project Alums 51 | 52 | Tim Smith 53 | 54 | - Github: [tas50](https://github.com/tas50) 55 | - Slack: @tas50 56 | 57 | Robb Kidd 58 | 59 | - Github: [robbkidd](https://github.com/robbkidd) 60 | - Slack: @robbkidd 61 | 62 | Tyler Ball 63 | 64 | - Github: [tyler-ball](https://github.com/tyler-ball) 65 | - Slack: @tball 66 | 67 | ## Project Repositories 68 | 69 | - [supermarket](https://github.com/chef/supermarket) 70 | - [supermarket-omnibus-cookbook](https://github.com/chef-cookbooks/supermarket-omnibus-cookbook) -------------------------------------------------------------------------------- /repo-management/README.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Repo Management 5 | 6 | Ready to create a new Chef Open Source Software project? Looking for some guidance on how to manage repositories for existing projects? You have come to the right place! 7 | 8 | ## Project Setup 9 | 10 | For information about how to set up a Chef Open Source project (including required files), check out the [Project Required Setup documentation](project-required-setup.md). 11 | 12 | ## Repo States 13 | 14 | Repos are born and eventually they die. For information about the different states a repo can be in, check out the [Repo States documentation](repo-states.md). 15 | 16 | ## GitHub Labels 17 | 18 | For information about labels for both GitHub Issues and Pull Requests, check out the [Project Labels documentation](github-labels.md). 19 | -------------------------------------------------------------------------------- /repo-management/github-labels.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | Projects in the Chef Community should feel encouraged to use these labels in their GitHub repositories. These labels provide consistency across our community, and you may use any or all of them. You may also create your own, but please try to fit them within our existing categories. 5 | 6 | # Categories 7 | 8 | - `Aspect` - Issues 9 | - `Expeditor` - PRs 10 | - `Platform` - PRs / Issues 11 | - `Size` - PRs 12 | - `Status` - PRs / Issues 13 | - `Triage` - Issues 14 | - `Type` - Issues 15 | 16 | # Labels 17 | 18 | ## Aspect 19 | 20 | Aspects define the characteristics of an issue. 21 | 22 | - `Documentation` - How do we use this project? 23 | - `Integration` - Works correctly with other projects or systems. 24 | - `Packaging` - Distribution of the projects "compiled" artifacts. 25 | - `Performance` - Works without negatively affecting the system running it. 26 | - `Portability` - Does this project work correctly on the specified platform? 27 | - `Security` - Can an unwanted third party affect the stability or look at privileged information? 28 | - `Stability` - Consistent results. 29 | - `Testing` - Does the project have good coverage, and is CI working? 30 | - `UI` - Affects how users interact with the interface of your project, with a focus on interaction and visual design. 31 | - `UX` - Affects how users feel about interacting with your project, with a focus on functionality, ease-of-use, and accessibility. 32 | 33 | ## Expeditor 34 | 35 | If your project is using Expeditor you'll want these labels. 36 | 37 | - `Expeditor: Skip All` - Used to skip all `merge_actions`. 38 | - `Expeditor: Skip Changelog` - Used to skip `built_in:update_changelog`. 39 | - `Expeditor: Skip Habitat` - Used to skip `built_in:trigger_habitat_package_build` 40 | - `Expeditor: Skip Omnibus` - Used to skip `built_in:trigger_omnibus_release_build` 41 | - `Expeditor: Bump Version Minor` - Used by [`github.minor_bump_labels`](https://expeditor.chef.io/docs/reference/built_in/#bump-version) to bump the Minor version number. 42 | - `Expeditor: Bump Version Major` - Used by [`github.major_bump_labels`](https://expeditor.chef.io/docs/reference/built_in/#bump-version) to bump the Major version number. 43 | - `Expeditor: Skip Version Bump` - Used to skip `built_in:bump_version` 44 | 45 | ## Platform 46 | 47 | - `AWS` 48 | - `Azure` 49 | - `Docker` 50 | - `GCP` 51 | - `Linux` 52 | - `macOS` 53 | - `SLES-like` 54 | - `UNIX-like` 55 | - `VMware` 56 | - `Windows` 57 | 58 | ## Priority 59 | 60 | - `Low` 61 | - `Medium` 62 | - `Critical` 63 | 64 | ## Status 65 | 66 | - `Adopted` - An issue that is being worked on. 67 | - `Good First Issue` - An issue that is ideal for a new contributor to the project. 68 | - `Help Wanted` - An issue that has enough details to be started and is ready for a contributor. These will show up on the Jump-In page for company wide first time contributor issues. 69 | - `Incomplete` - A pull request that is not ready to be merged as noted by the author. 70 | - `Untriaged` - An issue that has yet to be triaged. This should be set on all new issues 71 | - `Waiting on Contributor` - An issue or pull request that has unresolved requested actions from the author. 72 | 73 | ## Triage 74 | 75 | - `Declined` - Indicates an issue that can not or will not be resolved. 76 | - `Duplicate` - Indicates an issue is a duplicate of other open issue. 77 | - `Feature Request` - Indicates an issue requesting new functionality. 78 | - `Needs Information` - Indicates an issue needs more information in order to work on it. 79 | - `Not Reproducible` - Indicates an issue can not be reproduced as described. 80 | - `Support` - Indicates an issue that is a support question and will be redirected to other mediums. 81 | 82 | ## Type 83 | 84 | - `Breaking Change` - Changes the way existing features work in a way that affects users. 85 | - `Bug` - Does not work as expected. 86 | - `Chore` - non-critical maintenance of a project 87 | - `Deprecation` - Removal of existing features 88 | - `Design Proposal` - Community survey of a proposal 89 | - `Enhancement` - Adds new functionality. 90 | - `Regression` - It used to work, now it doesn't. 91 | - `Tech Debt` - Refactoring 92 | 93 | ## Automating Label Application 94 | 95 | Currently we utilize [repo_man](https://github.com/thommay/repo_man) to apply labels to individual GitHub repositories or all public repositories in a particular org. See the [chef example config](https://github.com/thommay/repo_man/blob/master/examples/chef.toml) for our current label setup. Repoman will not only add the appropriate labels, but it will also migrate existing labels and remove non-standard labels. 96 | -------------------------------------------------------------------------------- /repo-management/project-required-setup.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Required Project Files / Configuration 5 | 6 | In order to provide community members with everything necessary to succeed in a project, we require a minimum set of files and configuration for each project repository. This provides potential users and contributors with information that they will need to interact with the project, and increases the likelihood of successful project contributions. 7 | 8 | ## GitHub Repo Configuration 9 | 10 | ### Repository Description 11 | 12 | A project should include a useful description that acts as an elevator pitch for potential users that may find the project through search engines. 13 | 14 | ### Repository Topics 15 | 16 | GitHub uses repository topics to aid their search engine. Appropriate topics and keywords for the project should be added to help users find a repository. 17 | 18 | ### Repository Labels 19 | 20 | A project should include [the standard set of labels](github-labels.md) for issues and PRs in GitHub. 21 | 22 | ### Disable Unused Features 23 | 24 | When a new repository is created on GitHub, it is automatically includes the Projects and Wiki features. If you are not going to use these features, please disable them on the repository. 25 | 26 | ### Branch Protection 27 | 28 | Branch protection should be enabled on release branches, such as master, to require status checks and reviews before a change can be merged. 29 | 30 | ### PR Status Check: Developer Certificate of Origin 31 | 32 | All Chef Software Inc. OSS projects use the [developer certificate of origin](/DCO.md) for contributed changes. Commits in a pull request must be signed off by the author(s) to be eligible for merging. [Expeditor](https://expeditor.chef.io/docs/getting-started/) is a bot that [by default, will check the commits](https://expeditor.chef.io/docs/integrations/github/#configuration) on pull requests to Chef Software Inc. OSS project repositories, and is recommended to use. 33 | 34 | ## Files 35 | 36 | See the [oss_project_boilerplate repo](https://github.com/chef/oss_project_boilerplate) for samples of the following files that you can use in your project. 37 | 38 | ### README.md 39 | 40 | A project readme is the first thing a new user or contributor sees when interacting with a Chef Software project. We want to make sure this file is detailed and up to date. It should cover the following things: 41 | 42 | - The project state and response time maximums (see [Project States](repo-states.md) for more information) 43 | - The project's intended use 44 | - Any system or runtime requirements 45 | - Example uses 46 | - Known issues or incompatibilities 47 | - The Chef team responsible for the project 48 | - The project license 49 | - When a product requires a license to run the binary, a link to document explaining Chef's licensing terms, as license on code is different than license on binary. [This document is still to be written.] 50 | 51 | ### LICENSE 52 | 53 | The LICENSE file is an important legal requirement for open source code, and it is also parsed by GitHub for use in various places. Adding a license file allows users to search for projects with a specific license and also adds licensing badges to GitHub repository pages. Unless there is a specific reason all Chef projects should be [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0.html) licensed. 54 | 55 | ### CONTRIBUTING.md 56 | 57 | GitHub prompts new contributors to read a project's CONTRIBUTING.md file if present. Each project should include a file that details the team specific contribution process and links to the [Contributor Guide](../contributors/README.md) in this repository. 58 | 59 | ### CODE_OF_CONDUCT.md 60 | 61 | GitHub displays the Code of Conduct file when a user opens a new PR or Issue. We want to make sure everyone reads and understands our Code of Conduct, so this file needs to be included in every project repository. 62 | 63 | ### TEAMS.md 64 | 65 | The `TEAMS.md` file defines the team responsible for the project repository. This file should exist in the base of the GitHub repository and include a link back to team document in *this* repository. The specific details of the team will be stored in the [central teams directory](../teams) of this repository so that we don't need to replicate information across multiple repositories. 66 | 67 | ### .github/CODEOWNERS 68 | 69 | The GitHub codeowners file is used to auto-assign reviewers to a project. Properly routing new pull requests to the appropriate humans decreases the time it takes to get code reviewed and merged. It also reduces the number of lost pull requests, which helps us engage new contributors and retain them for the future. CODEOWNERS can be set up to assign ownership of certain directories or files to particular teams or individuals. For example, changes to files under `readme/docs` can automatically assign the docs team for review. 70 | 71 | ### .github/ISSUE_TEMPLATE.md 72 | 73 | Issue templates ensure that issues are filed with all the necessary information to make them actionable. GitHub allows you to define multiple templates for different types of issues (bug, proposal, etc.). 74 | 75 | ### .github/PULL_REQUEST_TEMPLATE.md 76 | 77 | Pull Request templates ensure that the users have followed all the necessary steps before submitting a PR. They also give us one last chance to point users to our contributing guides so we can ensure a good experience for first time contributors. 78 | 79 | ## Other Recommendations 80 | 81 | ### Pull Request Reminders 82 | 83 | We find pull request reminders to be a practical mechanism for reminding project members they have open PRs in need of review. Teams should feel free to choose whichever tool for this task that they like. Here are two tools that we recommend: 84 | 85 | - GitHub webhooks with Slack - this tool will update a Slack channel when a new pull request is open (and is highly configurable). 86 | 87 | - [Pull Reminders](https://pullreminders.com/) - this tool will routinely ping reviewers assigned to a pull request until that pull request is either merged or closed. Chef does have a current subscription to this tool. 88 | -------------------------------------------------------------------------------- /repo-management/repo-states.md: -------------------------------------------------------------------------------- 1 | > [!WARNING] 2 | > This page in the Chef Open Source Software Practices repository is currently undergoing content review. 3 | 4 | # Repo States 5 | 6 | A Chef OSS repo can be in one of 4 states 7 | 8 | - Active 9 | - Maintained 10 | - Prototyping 11 | - Deprecated 12 | 13 | ## Active 14 | 15 | Repos in an active state are under active development - including bug fixes, new features, and more. Repos in this active state must have at least two maintainers, who are current employees of Chef Software, Inc. The response time maximum for active projects should ideally be within 7 days. 16 | 17 | ## Maintained 18 | 19 | Repos in a maintained state are maintained where bugs will be fixed, but no new feature work should be expected. Repos in this maintained state must have at least one maintainer, who is a current employee of Chef Software, Inc. The response time maximum for issues or pull requests should be anywhere from 7 days to never. 20 | 21 | ## Prototyping 22 | 23 | Repos in a prototyping state should be considered alpha or beta. These repos will have activity from developers, but are not _maintained_. New feature requests and bug fixes should not be expected until the project moves to the Active state. While developers might be responsive, there is no expected response time maximum for prototypes. 24 | 25 | ## Deprecated 26 | 27 | Repos in a deprecated state are no longer maintained. No new features or bug fixes should be expected. Repos in this state do not have any assigned maintainers. See our [Project EOL Communication](../communication/project-eol.md) for additional information on the deprecation of a project. 28 | 29 | ## What is the Response Time Maximum? 30 | 31 | The Response Time Maximum (RTM) applies to responses from a project member to issues or pull requests. It does not apply to the resolution of an issue or the merging of a pull request. Resolution of an issue or merging of a pull request is highly variable depending on what is involved in them. 32 | 33 | ## Where to Communicate this: 34 | 35 | Both the Project State and Response Time Maximums must be defined in the README of the project. We recommend defining them at the top of the README (right under the title) like this: 36 | 37 | ```markdown 38 | - **[Project State](https://github.com/chef/chef-oss-practices/blob/master/repo-management/repo-states.md): Active** 39 | - **Issues [Response Time Maximum](https://github.com/chef/chef-oss-practices/blob/master/repo-management/repo-states.md): 7 days** 40 | - **Pull Request [Response Time Maximum](https://github.com/chef/chef-oss-practices/blob/master/repo-management/repo-states.md): 7 days** 41 | ``` 42 | --------------------------------------------------------------------------------