Amazing GitHub Template - Sane defaults for your next project!

Overview

Logo

Amazing GitHub Template - Sane defaults for your next project!

Report a Bug Β· Request a Feature . Ask a Question

license

PRs welcome made with hearth by dec0dOS

Table of Contents

About

Open Source Software is not about the code in the first place but the communications and community. People love good documentation and obvious workflows. If your software solves some problem, but nobody can figure out how to use it or, for example, how to create an effective bug report, there's something very bad going on. Did you hear about Readme Driven Development? Check out the awesome artice written by GitHub co-founder Tom Preston-Werner.

There are many great README or issues templates available on GitHub, however, you have to find them yourself and combine different templates yourself. In addition, if you want extensive docs like CODE_OF_CONDUCT.md, CONTRIBUTING.md, SECURITY.md or even advanced GitHub features like pull request template, additional labels, code scanning, and automatic issues/PRs closing and locking you have to do much work. Your time should be focused on creating something amazing. You shouldn't be doing the same tasks over and over like creating your GitHub project template from scratch. Follow the don’t repeat yourself principle. So just use the template and go create something amazing!

The key features of Amazing GitHub Template:

  • Configurable README.md template
  • Configurable LICENSE template
  • Configurable CODE_OF_CONDUCT.md template
  • Configurable CONTRIBUTING.md template
  • Configurable SECURITY.md template
  • Configurable issues template
  • Pull request template
  • CODEOWNERS template
  • Additional labels template
  • Automatic locking for closed issues and PRs workflow
  • Automatic cleaning for stale issues and PRs workflow
  • Automatic label verification for PRs workflow
  • Automatic security code scanning workflow via CodeQL
Additional info

This project is the result of huge research. I'm a long-time GitHub user so I've seen more than 7.3k READMEs so far. I've started writing docs for my open source projects (that are currently in their early stages so they exist in the private space for now). After I've analyzed many popular GitHub READMEs and other GitHub-related docs and features I've tried to create a general-propose template that may be useful for any project.

Of course, no template will serve all the projects since your needs may be different. So the Cookiecutter comes to the rescue. It allows Jinja template language to be used for complex cases. Just enter up the project preferences you want in the Cookiecutter interactive menu and that's it. There is a manual setup that could be useful for your existing projects (or if you don't want to use Cookiecutter for some reason). This README.md file is not a template itself, you should download the precompiled template and replace the predefined values, then remove unused sections.

Built With

Getting Started

Prerequisites

The recommended method to install Amazing GitHub Template is by using Cookiecutter. For manual install please refer to manual setup section.

The easiest way to install Cookiecutter is by running:

pip install --user cookiecutter

For other install options, please refer to Cookiecutter installation manual.

Usage

Cookiecutter template

After installing Cookiecutter, all you need to do is to run the following command:

cookiecutter gh:dec0dOS/amazing-github-template

You will get the interactive prompt where you'll need to specify relevant options for your project (or the default value will be used).

Preview

Manual setup

Please follow these steps for manual setup:

  1. Download the precompiled template

  2. Replace all the variables to your desired values

  3. Initialize the repo in the precompiled template folder

    or

    Move the necessary files from precompiled template folder to your existing project directory. Don't forget .github directory that may be hidden by default in your operating system

Variables reference

Please note that entered values are case-sensitive. Default values are provided as an example to help you figure out what should be entered.

On manual setup, you need to replace only values written in uppercase.

Name Default value Description
PROJECT_NAME My Amazing Project Your project name
REPO_SLUG my-amazing-project Repo slug must match the GitHub repo URL slug part
GITHUB_USERNAME dec0dOS Your GitHub username without @
FULL_NAME Alexey Potapov Your full name
OPEN_SOURCE_LICENSE MIT license Full OSS license name
modern_header y Use HTML to prettify your header
table_in_about n Use table to wrap around About section
include_logo y Include Logo section. Could only be used when modern_header == y
include_badges y Include section for badges
include_tos y Include Table of Contents
include_screenshots y Include Screenshots section
include_project_assistance y Include Project assistance section
include_authors y Include Authors & contributors section
include_security y Include Security section and SECURITY.md file
include_acknowledgements y Include Acknowledgements section
include_code_of_conduct y Include CODE_OF_CONDUCT.md file
include_workflows y Include .github/workflows directory
use_codeql y Use CodeQL
use_conventional_commits y Add Conventional Commits notice
use_github_discussions n Use GitHub Discussions

