├── .github ├── CONTRIBUTING.md ├── CONTRIBUTORS.md ├── ISSUE_TEMPLATE.md ├── PULL_REQUEST_TEMPLATE.md └── README.md ├── .travis.yml ├── README.md └── project-logo.png /.github/CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | ## Before getting started 2 | 3 | > On the first paragraph, take some lines to thank your future contributors. It motivates people and makes you more human. 4 | 5 | # How to contribute 6 | 7 | > Expose your project guidelines about how to contribute to it. Offer resources that people could use to discuss changes they wish to make, ask questions and talk about how they could help (and what needs their help). 8 | 9 | If you need further guidance, you can find our team on the following: 10 | 11 | * IRC channel 12 | * Skype 13 | * Mailing list 14 | * Some Project Management tool. 15 | 16 | > **ProTip:** Now this is a good time to remind people to follow some rules and to be polite while contributing: 17 | 18 | Please note we have a [code of conduct](#code-of-conduct), please follow it in all your interactions with the project. 19 | 20 | ## Getting started 21 | 22 | > Here you should address guidelines about future functionalities, milestone labels, bugs and unlisted features, issued assignments, etc. Since now we have an `Issue` and a `Pull Request` template, you can reference them directly: 23 | 24 | For further guidance about getting started, please refer to the related links: 25 | 26 | * [Pull Request Guidelines](PULL_REQUEST_TEMPLATE.md) 27 | * [Issues Guidelines](ISSUE_TEMPLATE.md) 28 | 29 | > **ProTip:** It's important people know the rules for contributing in the project. It's irritating for people trying to help when they are pushed back because they didn't follow some process that they didn't know existed. This file is the place for these processes and it will lower the barrier to entry for contribution. 30 | 31 | ## Coding conventions 32 | 33 | > Code should be optimized for readability. Attach some custom style guide or reference some. i.e.: 34 | 35 | In order to sanitize coding standards, please follow [this style guide](https://github.com/airbnb/javascript). 36 | 37 | ## Code of Conduct 38 | 39 | > This section should explicitly state that we will not discriminate against people on any grounds other than their code contributions, and make clear that behaviour that would be harmful to other people that may wish to contribute is not acceptable. This gives clear authority to remove people who are causing problems, and also sets a clear tone of inclusion. 40 | 41 | > **ProTip:** You can find more about [Contributor Covenant](http://contributor-covenant.org) or as a seperate `code_of_conduct` file. [Good sample](http://contributor-covenant.org/version/1/4/). 42 | -------------------------------------------------------------------------------- /.github/CONTRIBUTORS.md: -------------------------------------------------------------------------------- 1 | > ## ProTips: 2 | > This is maybe the most important file of your project if you think about maintanability and long-term support. It recognizes people who are helping you and, directly or indirectly, baking your/your project success. 3 | > 4 | > Those people spend their time, for free, to make your project better. You should, by all means, praise and thank them whenever you want. Time is an asset that never comes back, so if people choose to use their time with your code, this file shows them the respect they want. 5 | 6 | # Contributors 7 | 8 | ## Special thanks for all the people who had helped this project so far: 9 | 10 | > Here you should include a list of people who helped your project. A good practice would be their names and GH profiles. Other additional info may fit, but names and profiles are mandatory. Proper credits matter. 11 | 12 | * [Contributor #1](http://LINK_HERE) 13 | * [Contributor #2](http://LINK_HERE) 14 | * [Contributor #3](http://LINK_HERE) 15 | * so on... 16 | 17 | > If you think you can do it better, you can consider using [all-contributors](https://github.com/kentcdodds/all-contributors/) guidelines. This project itself uses it on the README file. You really should consider using them. 18 | 19 | ## I would like to join this list. How can I help the project? 20 | 21 | > Here you could make a call to people who would like to contribute to the project. Below, expose what you expect people to do. 22 | 23 | We're currently looking for contributions for the following: 24 | 25 | - [ ] Bug fixes 26 | - [ ] Translations 27 | - [ ] etc... 28 | 29 | For more information, please refer to our [CONTRIBUTING](CONTRIBUTING.md) guide. 30 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | > ## ProTips: 2 | 3 | > Bugs happen. Not everyone has the technical skill to fix them, but a much wider set of contributors can report them. This should be easy process and should leave the reporter feeling that they have contributed something useful back to the project. 4 | 5 | # Submitting an issue 6 | 7 | > Have something important to say or any prior guidance? Write here! i.e.: 8 | 9 | We have some functionalities in mind and we have issued them and there is a milestone label available on the issue. If there is a bug or a feature that is not listed in the issues page or there is no one assigned to the issue, feel free to fix/add it! Although it's better to discuss it in the issue or create a new issue for it so there is no confilcting code. 10 | 11 | ## Before submitting an issue, check the following checklist: 12 | 13 | > Ensure that contributors will follow a minimal quality check 14 | 15 | - [ ] To-Do. 16 | - [ ] Another To-Do. 17 | 18 | ## The problem 19 | 20 | > Ask the contributor to describe the issue he is facing or the feature he wants to see included to the project. 21 | 22 | ### What are the steps to reproduce this issue? 23 | 24 | > Describe here the requirements to help the contributor describe how can you emulate the issue he is facing. 25 | 26 | - [ ] Step 1 27 | - [ ] Step 2 28 | - [ ] So on... 29 | 30 | ### Expected Results 31 | 32 | > A text asking the contributor what should be the correct behaviour. 33 | 34 | ### Actual Results 35 | 36 | > A text asking the contributor what is the actual behaviour. 37 | 38 | ### Is there anything else you would like to report? 39 | 40 | > An optional step for the contributor to comment with more details the issue he is experiencing. 41 | 42 | ## Environment 43 | 44 | > If applicable, what environment is the contributor using? 45 | -------------------------------------------------------------------------------- /.github/PULL_REQUEST_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | > ## ProTips: 2 | > 3 | > One of the key jobs of validating a pull request is running a series of tests to check that it won't break any existing work when merging in, and that the work that is does add actually... works. We can check this using a CI service like [Travis](https://travis-ci.org/getting_started). It allows people to know without having to wait for a team member to see if they have made any functional error in their code. 4 | 5 | # Pull Request Process 6 | 7 | ## Before submitting a pull request 8 | 9 | > Ask contributors to ensure that any install or build dependencies are removed before the end of the layer when doing a build. 10 | 11 | ## General steps for completing this pull request 12 | 13 | Please review the [guidelines for contributing](CONTRIBUTING.md) to this repository. 14 | 15 | ### Checklist 16 | 17 | > Does your project contributions have steps to follow before being approved? Tests, documentation changing, etc? 18 | 19 | Ensure that your `pull request` has followed all the steps below: 20 | 21 | - [ ] Code compilation 22 | - [ ] All tests passing 23 | - [ ] Extended the documentation, if applicable 24 | - [ ] Added myself to the AUTHORS file 25 | 26 | ### Description 27 | 28 | > Ask the contributor to describe his `pull request`. 29 | 30 | ## Proposed changes 31 | 32 | > Ask contributors about why you (or your project maintainers) would accept the pull request. If it solves a previous request, also ask to link to that issue. 33 | 34 | ### Types of changes 35 | 36 | > Show in a checkbox-style, the expected types of changes your project is supposed to have: 37 | 38 | - [ ] New feature 39 | - [ ] Bugfix 40 | - [ ] So on... 41 | -------------------------------------------------------------------------------- /.github/README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | > Short description (one line) about what this project stands for. 5 | 6 | [![Under Development](https://img.shields.io/badge/under-development-orange.svg)](https://github.com/cez-aug/github-project-boilerplate) [![Public Domain](https://img.shields.io/badge/public-domain-lightgrey.svg)](https://creativecommons.org/publicdomain/zero/1.0/) [![Travis](https://img.shields.io/travis/cez-aug/github-project-boilerplate.svg)](http://github.com/cez-aug/github-project-boilerplate) 7 | 8 | > Short project's overview (one paragraph) explaining what this project stands for. Using this boilerplate, three lines is a good length for briefly explaining this project's purpose while respecting the base layout. :alien: 9 | 10 |
11 |
12 | 13 | ## Installing 14 | 15 | > **[?]** So, how users can get this project up and running on their machines? 16 | 17 | ```sh 18 | # Describe it in a nice way. Code samples with installation basics works great 19 | $ npm install --global ghdocs 20 | $ ghdocs 21 | ``` 22 | 23 | # Getting Started 24 | 25 | > **[?]** What does this project stands for? 26 | 27 | ## Usage 28 | 29 | > **[?]** Tell contributors how to use it. 30 | 31 | ## Contributing 32 | 33 | > **[?]** Write some Contributing guidelines or a Contributors list (or both!). Like: 34 | 35 | Please read [CONTRIBUTING.md](CONTRIBUTING.md) for more details. 36 | 37 | > or if you like it simple: 38 | 39 | 1. `Fork` this repository 40 | 2. Create a `branch` 41 | 3. `Commit` your changes 42 | 4. `Push` your `commits` to the `branch` 43 | 5. Submit a `pull request` 44 | 45 | > You can find more information about Pull Requests [here](https://help.github.com/categories/collaborating-on-projects-using-pull-requests/) 46 | 47 | Check also the [list of contributors](CONTRIBUTORS.md) who helped on this project. 48 | 49 | ## Changelog :memo: 50 | 51 | > **[?]** Write here a link for your `CHANGELOG` file. It's also commonly called `HISTORY`. 52 | 53 | ## Acknowledgments :thumbsup: 54 | 55 | > **[?]** Reference someone's code you used, insert an external link or thank people, i.e.: 56 | 57 | * [Shields.io](http://shields.io/). Definitely a must-have. 58 | * [Travis-CI](travis-ci.org). Another must-have. _Test and Deploy with Confidence_. 59 | 60 | ## To-Do :man: 61 | 62 | > **[?]** If your project is still in an early release, a to-do list is a good thing to keep track: 63 | 64 | - [x] Include something 65 | - [ ] Another something 66 | - [ ] So on... 67 | 68 | ## License 69 | 70 | > **[?]** Include a refence for the license you choosed. For this project my take was the **Public License**. More licenses [here](http://creativecommons.org). 71 | 72 | [![CC0](https://i.creativecommons.org/p/zero/1.0/88x31.png)](https://creativecommons.org/publicdomain/zero/1.0/) 73 | 74 | To the extent possible under law, [YOUR_NAME_HERE](mailto:YOUR_EMAIL_HERE) has waived all copyright and related or neighboring rights to this work. 75 | -------------------------------------------------------------------------------- /.travis.yml: -------------------------------------------------------------------------------- 1 | language: ruby 2 | rvm: 3 | - 2.2 4 | before_script: 5 | - gem install awesome_bot 6 | script: 7 | - awesome_bot README.md --allow-dupe --allow-redirect 8 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | > Template files for writing maintanable GitHub projects. Make your repo pretty! 5 | 6 | [![Under Development](https://img.shields.io/badge/under-development-orange.svg)](https://github.com/cezaraugusto/github-template-guidelines) [![Public Domain](https://img.shields.io/badge/public-domain-lightgrey.svg)](https://creativecommons.org/publicdomain/zero/1.0/) [![Travis](https://img.shields.io/travis/cezaraugusto/github-template-guidelines.svg)](http://github.com/cezaraugusto/github-template-guidelines) 7 | 8 | So you had an idea and developed the next world's industry-changing application. You decided to open-source it because you're way cool. Now you need to educate people about your project and need some docs to get started. You got it. :alien: 9 | 10 |
11 |

