Quiz and BadgeLive the contributor experience Make your developer playbook public The developer playbook / style guide / handbook should be somewhere publicly accessible, preferably as a prominent part of the developer-aimed documentation. Work from forks when possible Instead of working from branches on the main repository, it is better for core developers to work from personal forks. Don’t treat core devs as exceptions to filling out templates Many projects use templates for PRs and Issues to help guide contributions. The requirement to fill out these templates should apply to core developers as well as external contributors.Document development of common module types Provide reference material on how each component fits into the bigger picture There should be a public-facing overall architectural view that explains what types of modular components exist and how they are related to each other and how they communicate with each other. Provide a how-to on creating each component type For each type of modular component, there should be a step-by-step description of what methods need to be implemented, etc. If components should be external, provide a mechanism to publicize them There should be a listing of components from external contributors. This might come with a caveat that these are not developed or supported by the core team.Help users and contributors communicate with you Guide users to the correct place for each communication There should be clear documentation of where users should go for each type of communication. Have guidance for filing bug reports When users start a bug report, they should see advice on how to write good bug reports, as well as a checklist of what information is needed (e.g., environment information). Provide a channel for asking for development help There should be a recommended way for outside contributors to ask questions about how best to implement their contributions. Provide a channel for making feature requests There should be a well-defined place to propose new functionality. Provide a channel for filing bug reports You should have a recommended way to report bugs. Provide a channel for asking usage questions Documentation is never perfect, and users will have questions about how to accomplish some taskFiles to include in your repository Select a license for your project A file called LICENSE describing the legal permissions for reuse of the source code. CONTRIBUTING.md A CONTRIBUTING.md file gives an overview of how to contribute to your project. It typically links to other references for various types of contributions. Include a CITATION.cff for your repository A CITATION.cff file describes how to cite the software. This can point to peer-reviewed paper or to another recommended source for the citation.Contributors and permissions (GitHub roles) Organizations should have multiple owners The GitHub organization should have more than one person with “owner” permissions. Use teams to organize permissions GitHub allows you to group people into teams within an organization. Use pre-defined organization roles for core developer permissions Pre-defined organization roles (e.g., “All-repository maintain”) match the permissions for repository roles, but apply to all repositories in an organization. Use repository roles for team permissions on repositories Assigning repository roles (e.g., “Maintain” or “Admin”) to a team gives that team a well-defined set of permissions for a given repository.Contributors and security Use the principle of least privilege Access to repositories should be restricted to what is needed for development of features being contributed. Have a vetting process A process to validate your contributors are who they say they are. Unvetted contributors should require approval to run CI Until a contributor is vetted, their contributions should require manual approval before CI runs. Download Badge