├── .gitignore ├── README.md └── checklist-en.md /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | [![alt text](https://s3-sa-east-1.amazonaws.com/www.vinta.com.br/images/dont_delete/devchecklist-logo.png "Devchecklists Logo")](https://www.devchecklist.com) 2 | 3 | # Pull Requests Checklist 4 | 5 | ## Adding a New Language: 6 | * [ ] To add a new language you will need to create another markdown file containing the new [acronym language:](https://www.loc.gov/standards/iso639-2/php/code_list.php) 7 | * E.g. `checklist-pt.md`. 8 | * [ ] No further approval will be necessary; 9 | * [ ] The new checklist language should be visible on Devckecklists after you saved the file on your forked repository. 10 | 11 | ## Important Notes: 12 | * [ ] Markdown is the only way to write checklists on Devchecklists; 13 | * [ ] For tips about how to use markdown to write checklists, please take a look at these raw files: 14 | * [ ] [`checklist-en.md`](https://raw.githubusercontent.com/vintasoftware/devchecklists-template/master/checklist-en.md) sample markdown; 15 | * [ ] [`README.md`](https://raw.githubusercontent.com/vintasoftware/devchecklists-template/master/README.md) contained on this repository; 16 | * [ ] Another checklists markdowns from [Devchecklists](https://devchecklists.com). 17 | * [ ] Changes on the checklist repository will reflect on the current checklist of Devchecklists. 18 | 19 | ## Commercial Support 20 | [![alt text](https://avatars2.githubusercontent.com/u/5529080?s=200&v=4 "Vinta Logo")](https://vintasoftware.com) 21 | 22 | This project, as other Vinta open-source projects, is used in products of Vinta clients. We are always looking for exciting work, so if you need any commercial support, feel free to get in touch: contact@vinta.com.br 23 | 24 | Copyright (c) 2018 Vinta Serviços e Soluções Tecnológicas Ltda. 25 | [MIT License](LICENSE.txt) 26 | -------------------------------------------------------------------------------- /checklist-en.md: -------------------------------------------------------------------------------- 1 | ## 1. Pull request workflow 2 | * [ ] Read thoroughly the feature description to check if everything is implemented. 3 | * [ ] Run the code and use it as the end user would. Double check requested feature’s description. 4 | 5 | ## 2. Creating the pull request 6 | * [ ] Create Pull Request (but don't assign it yet). 7 | * [ ] Describe how to test the PR: urls, environment variables and other needs. 8 | * [ ] Refer to issue(s)/Trello card(s) the PR solves. 9 | * [ ] Refer back to the PR on Trello card(s). 10 | * [ ] Merge the target branch into the PR branch. Fix any conflicts that might appear. 11 | * [ ] Add screenshots of the new behavior, if applicable. 12 | * [ ] Add a description including the context and the chosen implementation strategy. 13 | * [ ] Explain code lines which the reviewer might not understand correctly: 14 | * Don't do it in the description, do it in the code itself as comments. 15 | * Consider refactoring and changing variable/function/method names to make it clearer. 16 | 17 | ## PR Self Review: 18 | #### Look for the following problems: 19 | 20 | * [ ] Code is not following code style guidelines (add links to your guidelines here when copying this checklist). 21 | * [ ] Bad naming: make sure you would understand your code if you read it a few months from now. 22 | * [ ] KISS: Keep it simple, Sweetie (not stupid!). 23 | * [ ] DRY: Don't Repeat Yourself. 24 | * [ ] YAGNI: You aren't gonna need it: check that you are not overcomplicating something for the sake of 'making it future-proof'. 25 | * PS: Fowler said "Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify". 26 | * [ ] Architecture errors: could there be a better separation of concerns or are there any leaky abstractions? 27 | * [ ] Code that is not readable: too many nested 'if's are a bad sign. 28 | * [ ] Performance issues (if that's a real concern for your application). 29 | * [ ] Complicated constructions that need refactoring or comments: code should almost always be self-explanatory. 30 | * [ ] Forgotten TODOs and noop lines: make sure they're mapped in your Trello/Issues board. 31 | * [ ] Grammar errors. 32 | * [ ] Continuous Integration errors, including tests and coverage (configure CI to send you an e-mail when tests are done). 33 | * [ ] If the feature needs regression tests, write them. 34 | * [ ] Other possible improvements (add to this Checklist if it's a general concept - it's open source!). 35 | * [ ] Once all problems are addressed, allocate the reviewer. 36 | 37 | ## Responding to feedback 38 | * [ ] If any problem hasn’t been addressed and the PR needs to be accepted ASAP, create new issues for remaining problems. 39 | * [ ] Respond all of the reviewer's comments ASAP: 40 | * Be grateful for the reviewer's suggestions. ("Good call. I'll make that change."). 41 | * Don't take it personally. The review is of the code, not yourself. 42 | * Try to understand the reviewer's perspective. 43 | * [ ] Once you receive feedback and address all issues, merge and close the PR/branch. 44 | --------------------------------------------------------------------------------