Let us know how we are doing

Take the DCI Working Group's new survey!

Page tree
Skip to end of metadata
Go to start of metadata
Status

PROPOSED 

Outcome
Minutes Link

Hyperledger would benefit from a common repo structure which present the same elements consistently. This includes:

  • README
  • SECURITY
  • CODEOWNERS
  • CODE_OF_CONDUCT
  • CONTRIBUTING
  • LICENSE
  • MAINTAINERS
  • NOTICES

What else?


Reviewed By

13 Comments

  1. We should probably also document formally the Copyright and License markup expectations, and we should stipulate the content of CODE_OF_CONDUCT, LICENSE and SECURITY. It would also be ideal to recommend a format for MAINTAINERS so that we might a) automate addition to mailing list and b) ensure people can be easily found online (email, chat, GH etc).

    1. This is what was previously discussed and recommended by The Linux Foundation regarding copyright and license: Copyright and License Policy

    2. Regarding MAINTAINERS.md format, LFID was recommended as an identifying field so that staff can find us across different platforms. 

  2. I might suggest a template repo where we could as the TSC manage any changes over time.

    1. I played with this - if you use a template repo, you have to force push to master to fix the DCO. Better to use a GitHub action, which I’m working on

      1. I wasn't thinking a formal template as much as one that should be emulated, but where we track changes to the recommended structure via Git

        1. I misunderstood.

  3. My 2p:

    • We should format files with an eye towards automation. Whatever we put in each file we need to ask ourselves, should the content be easy to consume from a script? Should it be autogenerated periodically?
    • I'm unclear as to the difference between CODEOWNERS and MAINTAINERS.
      • Is CODEOWNERS all of the contributors? The contributors can be calculated from the Git history although the email addresses used in Git repos don't always map to real people.
    • Eventually we want to store identity/key material "in-band" with the repo itself and then require that all contributions be digitally signed by an identity/key that is already in the repo. This would give us airtight provenance for DCO and knowing who can vote.
      • Once we make this move, we can require contributors land PR's to add their identity/key material in the repo before contributing code. This initial PR should include a digital signature over the CODE_OF_CONDUCT and the GOVERNANCE document and any other documents we require contributors to agree to.
    • Do we want a GOVERNANCE document that specifies who is a MAINTAINER and how the list of maintainers is updated and when?
    1. CODEOWNERS is "people who would like to review changes in a specific place". MAINTAINERS may be people that are not interested in reviewing changes - CODEOWNERS is far more granular, down to single files, for instance.

  4. I'm somewhat delinquent because we never got a call together. Maybe we take this in stages. The first stage being what files we require and how they are formatted. The repo-linter tool takes us part way there.

    1. minimally we should require files that will be useful for enforcing / checking legal, compliance and governance issues