From d6fb3d645ff46f059745935b62fcc32c63cf4034 Mon Sep 17 00:00:00 2001 From: Francisco Date: Thu, 26 Jan 2023 14:17:18 -0300 Subject: [PATCH] Add guidelines for pull requests (#4002) --- GUIDELINES.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/GUIDELINES.md b/GUIDELINES.md index bac94be6f..0f4c9829e 100644 --- a/GUIDELINES.md +++ b/GUIDELINES.md @@ -62,6 +62,20 @@ Some other examples of automation are: - Looking for common security vulnerabilities or errors in our code (eg. reentrancy analysis). - Keeping dependencies up to date and monitoring for vulnerable dependencies. +## Pull requests + +Pull requests are squash-merged to keep the `master` branch history clean. The title of the pull request becomes the commit message, so it should be written in a consistent format: + +1) Begin with a capital letter. +2) Do not end with a period. +3) Write in the imperative: "Add feature X" and not "Adds feature X" or "Added feature X". + +This repository does not follow conventional commits, so do not prefix the title with "fix:" or "feat:". + +Work in progress pull requests should be submitted as Drafts and should not be prefixed with "WIP:". + +Branch names don't matter, and commit messages within a pull request mostly don't matter either, although they can help the review process. + # Solidity Conventions In addition to the official Solidity Style Guide we have a number of other conventions that must be followed.