12 | Templates included: 13 | README • CONTRIBUTING • PULL REQUEST • ISSUE TEMPLATE • CONTRIBUTORS 14 |

15 |
16 | 17 | ## Installing 18 | 19 | Clone this project and name it accordingly: 20 | 21 | ``git clone git@github.com:cezaraugusto/github-template-guidelines.git MY-PROJECT-NAME && cd MY-PROJECT-NAME`` 22 | 23 | # Getting Started 24 | 25 | This project is a collection of [boilerplate](http://whatis.techtarget.com/definition/boilerplate) (template) files with resumed guidelines for `README`, `CONTRIBUTING` and `CONTRIBUTORS` documentation. It also includes a basic `ISSUE_TEMPLATE` and `PULL_REQUEST_TEMPLATE` which are now [allowed by GitHub](https://github.com/blog/2111-issue-and-pull-request-templates). All templates are filled under `.github/` folder. This `README` itself is a fork of the `README` [template](.github/README.md). 26 | 27 | ## Usage 28 | 29 | 1. After installing, remove this file `rm README.md`. 30 | 2. Move the `README` template file located under `.github/` to the main directory `mv .github/README.md .` :cool: 31 | 3. Follow the basic usage guidelines in each file or make it your way. *The world is yours*. 32 | 33 | ## Useful Resources :thumbsup: 34 | 35 | > References for starting a Project 36 | 37 | * [Helping people contribute to your Project](https://help.github.com/articles/helping-people-contribute-to-your-project/) 38 | * [Am I Ready to Open Source it?](https://gist.github.com/PurpleBooth/6f1ba788bf70fb501439#file-am-i-ready-to-open-source-this-md) 39 | 40 | > `README` References 41 | 42 | * [How To Write A Readme](http://jfhbrook.github.io/2011/11/09/readmes.html) 43 | * [How to Write a Great Readme](https://robots.thoughtbot.com/how-to-write-a-great-readme) 44 | * [Eugene Yokota - StackOverflow Answer](http://stackoverflow.com/a/2304870) 45 | 46 | > `CONTRIBUTING` References 47 | 48 | * [Setting Guidelines for Repository Contributors](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) 49 | * [Contributor Covenant](http://contributor-covenant.org/) 50 | 51 | > `CHANGELOG` References 52 | 53 | > This boilerplate intentionally did not provide any `CHANGELOG` file as example, since [this tool](https://github.com/skywinder/github-changelog-generator) could make it automatically, fulfilling the file's objective. If you still want to keep it handwritten, to keep you (and your project) sane, I'd recommend you to follow the references below: 54 | 55 | * [Semantic Versioning 2.0.0](http://semver.org/) 56 | * [Keep a Changelog](http://keepachangelog.com/) 57 | 58 | > `ISSUE_TEMPLATE` and `PULL_REQUEST_TEMPLATE` References 59 | 60 | * [Creating an Issue Template for your repository](https://help.github.com/articles/creating-an-issue-template-for-your-repository/) 61 | * [Creating a Pull Request Template for your repository](https://help.github.com/articles/creating-a-pull-request-template-for-your-repository/) 62 | * [Awesome GitHub Templates](https://github.com/devspace/awesome-github-templates) 63 | 64 | > `CONTRIBUTORS` References 65 | 66 | * [All Contributors](https://github.com/kentcdodds/all-contributors/) 67 | * [All Contributors (CLI)](https://github.com/jfmengels/all-contributors-cli) 68 | 69 | ## Contributors 70 | 71 | 76 | 77 | 78 | | [![Cezar Augusto](https://avatars.githubusercontent.com/cezaraugusto?s=100)
Cezar Augusto](http://cezaraugusto.net)
[📖](git@github.com:cezaraugusto/You-Dont-Know-JS/commits?author=cezaraugusto) 💡 👀 | [![Nathalia Bruno](https://avatars.githubusercontent.com/nathaliabruno?s=100)
Nathalia Bruno](http://nathaliabruno.com)
[📖](git@github.com:cezaraugusto/You-Dont-Know-JS/commits?author=nathaliabruno) 👀 | [![Billie Thompson](https://avatars.githubusercontent.com/PurpleBooth?s=100)
Billie Thompson](http://purplebooth.co.uk)
💡 | 79 | | :---: | :---: | :---: | 80 | 81 | 82 | This project follows the [all-contributors](https://github.com/kentcdodds/all-contributors) specification. 83 | Contributions of any kind welcome! 84 | 85 | ## License 86 | [![CC0](https://i.creativecommons.org/p/zero/1.0/88x31.png)](https://creativecommons.org/publicdomain/zero/1.0/) 87 | 88 | To the extent possible under law, [Cezar Augusto](http://cezaraugusto.net) has waived all copyright and related or neighboring rights to this work. 89 | -------------------------------------------------------------------------------- /project-logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cezaraugusto/github-template-guidelines/349a3b931612ff2f174f4fe09adfa92118814823/project-logo.png --------------------------------------------------------------------------------