NOTICE: to use GitHub Discussions, you have to enable it first.

Roadmap

See the open issues for a list of proposed features (and known issues).

Contributing

First off, thanks for taking the time to contribute! Contributions are what makes the open-source community such an amazing place to learn, inspire, and create. Any contributions you make will benefit everybody else and are greatly appreciated.

Please try to create bug reports that are:

  • Reproducible. Include steps to reproduce the problem.
  • Specific. Include as much detail as possible: which version, what environment, etc.
  • Unique. Do not duplicate existing opened issues.
  • Scoped to a Single Bug. One bug per report.

Please adhere to this project's code of conduct.

You could use markdownlint-cli to check for common markdown style inconsistency.

Support

Reach out to the maintainer at one of the following places:

License

This project is licensed under the MIT license. Feel free to edit and distribute this template as you like.

See LICENSE for more information.

Acknowledgements

Thanks for these awesome resources that were used during the development of the Amazing GitHub template:

Comments
  • dev: consider sonia-corporation/stale instead of actions/stale

    dev: consider sonia-corporation/stale instead of actions/stale

    I recently switched from actions/stale to sonia-corporation/stale.

    actions/stale appears to have no further active development, and sonia-corporation/stale has a nice feature: exempting from marking as stale all issues that are in a project (along with issues that are in milestones, or assigned to someone, both of which actions/stale already had). So if people are proposing features, simply accepting them by adding them to a project, like say a version release plan, will keep them from being marked stale without having to add extra labels.

    sonia-corporation/stale also has a much more comprehensive documentation site: https://sonia-corporation.github.io/stale/

    The Yaml keys in the workflow have different names but there's basically a 1:1 correspondence, so it was very fast to update my existing workflow to a new one.

    Anyway just passing this along in case it's helpful!

    enhancement stale 
    opened by rootwork 3
  • Wording suggestions

    Wording suggestions

    Pull request type

    • [ ] Bugfix
    • [ ] Feature
    • [x] Code style update (formatting, renaming)
    • [ ] Refactoring (no functional changes, no api changes)
    • [ ] Build related changes
    • [ ] Documentation content changes
    • [ ] Other (please describe):

    What is the current behavior?

    Nothing is inaccurate, there are just a few places where things are confusing or could be phrased better.

    Note that while this generally touches the template documentation, it's not about this project's documentation, which is why I marked it as "code style update."

    Issue Number: #3

    What is the new behavior?

    I've left inline comments over at https://github.com/dec0dOS/amazing-github-template/pull/6/files (or just scroll down).

    • Typo fixes
    • Grammar fixes
    • Simplification and/or clarification
    • Stylistic changes (feel free to reject these if you disagree)
    • A few larger restructuring sections or additions

    Other information

    If you want references for any of the suggested fixes, let me know.

    opened by rootwork 2
  • feat: Configurable stale/close workflow

    feat: Configurable stale/close workflow

    Feature Request

    Describe the Feature Request

    I think the project should be more transparent about a) including this specific workflow, and b) allowing it to be more easily configurable.

    My projects are mostly pretty small. If I get contributions, I'm willing to give a long time for contributors to respond to feedback, and I might never close an issue, even if it hasn't had activity, in case someone is willing to take it up at some point in the future. (I don't mind issues being closed so much as them being locked to new comments.)

    PR https://github.com/dec0dOS/amazing-github-template/pull/2 is actually a good example. For your project it may make sense to mark it as stale after 30 days, and close it a week later, but for me that would be too quick. I don't have many contributors, and I want to give them more leeway.

    If this is added to an existing project, maintainers might not realize this is one of the workflows being enabled, and/or might not realize the timeline that's now being enforced.

    I realize one can go in and just remove the workflow or change the days-before-stale or days-before-close values, but this is about surfacing something that could be a surprising or disruptive change for a small project.

    Describe Preferred Solution

    1. Assuming you don't want to inquire in the setup process about every single workflow, consider making this one a special case and allowing people to enable/disable it on setup.

    2. If enabled, inquire in the setup what the values of days-before-stale and days-before-close should be.

    3. Note in the project documentation how to remove or change this workflow (and maybe workflows in general) if it isn't important to a project.

    Describe Alternatives

    Just do number 3 above. To me that would be sub-optimal, but better than not mentioning it at all.

    Related Code

    Additional Context

    N/A

    If the feature request is approved, would you be willing to submit a PR? (Help can be provided if you need assistance submitting a PR)

    • [x] Yes
    • [ ] No
    enhancement stale 
    opened by rootwork 2
  • feat: Wording/language cleanup

    feat: Wording/language cleanup

    Feature Request

    Describe the Feature Request

    There is some wording in some places that seems a little clunky or unclear -- I'm not sure if this is a translation issue or something else, but I thought I could offer some suggestions for making things more straightforward.

    Describe Preferred Solution

    Happy to make a PR with suggestions if you're open to it.

    Describe Alternatives

    N/A

    Related Code

    N/A

    Additional Context

    I don't have any, but I could probably find style guides etc. if you want "objective" citations for my opinions on things :)

    If the feature request is approved, would you be willing to submit a PR? Yes / No (Help can be provided if you need assistance submitting a PR)

    enhancement 
    opened by rootwork 2
  • feat: automatic releases

    feat: automatic releases

    • Automatic release on pull_request to main branch
    • Automatic pre-release on push or pull_request on develop branch
    • Updated documentation
    • Updated template project folder
    • Integrated .gitignore on template project folder
    stale 
    opened by devalexanderdaza 2
  • Update pr-labels.yml

    Update pr-labels.yml

    Allows PRs both from the same repository as well as forks. According to: https://github.com/marketplace/actions/verify-pull-request-labels

    Pull request type

    Please check the type of change your PR introduces:

    • [ ] Bugfix
    • [x] Feature
    • [ ] Code style update (formatting, renaming)
    • [ ] Refactoring (no functional changes, no api changes)
    • [ ] Build related changes
    • [ ] Documentation content changes
    • [ ] Other (please describe):

    What is the current behavior?

    • Fails then running PR labels check from the fork.

    Issue Number: N/A

    What is the new behavior?

    • Allows PRs both from the same repository as well as forks

    Other information

    opened by ss-o 1
  • Changed yes/no in feature request template to checkboxes

    Changed yes/no in feature request template to checkboxes

    Under the question "If the feature request is approved, would you be willing to submit a PR?" I changed the response template to checkboxes. This matches the template for PRs (under "Does this introduce a breaking change?")

    Pull request type

    Please check the type of change your PR introduces:

    • [ ] Bugfix
    • [x] Feature
    • [ ] Code style update (formatting, renaming)
    • [ ] Refactoring (no functional changes, no api changes)
    • [ ] Build related changes
    • [ ] Documentation content changes
    • [ ] Other (please describe):

    What is the current behavior?

    Unclear what one is supposed to do when responding to the Yes/No question -- bold the answer? Delete the non-answer? And the italicized help text makes it a little more confusing.

    Issue Number: N/A

    What is the new behavior?

    • plain text => checkboxes

    Other information

    None

    opened by rootwork 1
  • bump v2 to v3 lock.yml

    bump v2 to v3 lock.yml

    Breaking changes: v2 to v3

    input parameter names have changed

    Ref: https://github.com/dessant/lock-threads/blob/08e671be8ac8944d0e132aa71d0ae8ccfb347675/CHANGELOG.md#300-2021-09-27

    Pull request type

    Please check the type of change your PR introduces:

    • [ ] Bugfix
    • [ ] Feature
    • [x] Code style update (formatting, renaming)
    • [ ] Refactoring (no functional changes, no api changes)
    • [ ] Build related changes
    • [ ] Documentation content changes
    • [ ] Other (please describe):

    What is the current behavior?

    Unexpected input(s): 'issue-lock-inactive-days', 'pr-lock-inactive-days'.

    Issue Number: N/A

    What is the new behavior?

    Renamed following input parameters to allow upgrading from v2 to v3:

    • issue-lock-inactive-days --> issue-inactive-days
    • pr-lock-inactive-days --> pr-inactive-days

    Other information

    opened by ss-o 0
Releases(latest)
Owner
Alexey Potapov
Getting git-style versioning working on RDFlib

Getting git-style versioning working on RDFlib

Gabe Fierro 1 Feb 01, 2022
🐸 Identify anything. pyWhat easily lets you identify emails, IP addresses, and more. Feed it a .pcap file or some text and it'll tell you what it is! πŸ§™β€β™€οΈ

🐸 Identify anything. pyWhat easily lets you identify emails, IP addresses, and more. Feed it a .pcap file or some text and it'll tell you what it is! πŸ§™β€β™€οΈ

Brandon 5.6k Jan 03, 2023
Text Summarizationcls app with python

Text Summarizationcls app This is the repo for the Text Summarization AI Project. It makes use of pre-trained Hugging Face models Packages Used The pa

Edem Gold 1 Oct 23, 2021
LazyText is inspired b the idea of lazypredict, a library which helps build a lot of basic models without much code.

LazyText is inspired b the idea of lazypredict, a library which helps build a lot of basic models without much code. LazyText is for text what lazypredict is for numeric data.

Jay Vala 13 Nov 04, 2022
Utility for Text Normalisation or Inverse Normalisation

Text Processor Text Normalisation or Inverse Normalisation for Indonesian, e.g. measurements "123 kg" - "seratus dua puluh tiga kilogram" Currency/Mo

Cahya Wirawan 2 Aug 11, 2022
A slugifier that works in unicode

Unicode Slugify Unicode Slugify is a slugifier that generates unicode slugs. It was originally used in the Firefox Add-ons web site to generate slugs

Mozilla 315 Nov 21, 2022
A Python3 script that simulates the user typing a text on their keyboard.

A Python3 script that simulates the user typing a text on their keyboard. (control the speed, randomness, rate of typos and more!)

Jose Gracia Berenguer 3 Feb 22, 2022
Build a translation program similar to Google Translate with Python programming language and QT library

google-translate Build a translation program similar to Google Translate with Python programming language and QT library Different parts of the progra

Amir Hussein Sharifnezhad 3 Oct 09, 2021
Text to ASCII and ASCII to text

Text2ASCII Description This python script (converter.py) contains two functions: encode() is used to return a list of Integer, one item per character

4 Jan 22, 2022
Python port of Google's libphonenumber

phonenumbers Python Library This is a Python port of Google's libphonenumber library It supports Python 2.5-2.7 and Python 3.x (in the same codebase,

David Drysdale 3.1k Dec 29, 2022
A program that looks through entered text and replaces certain commands with mathematical symbols

TextToSymbolConverter A program that looks through entered text and replaces certain commands with mathematical symbols Example: Syntax: Enter text in

1 Jan 02, 2022
Hotpotato is a recipe portfolio App that assists users to discover and comment new recipes.

Hotpotato Hotpotato is a recipe portfolio App that assists users to discover and comment new recipes. It is a fullstack React App made with a Redux st

Nico G Pierson 13 Nov 05, 2021
Username reconnaisance tool that checks the availability of a specified username on over 200 websites.

Username reconnaisance tool that checks the availability of a specified username on over 200 websites. Installation & Usage Clone from Github: $ git c

Richard Mwewa 20 Oct 30, 2022
This is a text summarizing tool written in Python

Summarize Written by: Ling Li Ya This is a text summarizing tool written in Python. User Guide Some things to note: The application is accessible here

Marcus Lee 2 Feb 18, 2022
Umamusume story patcher with python

umamusume-story-patcher How to use Go to your umamusume folder, usually C:\Users\user\AppData\LocalLow\Cygames\umamusume Make a mods folder and clon

8 May 07, 2022
Extract knowledge from raw text

Extract knowledge from raw text This repository is a nearly copy-paste of "From Text to Knowledge: The Information Extraction Pipeline" with some cosm

Raphael Sourty 10 Dec 03, 2022
Etranslate is a free and unlimited python library for transiting your texts

Etranslate is a free and unlimited python library for transiting your texts

Abolfazl Khalili 16 Sep 13, 2022
Word and phrase lists in CSV

Word Lists Word and phrase lists in CSV, collected from different sources. Oxford Word Lists: oxford-5k.csv - Oxford 3000 and 5000 oxford-opal.csv - O

Anton Zhiyanov 14 Oct 14, 2022
box is a text-based visual programming language inspired by Unreal Engine Blueprint function graphs.

Box is a text-based visual programming language inspired by Unreal Engine blueprint function graphs. $ cat factorial.box β”Œβ”€Ζ’(Factorial)───┐

Pranav 104 Dec 24, 2022
Fuzzy String Matching in Python

FuzzyWuzzy Fuzzy string matching like a boss. It uses Levenshtein Distance to calculate the differences between sequences in a simple-to-use package.

SeatGeek 8.8k Jan 08, 2023