[ ] Include an ISSUE_TEMPLATE.md file to help when people create an issue (idea, bug/defect etc)
[ ] Include a PULL_REQUEST_TEMPLATE.md file to help when people submit a pull request
[ ] Use milestones in the issue section to organise project journey and priority of issues in that current sprint. Also align milestone name to releases
[ ] Use labels on issues to highlight: area, size of work with points etc
[ ] Use releases to show stable versions. Use semver format
[ ] Use an existing branching strategy, for example gitflow (even if a cut down version)
[ ] Split documentation into overview (in README.md) and link to more details. Include explanation of acronyms / abbreviations for people to understand
[ ] Clean up unused files, branches, releases etc
[ ] Add badges to the repo for: CI, dependency checkers, lint checkers, deployment etc
[ ] Documentation to be in the repo, so that it can be kept in sync with the codebase and all changes go via pull request for review (treat documentation like code)
[ ] Have a simple static website that demonstrates features (could host for free on GitHub Pages)
[ ] Deploy documentation as part of CI to static website and downloadable PDF (could host for free on GitHub Pages)
[ ] Use description, link and labels in the project repo (top of landing page)
[ ] Make the project standards (branching, labelling, testing etc) clear
[ ] Lock main branch and pull requests require at least 1 review
Medium
In no particular order:
[ ] Meetup talk
[ ] Hackathon
General
In no particular order:
[ ] Make sure issues (stories) are small enough and have enough information for someone outside the team to understand and feel they could contribute - sketches / diagrams etc are usually welcome, these do not have to be pixel perfect
[ ] Similar to issues, keep pull requests small so others can follow / review - plus improves project's activity
[ ] Try to respond within 24hrs to a contributor activity on the repo
[ ] Commit messages must be descriptive but concise
High
In no particular order:
Note: creating these as issues on your project and working through them
README.mdfile with simple screenshots / diagrams (include links to more details in the various sections)CONTRIBUTING.mdfile. Good examples: OpenGov, AtomCODE_OF_CONDUCT.mdfile. Standard COCLICENSEfile. Good resource to helpISSUE_TEMPLATE.mdfile to help when people create an issue (idea, bug/defect etc)PULL_REQUEST_TEMPLATE.mdfile to help when people submit a pull requestREADME.md) and link to more details. Include explanation of acronyms / abbreviations for people to understandfiles,branches,releasesetcMedium
In no particular order:
General
In no particular order: