ifood · evertontavares-ifood · Mar 21, 2022 · Mar 22, 2022
diff --git 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
diff --git 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
@@ -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.
diff --git 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:
+Thanks for your PR, you're awesome! :+1:
+If it`s your first time here, please read the project CONTRIBUTING file before submit.