Forkability recommends a few files, folders and other features for open-source projects, and this project has the ones with ticks by them.

Under "Suggestions" is a list of features which the project doesn't have but could probably benefit from. Some of the more common ones are explained below.

Contributing Guide

The contributing guide is a file which explains to any would-be contributors some important things they should know before they open an issue, fork the repo or create pull request. It is often simply called CONTRIBUTING without an extension, but some people prefer to use Markdown (.md or .markdown) or .txt.

Some of the things which should be included in your contributing guide are:

• The goal of the project. To make sure contributors don't open issues which are way outside of the scope of the project, any pre-determined limitations of the project should be outlined here by explaining what the project intends to achieve.
• Coding style guidelines. E.g. variable naming conventions, architectural patterns used, indent characters used.
• Test-writing guidelines. E.g. BDD-style, end-to-end, extent of coverage.

Licence

The licence is a file which explains to any users or would-be contributors how they can reuse your code or project. It is often simply called LICENSE without an extension, but some people prefer to use .txt.

If you are unsure which licence to choose for your project then Choosealicense.com by GitHub attempts to demystify the licence selection process.

If you want to share your work with others, please consider choosing an open source license.

Untouched & Uncommented Issues

GitHub's issue tracker is a feature commonly used both by users of open-source code and the code's owners or contributors for keeping track of bugs and new features.

Forkability looks for any open issues which weren't created by the repository owner which haven't been commented, and labels these as Uncommented Issues.

Untouched Issues on the other hand are open, non-owner issues which haven't been commented on and haven't been labeled, suggesting that no contributor has even acknowledged the issue.

As an open-source project contributor, it's important to keep on top of issues by organising them, responding to the issue openers. If you do, you're less likely to have people opening up duplicate issues, and less likely to miss important, high-priority bugs or great new ideas.