No set guidelines for adding or excluding repositories

[sammyhori]

Currently the requirements for a repository are set out as:

Ensure your contribution is useful and relevant, with sufficient content and a clear, concise description for each item.Make sure your contribution is useful and relevant before submitting. That implies it has enough content and every item has a good succinct description.

This is a good description, but isn't very specific, meaning different reviewers and contributors may have different understandings of the requirements.

I propose that some formal requirements be established to help ensure the longevity of this repository, as they will make it easier for maintainers to evaluate requests and justify turning some down as well.

Finally, well defined requirements will help with automation efforts, giving better guides on what should be marked invalid and what not to.

[sammyhori]

Some potential rules would be along the lines of:

To be valid a repository must be/have:

1. Larger than 50 commits or have been reasonably recently moved from a different/no version control system and still be reasonably large, say 1000 lines of code minimum or used by a community of more than 150 people,
2. Have had at least 5 commits in the last 3 months,
3. Have had at least 25 commits in the last 12 months,
4. Have at least 1 open issue with the given label,
5. The json must be correctly formatted and contain at least one technology category.
6. The contents and function of the repository are appropriate (as some beginner developers looking at this list may be younger teenagers/children).

The strictness or requirements difficultly of these rules will affect the balance of this list's quality and purpose. A balance between holding only massively active, largely used repositories with lots of opportunities for beginners (prioritises the beginners, but may bias help away from smaller projects) and holding every somewhat reasonable project, getting bombarded with personal projects people have started a week ago which are added to the impossibly massive list (prioritises the open source projects [somewhat], but may make the list difficult to search and leave beginners with ignored pull requests) must be found.

Automation opportunities with these rules

1. 🟢🟡 Pass to Warning potential, could check for >50 commits (pass) and stars (pass), even possibly lines of code (although differentiating code and random other things may not prove easy), but overall a user check would be required if there isn't a simple pass.
2. 🟢🔴 Pass to Fail potential, could be automated.
3. 🟢🔴 Pass to Fail potential, could be automated.
4. 🟢🔴 Pass to Fail potential, could be automated (probably via GitHub API).
5. 🟢🔴 Pass to Fail potential, could be automated.
6. Hard to automate, should take manual check. Added comment: GitHub's acceptable use policies will help management of this