Repository Structure Task Force

I'll send an email to the TSC soliciting a meeting time. Will need to accommodate EST and PST so far.

I really like having a tool that can be used to check that the repo has the files that Hyperledger expects.

Looks like it wanted a very recent version of Node.js and npm, and I also had to upgrade gawk for Catalina. Works now, looks like we need to define a set of rules.

I had a long write-up of some analysis I did of repolinter tool but the WIKI logged me out and I lost it.

tl;dr:

RECOMMENDATION: adopt repolinter with a policy that omits checking the NOTICES and CoC email. Fix the rule for Azure pipelines and omit the SUPPORT file check and PR/Issues templates. Everything else in the default policy should be required.

All rule sets can be changed in default.json or in repolinter.json. For checking repos, it should be done via local workspace files NOT the target, since the repolinter can be gamed by changing the rule sets in the target. The whole purpose of checking the target for compliance will be lost. Unless of course the target rule set file also contains explanations of why the rule set has been modified from our recommendations.

SUPPORT.md

I think SUPPORT.md should be required. For example repolinter SUPPORT.md says:

"If you are having trouble running repolinter, make sure you have the latest npm with npx support before running npx repolinter.

If you find a bug, please submit it to our issue tracker at https://github.com/todogroup/repolinter/issues and label it as a bug"
This is extremely useful, a problem of not able to run repolinter was brought up before- A look at SUPPORT.md tells you what to do. I have heard a lot of people complaining about the lack of support or response in Hyperledger frameworks. Having a SUPPORT.md makes it possible to point to it or to quote it for a first level support. It does not have to be elaborate, just a few lines to help you get started on a journey.

PR and ISSUE_TEMPLATEs
Should be required, for ease of reporting issues and putting together PRs. This will help more collaborators be productive.

ABOUT the emails for CoC or NOTICES: I do not have a problem with these being taken out of the rule set. Unless of course the email is the general support email which has a chance of being answered.

If you look above, at the screen dumps of the runs that Tracy Kuhrt did or I did, you wll notice that linguistics and license libraries are missing, those are gem components that need ruby; of course for complete coverage you probably need those libraries- I have not yet run with them so I do not know what the results of such a run would be.

Note, that the NOTICES file may be required by some compatible licenses. Most of our larger projects probably need this. It's worth discussing whether requiring this file would stimulate some awareness from projects that do need it.

Change log feels optional to me. Some projects publish release notes that uplevel the commit history which is otherwise available through the repo directly.

The SECURITY.md and CODE_OF_CONDUCT.md should be standard across projects. I think there was some talk of a repo for these things. Maybe when we reorg the governing docs?

The content of the other files should be flexible to each project's needs.

We could indeed establish a template repository for creating new repositories. That won't help with ones we already have. It would simplify the work of the CA team, though. I submitted a PR to fabric that includes a modified policy file for repolinter that makes the changes I had been suggesting. https://github.com/hyperledger/fabric/pull/630

I believe that all repos now have the common SECURITY.md file. That should also be added to any template repo we create. The Fabric repo uses the following to refer to the CODE_OF_CONDUCT in the wiki

Code of Conduct Guidelines
==========================

Please review the Hyperledger [Code of
Conduct](https://wiki.hyperledger.org/community/hyperledger-project-code-of-conduct)
before participating. It is important that we keep things civil.

<a rel="license" href="http://creativecommons.org/licenses/by/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by/4.0/88x31.png" /></a><br />This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution 4.0 International License</a>.

I think that someone suggested we cut-n-paste from the wiki into the CoC file. I could live with that, but it would make for a chore if we ever change it.

Here's a gist of all the repos under the hyperledger GH org repolinted:

https://gist.github.com/christo4ferris/13df399dff3613d405e8a60f23847385

Why is there a github-issue-template check if most (all?) HL projects use Jira?

https://gist.github.com/christo4ferris/13df399dff3613d405e8a60f23847385#file-gistfile1-txt-L7446

I believe these lines here will always clash with our tests because of how truffle migration files are structured.

Danno Ferrin suggests not requiring copyright headers in javascripts as another tweak that should be considered.

I believe ROADMAP.md isn't being checked. What's the status of that file? 

No hyperledger projects have a NOTICE file (the only exception is when go code is vendoring in libraries).  I propose it be deleted from the lint check.  Alternately we should define what goes in it.