{"id":20577211,"url":"https://github.com/katherinemichel/setting-up-an-open-source-project","last_synced_at":"2025-10-24T20:20:54.991Z","repository":{"id":37601948,"uuid":"75515211","full_name":"KatherineMichel/setting-up-an-open-source-project","owner":"KatherineMichel","description":":repeat: Setting Up An Open Source Project","archived":false,"fork":false,"pushed_at":"2021-12-21T02:09:19.000Z","size":2831,"stargazers_count":35,"open_issues_count":0,"forks_count":11,"subscribers_count":5,"default_branch":"master","last_synced_at":"2025-01-16T21:53:06.816Z","etag":null,"topics":["documentation","open-source","planning","tutorial"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/KatherineMichel.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2016-12-04T03:31:17.000Z","updated_at":"2024-10-26T23:44:46.000Z","dependencies_parsed_at":"2022-07-12T16:33:09.219Z","dependency_job_id":null,"html_url":"https://github.com/KatherineMichel/setting-up-an-open-source-project","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/KatherineMichel%2Fsetting-up-an-open-source-project","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/KatherineMichel%2Fsetting-up-an-open-source-project/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/KatherineMichel%2Fsetting-up-an-open-source-project/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/KatherineMichel%2Fsetting-up-an-open-source-project/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/KatherineMichel","download_url":"https://codeload.github.com/KatherineMichel/setting-up-an-open-source-project/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":242196720,"owners_count":20087826,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["documentation","open-source","planning","tutorial"],"created_at":"2024-11-16T05:48:20.932Z","updated_at":"2025-10-24T20:20:49.955Z","avatar_url":"https://github.com/KatherineMichel.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Setting Up An Open Source Project\n\n![](come-in-open-source.jpg)\n[Photo Credit: Pete McCarthy](https://www.flickr.com/photos/petemccarthy/6866996865/in/photolist-bsP9VF-5HxTaS-aDjRJP-aDjQrH-deG7gC-aDoF1o-aDjPXc-aDoGmu-6rVG54-4SamTJ-aDoGf7-6rkTRy-oau5mJ-rufey1-q7f8tc-6D4R4n-ob5fBr-9ZakZE-fUg5eD-ruf1Y1-hvbS4v-afKdid-nPLGo6-p6vQv5-e28yoh-djiwmi-pPy6cL-74jKzz-nVcJqF-nQiamA-6fSXcE-aDoGyU-fAjoZM-4S4Lcz-5ZXKj8-aDjQSr-7z68V1-pPDNbq-edZStq-8f1nQ1-eVGah1-piE7UU-qzeuLm-6fSGWA-3TRAoj-8Yko35-6fSSyE-6fNEBM-fcweAo-qzfe8W)\n\nTable of Contents\n-----------------\n\n- [About](#about)\n- [Testimonials](#testimonials)\n- [Documentation File Types](#documentation-file-types)\n    - [Markdown](#markdown)\n    - [Dotfiles](#dotfiles)\n- [Initial Documentation](#initial-documentation)\n    - [README.md](#readmemd)\n    - [Wiki](#wiki)\n    - [LICENSE.md](#licensemd)\n    - [Presentation](#presentation)\n- [Editor Configs, Environment, Git](#editor-configs-environment-git) \n    - [.editconfig](#editconfig)\n    - [.env](#env) \n    - [.gitattributes](#gitattributes)    \n    - [.gitconfig](#gitconfig)\n    - [config.yml](#configyml)\n- [Build Automation](#build-automation)\n    - [makefile](#makefile) \n- [DNS](#dns)\n    - [CNAME](#cname)\n- [Advanced Work Flow](#advanced-work-flow)\n    - [Git Flow](#git-flow)\n    - [A Successful Git Branching Model](#a-successful-git-branching-model)\n    - [Comparison between Git Flow and A Successful Git Branching Model](#comparison-between-git-flow-and-a-successful-git-branching-model)       \n    - [Semver](#semver)    \n- [Release Documentation](#release-documentation)\n    - [Roadmap](#roadmap)\n    - [CHANGELOG.md](#changelogmd)\n    - [RELEASING.md](#releasingmd)      \n- [Collaboration](#collaboration)\n    - [Organizations](#organizations)\n    - [Teams](#teams)\n    - [Repository Access](#repository-access)\n- [Common Project Contributor Tasks](#common-project-contributor-tasks)  \n    - [Backend](#backend)\n    - [Frontend](#frontend)\n    - [Support](#support)\n    - [Media](#media)\n- [Workflow Tools](#workflow-tools)\n    - [Projects](#projects) \n    - [Issues](#issues) \n    - [Milestones](#milestones)\n    - [Pull Requests](#pull-requests) \n    - [Code Review](#code-review)\n    - [Repository Statistics](#repository-statistics)\n- [Contributing Templates](#contributing-templates)\n    - [ISSUE_TEMPLATE.md](#issue_templatemd)\n    - [PULL_REQUEST_TEMPLATE.md](#pull_request_templatemd)\n- [Contributing Documentation](#contributing-documentation)\n    - [CODE_OF_CONDUCT.md](#code_of_conductmd)\n    - [CONTRIBUTING.md](#contributingmd)\n    - [Styleguide](#styleguide)\n- [New Contributors](#new-contributors)\n- [Helpful Resources](#helpful-resources)\n\n\u003chr\u003e\n\n# About\n\nWhile looking through GitHub repositories and reading/watching coding tutorials, I have come across a number of best practices for setting up projects. I've never seen these best practices in one place, so I decided to create my own list. Though some are more common than others, a few are obscure, but highly useful! This list is fairly unopinionated. Depending on the language/framework used in a project, additional config files will be needed. \n\n:top: \u003csub\u003e[**back to top**](#table-of-contents)\u003c/sub\u003e\n\n\u003chr\u003e\n\n# Testimonials\n\n\u003e **“Great idea and that's really useful.”**\u003cbr\u003e\n\u003e — Jeff\n\n\u003e **“Cool :) This looks really useful. I'll have to follow the suggestions there.”**\u003cbr\u003e\n\u003e — Mariatta\n\n:top: \u003csub\u003e[**back to top**](#table-of-contents)\u003c/sub\u003e\n\n\u003chr\u003e\n\n# Documentation File Types\n\n## Markdown\n\nGitHub project documentation is often created using Markdown files (files that end in .md). Markdown tends to be simpler and easier to use than regular HTML. See [GitHub flavored Markdown](https://help.github.com/articles/github-flavored-markdown) for instructions. \n\n## Dotfiles\n\nDotfiles begin with a dot and often contain configuration info specific to the developer or project. Dotfiles (or folders) are normally hidden from view. \n\n* [Hidden File and Hidden Directory](https://en.wikipedia.org/wiki/Hidden_file_and_hidden_directory)\n\n:top: \u003csub\u003e[**back to top**](#table-of-contents)\u003c/sub\u003e\n\n\u003chr\u003e\n\n# Initial Documentation\n\n## README.md\n\nA [README](https://en.wikipedia.org/wiki/README) is a file that contains project information and instructions.  \n\n* [Example README Structure](https://github.com/KatherineMichel/setting-up-an-open-source-project/blob/master/example-README-structure.md)\n\n## Wiki\n\nA README usually suffices for providing project information. If not, every GitHub repo comes with a wiki. The project wiki is enabled by default under Settings -\u003e Features. Editing can be restricted to collaborators only. GitHub wikis can be created using [GitHub flavored Markdown](https://help.github.com/articles/github-flavored-markdown) and hyperlinks can be created across pages. \n\n* [GitHub Projects with Great Wikis](https://github.com/showcases/projects-with-great-wikis)\n\n## LICENSE.md\n\nA [Software License](https://en.wikipedia.org/wiki/Software_license) specifies the terms under which open source code can be used and redistributed. GitHub offers guidance for choosing a license. A repo that does not contain a license is considered copyrighted and therefore cannot be used publicly without permission. \n\n* [GitHub Choose a License](http://choosealicense.com)\n* [GitHub Open Source Licensing](https://help.github.com/articles/open-source-licensing) \n\n## Presentation\n\nConsider adding a presentation using [GitPitch](https://gitpitch.com). Create a [PITCHME.md](PITCHME.md) using markdown. A presentation URL such as [the one for this repo](https://gitpitch.com/KatherineMichel/setting-up-an-open-source-project), will be automatically created. \n\n:top: \u003csub\u003e[**back to top**](#table-of-contents)\u003c/sub\u003e\n\n\u003chr\u003e\n\n# Editor Configs, Environment, Git\n\n## .editconfig \n \nA .editconfig is a dotfile in which a developer or project maintainers can specify local editor preferences. For example, if developers are working on different operating systems (Linux, Mac OS, Windows), .editconfig settings can be used to standardize line endings across all machines. \n \n * [EditorConfig](http://editorconfig.org)\n * [EditorConfig Plugins](http://editorconfig.org/#download)\n \n## .env\n\nA .env file is a dotfile used to store environmental variables. Beware pushing a .env file to a public repo. Include the .env in the .gitignore (see below), or, set the environmental variables through the command line/bash or host dashboard.\n\n## .gitignore\n\nWhen running code locally, some files may be generated that are only for your own local use. A .gitignore is a dotfile used to instruct Git to not include these files when pushing code to GitHub, where they would be unncessary. GitHub provides .gitignore templates that vary by language or framework. Alternatively, files to be ignored can be stored in hidden folders named .git/info/exclude. \n\n* [GitHub .gitignore Templates](https://github.com/github/gitignore) \n \n## .gitattributes \n \n## .gitconfig \n \nA .gitconfig is a dotfile in which a developer or project maintainers can specify local Git preferences.  \n \n\u003c!--\nhttps://git-scm.com/docs/git-config\n--\u003e \n \n## config.yml \n \n:top: \u003csub\u003e[**back to top**](#table-of-contents)\u003c/sub\u003e\n\n\u003chr\u003e \n \n\u003c!--\n.cfg file\n--\u003e \n \n# Build Automation   \n\n## makefile \n \nA [makefile](https://en.wikipedia.org/wiki/Makefile) contains code for build automation. \n \n## Earthly\n\nAn [Earthfile](https://earthly.dev/) contains code for containerized build automation.\n \n:top: \u003csub\u003e[**back to top**](#table-of-contents)\u003c/sub\u003e\n\n\u003chr\u003e \n\n# DNS   \n\n## CNAME\n \nA [CNAME](https://en.wikipedia.org/wiki/CNAME_record) file is used to specify a domain name.\n \n:top: \u003csub\u003e[**back to top**](#table-of-contents)\u003c/sub\u003e\n\n\u003chr\u003e\n\n# Advanced Work Flow\n\n## Git Flow\n\nGitHub Flow is GitHub's \"lightweight, branch-based workflow.\"   \n\n* [Understanding the GitHub Flow](https://guides.github.com/introduction/flow)\n\n## A Successful Git Branching Model\n\n[A Successful Git Branching Model](http://nvie.com/posts/a-successful-git-branching-model) is a popular Git workflow methodology referenced often by professional developers.\n\n## Comparison between Git Flow and A Successful Git Branching Model\n\nScott Chacon, a GitHub developer, wrote in a blog post called \"[Issues with git-flow](http://scottchacon.com/2011/08/31/github-flow.html)\" that GitHub Flow is a simple process that can be used to deploy often. In contrast, git-flow (from A Successful Git Branching Model), is a sophisticated process focused on major releases, and may be more complicated than what most developers need.\n\n## Startup Engineering MOOC\n\nStartup Engineering MOOC is currently out of commission, but is a highly recommended introduction to staged deployment using GitHub, Heroku, and AWS. \n\n## Semver\n\n[Semver](http://semver.org) is a popular versioning methodology used for software releases.\n\n:top: \u003csub\u003e[**back to top**](#table-of-contents)\u003c/sub\u003e\n\n\u003chr\u003e\n\n# Release Documentation\n\n## Roadmap\n\nA [Roadmap](https://en.wikipedia.org/wiki/Technology_roadmap) is a schedule for future project goals. A roadmap could be communicated through a Markdown file or through a [project](https://help.github.com/articles/about-projects). \n\nProject Example\n* Project name is version name\n* Example columns: To Do, In Progress, Testing, Done\n\n## CHANGELOG.md\n\nA [CHANGELOG.md](https://en.wikipedia.org/wiki/Changelog) file lists notable changes made to the project. \n\n## RELEASING.md\n\nA RELEASING.md file gives instructions for how to complete a software release. \n\n:top: \u003csub\u003e[**back to top**](#table-of-contents)\u003c/sub\u003e\n\n\u003chr\u003e\n\n# Collaboration\n\n## Organizations\n\nOrganization accounts are for code owned by groups (companies, OSS projects). \n\n* [About GitHub Organizations](https://help.github.com/articles/about-organizations)\n\n## Teams\n\nTeams make permission management easier. A developer added to a team now has access to repos based on team access. \n\n* [Setting Up Teams](https://help.github.com/articles/setting-up-teams)\n* [Maintaining Teams](https://help.github.com/articles/maintaining-teams)\n\n## Repository Access\n\n* Public repo- anyone can access\n* Private repo- only designated members can access\n\n\u003c!--\nAccess Control in GitHub\n* Owners can do anything\n* Collaborators have full read/write access (can push to the project, merge pull requests), but not administrative access (can't change settings, add new collaborators)\n* If you want to restrict someone's access to commit to master branch, instead of adding them as a collaborator, ask them to fork the repo to make changes\n* Have team members work on the same code base, but have separate repo that you send pull requests to that only your operations manager or team lead can accept\n--\u003e\n\n:top: \u003csub\u003e[**back to top**](#table-of-contents)\u003c/sub\u003e\n\n\u003chr\u003e\n\n# Common Project Contributor Tasks\n\n## Backend\n* Code\n* Plugin/utility libraries\n* Tools\n* Infrastructure (Hosting, Build-Tools, etc)\n* Tests\n* Bug reports\n* Examples\n* Translation\n\n## Frontend\n* Design\n\n## Support\n* Reviewed Pull Requests\n* Documentation\n* Answering Questions (in Issues, Stack Overflow, Gitter, Slack, etc.)\n\n## Media\n* Blogposts\n* Tutorials\n* Videos\n* Talks\n\n:top: \u003csub\u003e[**back to top**](#table-of-contents)\u003c/sub\u003e\n\n\u003chr\u003e\n\n# Workflow Tools\n\nGitHub provides a number of special features that help with workflow. \n\n* [GitHub Features](https://github.com/features)\n\n## Projects\n\nGitHub projects are a feature that can be used to prioritize and track workflow through a board of columns and cards.  \n\n* [Projects](https://help.github.com/articles/tracking-the-progress-of-your-work-with-projects)\n\n## Issues\n\nIssues are discussion threads used to ask questions, propose new functionality, and report bugs. Issues can be assigned to people, associated with a milestone, or tagged with one or more labels (which can also be found through GitHub search). Issues that are no longer relevant can be closed.\n\nExample Difficulty Level Labels\n* difficulty: easy, difficulty: medium\n, difficulty: hard\n\nExample New Comer and Help Wanted Labels\n* help wanted, up-for-grabs, first-timers-only, beginner friendly\n\nExample General Labels\n* question, for discussion, docs, feature, bug, enhancement\n\nTypes of GitHub Comments\n* On the pull request\n* On the commit\n* On a line\n\nCommenting Enhancements\n* @ mentioning\n\nMention an issue in a commit and it will show up in the issue and notify anyone subscribed to issue. Include \"fixes\" \"closes\" or \"resolves to auto close the issue when merged in default branch (probably master)\n\n    $ git commit -m \"Should help with issue #1\"\n    $ git commit -m \"Fixes #1\"\n\n## Milestones\n\nMilestones are a scheduling tool used to track the progress of activity.\n\n## Pull Requests\n\nA pull request is a submission of a proposed change to a code base. \n\n## Code Review\n\n[Code review](https://en.wikipedia.org/wiki/Code_review) is examination of code to determine quality. \n\n## Branch Protection\n\n[Branch Protection](https://help.github.com/articles/about-protected-branches) prevents collaborators from making irrevocable changes to the branch. \n\n## Repository Statistics\n\n:top: \u003csub\u003e[**back to top**](#table-of-contents)\u003c/sub\u003e\n\n\u003chr\u003e\n\n\u003c!--\nListing issues- issues tab, filtering issues\nissue notifications, subscribe/unsubscribe to an issue\nRespond by replying to any email about that issue\n\nIssues- keyboard shortcuts\nRails repo issues- filter issues by milestone, labels\n--\u003e\n\n\u003c!--\n* [List of Tools for Code Review Wikipedia](https://en.wikipedia.org/wiki/List_of_tools_for_code_review)\n\nhttps://help.github.com/articles/about-repository-graphs#traffic\n\nhttps://guides.github.com/features/issues\nhttps://github.com/blog/957-introducing-issue-mentions\n\nMilestones\nhttps://help.github.com/articles/creating-and-editing-milestones-for-issues-and-pull-requests\nhttps://help.github.com/articles/associating-milestones-with-issues-and-pull-requests\nhttps://github.com/blog/2178-multiple-assignees-on-issues-and-pull-requests\n--\u003e\n\n# Contributing Templates\n\nWhen an issues or pull request template is added to a repository, the template contents will automatically populate in the issue or pull request form body. These templates can be stored in the root or a hidden directory named .github.\n\n* [GitHub Issue and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates)\n\n## ISSUE_TEMPLATE.md\n\n* [Example ISSUE_TEMPLATE Structure](https://github.com/KatherineMichel/setting-up-an-open-source-project/blob/master/example-ISSUE_TEMPLATE-structure.md)\n* [Creating an Issue Template for Your Repository](https://help.github.com/articles/creating-an-issue-template-for-your-repository)\n\n## PULL_REQUEST_TEMPLATE.md\n\n* [Example PULL_REQUEST_TEMPLATE Structure](https://github.com/KatherineMichel/setting-up-an-open-source-project/blob/master/example-PULL_REQUEST_TEMPLATE-structure.md)\n* [Creating an Pull Request Template for Your Repository](https://help.github.com/articles/creating-a-pull-request-template-for-your-repository)\n\n:top: \u003csub\u003e[**back to top**](#table-of-contents)\u003c/sub\u003e\n\n\u003chr\u003e\n\n# Contributing Documentation \n \n## CODE_OF_CONDUCT.md\n\nA [Code of Conduct](https://en.wikipedia.org/wiki/Code_of_conduct) sets forth the standard of conduct expected of project contributors. \n\n* [Adding a Code of Conduct to Your Project](https://help.github.com/articles/adding-a-code-of-conduct-to-your-project)\n\n## CONTRIBUTING.md\n\nA CONTRIBUTING.md file provides guidance to contributors about best practices for contributing to the project. \n\n* [Setting Guidelines for Repository Contributors](https://help.github.com/articles/setting-guidelines-for-repository-contributors)\n\n## Styleguide\n\nSimilarly to a journalistic styleguide, a programming styleguide illustrates the project's preferred coding conventions.\n\n:top: \u003csub\u003e[**back to top**](#table-of-contents)\u003c/sub\u003e\n\n\u003chr\u003e\n\n# New Contributors\n\nIdeally, make project welcoming to newcomers, with user-friendly documentation. Include a mentor list, if applicable. \n\n* [Helping People Contribute to Your Project](https://help.github.com/articles/helping-people-contribute-to-your-project)\n\n:top: \u003csub\u003e[**back to top**](#table-of-contents)\u003c/sub\u003e\n\n\u003chr\u003e\n\n# Helpful Resources\n\n* [GitHub Blog](https://github.com/blog) \n\nGit and GitHub Documentation\n* [Git Homepage](https://git-scm.com)\n* [Set Up Git](https://help.github.com/articles/set-up-git)\n* [Try Git](https://try.github.io)\n* [GitHub Help](https://help.github.com)  \n* [GitHub Training](http://training.github.com)  \n* [GitHub Bootcamp](https://help.github.com/categories/bootcamp)  \n* [GitHub Guides](https://guides.github.com) \n\nGit Cheat Sheets and Tutorials \n* [Git and GitHub in Plain English](https://red-badger.com/blog/2016/11/29/gitgithub-in-plain-english)\n* [GitHub Development Git Cheat Sheet](https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf) \n* [GitHub Hello World Tutorial](https://guides.github.com/activities/hello-world)\n* [Atlassian Git](https://www.atlassian.com/git) and [Atlassian Git Tutorials](https://www.atlassian.com/git/tutorials)  \n* [Digital Ocean Git Tutorial Series](https://www.digitalocean.com/community/tutorial_series/introduction-to-git-installation-usage-and-branches)\n* [Bitbucket Learn Git with Bitbucket Cloud](https://confluence.atlassian.com/bitbucket/tutorial-learn-git-with-bitbucket-cloud-759857287.html) \n\nGitHub Markdown Documentation\n* [GitHub Flavored Markdown](https://help.github.com/articles/github-flavored-markdown) \n* [GitHub Mastering Markdown Tutorial](https://guides.github.com/features/mastering-markdown)\n* [Enterprise Markdown Cheat Sheet](https://enterprise.github.com/downloads/en/markdown-cheatsheet.pdf)\n\nPresentation Tools\n* [GitPitch](https://gitpitch.com)\n\nProject Funding\n* [Lemonade Stand](https://github.com/nayafia/lemonade-stand)\n\n:top: \u003csub\u003e[**back to top**](#table-of-contents)\u003c/sub\u003e\n\n\u003chr\u003e\n\n\u003c!--\nIssue triage\n\nhttps://github.com/blog/2097-improved-commenting-with-markdown\n\nhttp://jlord.us/git-it\nhttps://github.com/github/training-kit\nhttps://github.com/github/teach.github.com\nhttps://github.com/github-archive\nhttps://github.com/github-archive/training.github.com\n\nhttp://slides.com/kentcdodds/1st-pr#/\n* [First Timers Only](https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.barzl7cwa) \n\nhttps://gist.github.com/PurpleBooth/b24679402957c63ec426\n\nhttp://hackforchange.org/tips-for-better-open-source-documentation\nhttps://github.com/zalando/zalando-howto-open-source\nhttps://github.com/ddbeck/readme-checklist\n\nCODE_OF_CONDUCT\nhttps://github.com/stevemao/github-issue-templates\n\nhttps://github.com/devspace/awesome-github-templates\nhttps://github.com/jessicard/remote-jobs/blob/master/PULL_REQUEST_TEMPLATE.MD\nhttps://github.com/tylucaskelley/github-templates/blob/master/CONTRIBUTING.md\n\nhttps://github.com/angular-translate/angular-translate/blob/master/CONTRIBUTING.md\n\nhttps://github.com/jdorfman/awesome-help-wanted\n\nhttps://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md\n\n\nOpen Source Management, Codes of Conduct, Roadmaps\n* [Open Source Management at Docker](https://github.com/docker/opensource)\n* [Sentry Open Source Hosting](https://getsentry.com/for/open-source)\n\nExample First-Timers Info\n* [Pinax First-Timer Opportunity via Twitter](https://twitter.com/pinaxproject/status/687318459072446466) and [First-Timer](https://twitter.com/pinaxproject/status/694213861327659008)\n* [How to Contribute to Pinax Blog Post](http://pinaxproject.com/pinax/ways_to_contribute) and [How to Contribute to Pinax Blog Post](http://blog.pinaxproject.com/2015/11/10/guide-how-contribute-pinax)\n* [Pinax First Timers Only](http://blog.pinaxproject.com/2016/01/11/first-timers-only-and-new-labels), and [Pinax Issues GitHub](https://github.com/pinax/pinax/issues)\n* [Pinax 16.04](http://blog.pinaxproject.com/2016/02/01/pinax-1604) and [Proposal for Pinax Distribution Versioning GitHub](https://github.com/pinax/pinax/issues/84)\n\nhttp://pinaxproject.com/pinax/how_to_contribute\nhttp://blog.pinaxproject.com/2016/03/15/writing-better-documentation-and-why-documentation/\nhttps://www.youtube.com/channel/UCAPpNG85GLzUBwzYCjd4raQ\nhttps://plus.google.com/events/ca9n7iklbra4i67te8uh55468n0\n\nhttps://github.com/pybee/voc/wiki/Your-first-VOC-contribution\n\nhttps://medium.com/@kentcdodds/what-open-source-project-should-i-contribute-to-7d50ecfe1cb4#.sdw2t63pw\n\nStart contributing to open source\n* Do a GitHub search such as [\"pull requests welcome\"](https://github.com/search?utf8=%E2%9C%93\u0026q=pull+requests+welcome)\n\n* [Jekyll Code of Conduct GitHub](https://github.com/jekyll/jekyll/blob/master/CONDUCT.md)\n* [Rails Code of Conduct GitHub](https://github.com/rails/rails/blob/master/CODE_OF_CONDUCT.md)\nhttps://github.com/HackathonHackers/code-of-conduct\n\nLearn X in Y Minutes\n* [Learn X in Y Minutes Git](https://learnxinyminutes.com/docs/git)\n* [Learn X in Y Minutes Markdown](https://learnxinyminutes.com/docs/markdown) \n\n* [Git Index](http://gitref.org)  \n* [Stanford Git Magic](http://www-cs-students.stanford.edu/~blynn/gitmagic) \n\nRecommended\nhttps://www.git-tower.com\n\nhttps://git-scm.com/book/en/Git-Basics-Tips-and-Tricks\nhttps://github.com/jlord/git-it\n--\u003e \n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkatherinemichel%2Fsetting-up-an-open-source-project","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fkatherinemichel%2Fsetting-up-an-open-source-project","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkatherinemichel%2Fsetting-up-an-open-source-project/lists"}