diff --git a/.github/ISSUE_TEMPLATE/BUG_REPORT.yml b/.github/ISSUE_TEMPLATE/BUG_REPORT.yml index 8c41f6d..b5c1fc8 100644 --- a/.github/ISSUE_TEMPLATE/BUG_REPORT.yml +++ b/.github/ISSUE_TEMPLATE/BUG_REPORT.yml @@ -9,6 +9,13 @@ body: attributes: value: | Thanks for taking the time to fill out this bug report! + + To help our team to identify and handle the issue in the best way possible, please: + - Check if it`s really an unreported bug; + - Describes only one bug per issue; + - List all the steps necessary to reproduce the issue. The person reading your bug report should be able to follow these steps to reproduce your issue with minimal effort; + - If it`s related a security bug, please follow the steps described in [SECURITY.md file](https://github.com/ifood/.github/blob/main/SECURITY.md). + - type: textarea id: current-behavior attributes: diff --git a/DEVELOPMENT.md b/DEVELOPMENT.md deleted file mode 100644 index 7ab9c06..0000000 --- a/DEVELOPMENT.md +++ /dev/null @@ -1,80 +0,0 @@ -## Issues - -When opening a new issue, always make sure to fill out the issue template. **This step is very important!** Not doing so may result in your issue not being managed in a timely fashion. Don't take this personally if this happens, and feel free to open a new issue once you've gathered all the information required by the template. - -### Bugs - -We use GitHub Issues for our public bugs. If you would like to report a problem, take a look around and see if someone already opened an issue about it. If you are certain this is a new unreported bug, you can submit a bug report using our bug report template. - -- **One bug per issue:** Please report a single bug per issue. This make easier to assign and follow the correction. -- **Provide reproduction steps:** List all the steps necessary to reproduce the issue. The person reading your bug report should be able to follow these steps to reproduce your issue with minimal effort. - -If you're only fixing a bug, it's fine to submit a pull request right away but we still recommend filing an issue detailing what you're fixing. This is helpful in case we don't accept that specific fix but want to keep track of the issue. - -### Security Bugs - -To safely disclosure, all security issues must be sent by the email security-oss@ifood.com.br. This is required to each report be acknowledged, analyzed and classified by the internal iFood security team, and treated and published in the best way. **Please, do not file public issues.** - -For more information, read our [security document](https://github.com/ifood/.github/blob/main/SECURITY.md). - -### Feature requests - -If you would like to request a new feature or enhancement but are not yet thinking about opening a pull request, you can file an issue with the feature request template. - -## Pull Requests - -This is the principal way that the community will use to share your code with the project, and needs to be described clearly to help the project team review. - -So, it`s required to follow some best practices that all pull requests, to help newer contributors and standardize, giving minimal important information to the reviewer about the code: - -1. **Keep your PR small.** Small pull requests (~300 lines of diff) are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it. -2. **Use descriptive titles.** It is recommended to follow this [commit message style](#commit-messages). -3. **Test your changes.** And describe how to test your pull request. -4. **CLA.** If you haven't already, [sign the CLA](https://github.com/ifood/.github/blob/main/CLA.md). -5. **Related Issue.** All pull requests must have an issue associated, and specified in the message. - -All pull requests should be opened against the `main` branch. - -We have a lot of integration systems that run automated tests to guard against mistakes. The maintainers will also review your code and fix obvious issues for you. These systems' duty is to make you worry as little about the chores as possible. Your code contributions are more important than sticking to any procedures, although completing the checklist will surely save everyone's time. - -### Commit Messages - -All projects follow the conventional commits specification (https://www.conventionalcommits.org/) with some particularities: - -- Text in English. -- The first line must have at most 100 characters. -- Sentences are written in the present imperative form. - -The related issue must be referenced in the footer (optional for non-permanent branches) - -The template will look like this: - -``` -[optional scope]: - -[optional body] - -[optional footer(s)] -``` - -Example: - -``` -fix: Fix code typing error - -Details can be found at ticket - -Refs #133 -``` - -To help the user conform with the pattern, the project should use commitzen and repository server and local hooks. - -### Contributor License Agreement (CLA) - -In order to accept your pull request, we need you to submit a CLA. You only need to do this once, so if you've done this for another iFood open source project, you're good to go. iFood uses the [cla-bot project](https://colineberhardt.github.io/cla-bot/) to check the CLA assignment into all Pull Requests. To sign, the user must go to https://github.com/ifood/clabot-config project, and commit a change adding your GitHub user inside the .clabot file. - -After you have signed the CLA, must add a new PR comment with `@cla-bot check` message, that will trigger the bot and update the PR status. There's no need to open a new PR. - -**CLAs are required for us to merge your pull request.** While we value your effort and are willing to wait for you to come back and address the reviews in case you are unavailable after sending the pull request, pull requests that are ready to merge but have CLA missing and no response from the author **will be closed within two weeks of opening**. If you have further questions about the CLA, please stay in touch with us. - -If it happens that you were unavailable and your PR gets closed, feel free to reopen once it's ready! We are still happy to review it, help you complete it, and eventually merge it. diff --git a/GET_INVOLVED.md b/GET_INVOLVED.md index 75ed074..961734d 100644 --- a/GET_INVOLVED.md +++ b/GET_INVOLVED.md @@ -17,6 +17,40 @@ The [Open Source Guides](https://opensource.guide/) website has a collection of iFood has adopted the [Contributor Covenant](https://www.contributor-covenant.org/) that we expect project participants to adhere to. Please read [the full text](https://github.com/ifood/.github/blob/main/CODE_OF_CONDUCT.md) so that you can understand what actions will and will not be tolerated. + +## Issues + +When opening a new issue, always make sure to fill out the issue template. **This step is very important!** Not doing so may result in your issue not being managed in a timely fashion. Don't take this personally if this happens, and feel free to open a new issue once you've gathered all the information required by the template. + +If you're only fixing a bug, it's fine to submit a pull request right away but we still recommend filing an issue detailing what you're fixing. This is helpful in case we don't accept that specific fix but want to keep track of the issue. + +### Security Bugs + +To safely disclosure, all security issues must be sent by the email security-oss@ifood.com.br. This is required to each report be acknowledged, analyzed and classified by the internal iFood security team, and treated and published in the best way. **Please, do not file public issues.** + +For more information, read our [security document](https://github.com/ifood/.github/blob/main/SECURITY.md). + +## Pull Requests + +This is the principal way that the community will use to share your code with the project, and needs to be described clearly to help the project team review. + +So, it`s required to follow some best practices that all pull requests, to help newer contributors and standardize, giving minimal important information to the reviewer about the code: + +1. **Keep your PR small.** Small pull requests (~300 lines of diff) are much easier to review and more likely to get merged. Make sure the PR does only one thing, and be related to just one issue, otherwise try to split it. +2. **Use descriptive titles.** It`s helps to quickly identify what the PR is about. +3. **Test your changes.** And describe how to test your pull request. +4. **CLA.** If you haven't already, [sign the CLA](https://github.com/ifood/.github/blob/main/CLA.md). + +### Contributor License Agreement (CLA) + +In order to accept your pull request, we need you to submit a CLA. You only need to do this once, so if you've done this for another iFood open source project, you're good to go. iFood uses the [cla-bot project](https://colineberhardt.github.io/cla-bot/) to check the CLA assignment into all Pull Requests. To sign, the user must go to https://github.com/ifood/clabot-config project, and commit a change adding your GitHub user inside the .clabot file. + +After you have signed the CLA, must add a new PR comment with `@cla-bot check` message, that will trigger the bot and update the PR status. There's no need to open a new PR. + +**CLAs are required for us to merge your pull request.** While we value your effort and are willing to wait for you to come back and address the reviews in case you are unavailable after sending the pull request, pull requests that are ready to merge but have CLA missing and no response from the author **will be closed within two weeks of opening**. If you have further questions about the CLA, please stay in touch with us. + +If it happens that you were unavailable and your PR gets closed, feel free to reopen once it's ready! We are still happy to review it, help you complete it, and eventually merge it. + ## Triaging Issues and Pull Requests One great way you can contribute to the project without writing any code is to help triage issues and pull requests as they come in. @@ -25,4 +59,3 @@ One great way you can contribute to the project without writing any code is to h - Suggest labels that can help categorize issues. - Flag issues that are stale or that should be closed. - Ask for test plans and review code. - diff --git a/SECURITY.md b/SECURITY.md index f26a656..e5712ac 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,11 +1,5 @@ # Security Policy -Before a project be opened inside the iFood Open Source community, the internal security team scans the code to identify possible existent vulnerabilities, that need to be corrected until the launch. With the security team giving the "OK", the project will be published in iFood GitHub without the previous git history, to prevent exposed keys. - -All new source code received by pull request will be scanned by a security pipeline that will detect vulnerabilities, sensitive data, exposed secrets, vulnerable dependencies, etc.. All issues identified by the pipeline need to be solved to be able to merge. - -The project also will be followed by a security champion during all your life cycle, that will be a support for security reports analysis, and a required pull request reviewer. - ## Reporting a Vulnerability We're extremely grateful for all that report vulnerabilities to the iFood Open Source Community. All reports are thoroughly investigated by a set of community volunteers. @@ -16,6 +10,8 @@ To make a report, email your vulnerability to oss-security@ifood.com.br. This al Security is one of the most important checks performed within the code, and it is a required step for any code that is included in the project. +The project also will be followed by a [security champion](https://owasp.org/www-pdf-archive/OWASP_Bucharest_2017_Antukh.pdf) during all your life cycle, that will be a support for security reports analysis, and a required pull request reviewer. + ## Shifting security left A good preventive practice is to bring the security checks to the start of the development pipeline, to find vulnerabilities and security issues during the planning and coding phases. The goal is to ensure that the codebase is designed to be secure from the start with rapid feedback, rather than checking for security issues at the end of the process. @@ -24,6 +20,6 @@ It can be done with some practices, like planning all security requirements alon ## Security Pipeline -All iFood projects needs to run to all pull requests a security pipeline that statically scans for vulnerabilities, scans secrets, and vulnerabilities in dependencies. For security reasons, it is not automatically executed on every pull request change, and needs an approval from the project maintainer. If the maintainer understands that the security pipeline can be skipped, he can request the merge to the project owner, that is the only one that has this permission. +All new source code received by pull request will be scanned by a security pipeline that will detect vulnerabilities, sensitive data, exposed secrets, vulnerable dependencies, etc.. All issues identified by the pipeline need to be solved to be able to merge. For security reasons, it is not automatically executed on every pull request change, and needs an approval from the project maintainer. If the maintainer understands that the security pipeline can be skipped, he can request the merge to the project owner, that is the only one that has this permission. Besides this validation, the project use the snyk GitHub app, that will check some vulnerabilitie, and a manual review done by an iFood internal security champion, and it's a required reviewer, and is required to prevent security issues that cannot be caught by automated tools, and give all project users and maintainers a guarantee that the project is safe to use. \ No newline at end of file diff --git a/pull_request_template.md b/pull_request_template.md index cafcba2..b1d3bc1 100644 --- a/pull_request_template.md +++ b/pull_request_template.md @@ -1,12 +1,12 @@ +## Fixes #(issue number): (Issue description) -**1. Related issue:** +**1. What this MR does / why we need it:** -**2. What this MR does / why we need it:** +**2. Possible negative impact:** -**3. Possible negative impact:** +**3. How to test this PR?** -**4. How to test this PR?** +**4. Special notes for your reviewer** -**5. Special notes for your reviewer** - -Thanks for your PR, you're awesome! :+1: \ No newline at end of file +Thanks for your PR, you're awesome! :+1: +If it`s your first time here, please read the project CONTRIBUTING file before submit.