Suggestion: Add CI to automate heavy PR load

[transitive-bullshit]

This would ideally combine awesome-lint with a linter for the pull requests themselves and the main awesome readme.

Related to #1363 and the goal of maintaining Sindre's sanity 💯

Here's my proposed game plan:

• create a linter based off of awesome-lint that lints this repo's readme.md to verify formatting and extract all the sub-lists
• this linter validates every awesome list linked to via awesome-lint
• maintainers will only consider PRs once they pass this CI step

There will be some existing awesome lists that don't pass awesome-lint, so we could whitelist these for now and incrementally fix them until the whitelist can be removed.

This would also put more onus on the awesome-lint project which appears to have been inactive for some time.

Possible future extensions:

• Include awesome-lint in the default awesome list template such that it would be enforced via CI for sub-awesome lists going forwards.

@sindresorhus I'd be happy to spearhead this, since I really believe these lists help countless developers out there every day, and the current gameplan of manual reviewing (even with the help of fellow list-makers) seems sub-optimal.

[sindresorhus]

I honestly think this will just create more work for us with false-positives. It's really hard to correctly lint Markdown and many of the things I comment on cannot be automatically linted.

I guess we could experiment with awesome-lint in some Awesome lists first, so any issues would only disrupt those lists an not the main Awesome list.

In short, awesome-lint will need a lot of work to be production-ready and nobody has been willing to do it. Are you?

[sellisd]

How about a complementary approach: encourage the automated generation of awesome lists.

To generate an awesome list that conforms to the requirements not much are needed:

1. A table with the list entries that could have the following format:

Category	Name	Link	Description
Platforms	Node.js	https://github.com/sindresorhus/awesome-nodejs#readme	JavaScript runtime built on Chrome's V8 JavaScript engine.
Frontend Development	...	...	...
...	...	...	...

2. A string with the title of the list

3. A header in markdown format

4. A footer in markdown format

5. An enum for license choice

6. A free text for code of conduct or other necessary files

A short script in ones favorite language could do the trick.

[sindresorhus]

@sellisd Awesome lists should be hand-made.

We already link to a generator to make it easier to get started: https://github.com/dar5hak/generator-awesome-list

[transitive-bullshit]

In short, awesome-lint will need a lot of work to be production-ready and nobody has been willing to do it. Are you?

Yes :) See my first PR for awesome-lint. I've actually worked quite a bit with unist and the remark ecosystem, and I'm excited to work on this.

There will still be a need for manual review of submissions, but I really think that just having an obvious RED LIGHT when someone creates a PR request because of failing some basic linting check will make your life easier as a maintainer.

Our goal with the linter shouldn't be to catch all false-positives. It should be to make it very clear when submitting that the author hasn't adhered to basic guidelines. As long as the linter can't produce false-negatives (e.g., linter says your readme is invalid, but it's really okay), then I think this will be an overall win for cutting down the time it takes to deal with submissions.

[sindresorhus]

@transitive-bullshit Good to hear. Let's make this happen then :)

[sisirkoppaka]

@sindresorhus @transitive-bullshit Added a PR ( #1675 ) for linting awesome itself with awesome-lint as a GitHub Action which should shine more light early in the PR review process on linting success check.

Do share your thoughts.

[brandonzane11]

How can I fix?