Introduce Client Specification Compliance Badges

[kbdharun]

As suggested here by @pixelcmtd and me, we would like to propose limiting Wiki editing to Collaborators (to prevent Spam link changes and unwarranted file and content renaming).

The proposal is to

• Create an issue template for client authors to request any addition or updating of their client data.
• Introduce a Client Specification Badge for clients conforming to the latest specification as suggested here.
• Mark the client who hasn't updated to newer versions of Client Specification, and hasn't updated to the main branch as outdated and move them to the last part of the page.

[pixelcmtd]

Continuing discussions from #9628:

by definition, a "wiki" can be edited by the community.

Yes, it can. I still hate that GitHub feature, because "how about a bunch of Markdown files? We already have plenty of those." And if all of those things were just in Markdown files in the repository, the community could edit the "wiki" with PRs like for everything else. I'm not sure whether I'm suggesting we should switch away from the GitHub-specific thing, but I am very much suggesting that, like for everything else, outsiders to the tldr project go through collaborators to edit the pages. Having personally experienced, what can happen when you have an open and undermoderated wiki, I can tell you one thing: Don't do it, it's net worth it. If you need an example, learn a bit about how Wikipedia do their thing.

We can use Bats. It's a test framework that enables us to define test suites for bash. In doing so, we can create tests that verify clients meet the interface required by our client specifications. We can test against supported arguments, commands, or even the layout of the output.

I haven't looked at it closely yet, but it does look very interesting.

[jxu]

Seems like there are two different issues here. FWIW, yt-dlp's wiki is actually a full separate repo, yt-dlp-wiki. I assume they configured the Wiki tab to reflect content from there.

[kbdharun]

Seems like there are two different issues here. FWIW, yt-dlp's wiki is actually a full separate repo, yt-dlp-wiki. I assume they configured the Wiki tab to reflect content from there.

I am considering this solution too, but the issue is most of these wiki actions are outdated or don't update dependencies regularly so they can't be run long-term without any issues.

[kbdharun]

An update on "limiting Wiki editing to collaborators".

I have enabled the Feed bot (ems.host integration) to notify us about Wiki edits using the https://github.com/tldr-pages/tldr/wiki.atom feed in our chatroom.

This allows us to continue having a publicly editable wiki while being able to monitor any spam or malicious edits and rectify them ASAP.

I am removing it from the scope of this issue and updating the title to be about Client Specification Compliance Badges.

Edit. Checkout a similar issue at #4044