Restructure and update community governance docs

[AevaOnline]

This is a first pass at re-organizing the community documentation. I anticipate a healthy conversation and several iterations of this work before it is acceptable to merge. It's a hefty patch, with substantial implications for the project, and I'd like folks to understand what I am suggesting before we merge this.

Changes:

• simplifying front page / README
• creating a docs/Community folder for documentation about community structure/governance
• refactored the top-level README to be a succinct summary of the project,
  with content mostly moved to docs/GettingStartedDocs/README
• added docs/Community/README, which outlines the community structure and helpfully links to other documents
• moved docs/Contributing to docs/Community/Contributing, clarified the
  "Design Discussion" section and added a "Weekly Issue Triage" section
• refactored docs/Governance into
  docs/Community/Governance (which is also significantly expanded upon)
  docs/Community/ReleaseProcess (mostly unchanged)
  docs/Community/conduct/ConflictPolicy (mostly unchanged)
• refactored docs/Committers into
  docs/Community/Committers (retains list of committers, though I'd like to remove this)
  docs/Community/governance/charter (retains definition of scope)
  docs/Community/governance/README (retains list of committee members)
• added a few SIG folders and templates as placeholders and examples
• added a few other files as placeholders for content that would be helpful to write soon

To get past the license check affecting documentation, I also added a
wildcard match in scripts.check-license.ignore for docs/*

Signed-off-by: Aeva Black 806320+AevaOnline@users.noreply.github.com

[dthaler]

Good contribution, lots of good things to discuss here.
I think this PR combines many uncontroversial things with some possibly(?) controversial things.
If we don't get immediate consensus, it might be helpful to split this long PR into two so that part of it could be merged immediately.

[dthaler]

In your Community/CodeOfConduct.md lines 8-11 say: "Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the Open Enclave Community Governance Committee or to the Confidential Computing Consortium."

But here only mentions the former. We should be consistent, whichever we use.

[AevaOnline]

I disagree that this needs to be so formal and consistent. It's community documentation, not a C header file.

[dthaler]

remove "in-enclave" since there is an experimental "host verification" library for verifying attestation reports outside of an enclave.

[AevaOnline]

Oh, neat!

[jhand2]

Thanks for writing this up and organizing the community docs! A few small comments

[jhand2]

I think this is just using the conference term "hallway track" as an analogy. Some people that work on the SDK inevitably work in close physical proximity and not all discussions will happen online. Given that reality, I think this is good guidance in terms of decision-making for the SDK.

This is language that is pretty specific to people who attend a lot of conferences (I hear it most often used by academics) so I agree that language could be a little confusing.

[AevaOnline]

Good contribution, lots of good things to discuss here.
I think this PR combines many uncontroversial things with some possibly(?) controversial things.
If we don't get immediate consensus, it might be helpful to split this long PR into two so that part of it could be merged immediately.

Thanks for the feedback, @dthaler . I can certainly see your point that splitting this into multiple PRs might make it easier to merge. I didn't feel that I had the knowledge to guess that ahead of time, so I opened as one PR, and I'm happy to refactor it.

Do you have any suggestions insofar as where to draw those lines?

[achamayou]

@AevaOnline thank you for proposing this new structure and taking the time to update the doc! I do not have any objections, I've left some minor local comments and suggestions inline.

The only general question I have, and perhaps this PR is too early to ask, is how do we reconcile the strict code ownership property of the SIGs (defined per-directory by Prow, as I understand it), and some of the SIGs mentioned in the document or the discussion such as "Release SIG", "Architecture SIG" or "API SIG"?

Would the release SIG only own packaging scripts? Would it own release branches for patching purposes, across areas normally owned by other SIGs on master?
Would an Architecture SIG own any code at all? How would it be decided that a PR needs to go through the Architecture SIG as well as the SIGs that own the files that the PR modifies? That sounds difficult to automate.

Would there be a default SIG that automatically owns all the code that's not owned by other SIGs?

Apologies if that's too many questions, too early. I certainly don't expect an answer to every one of them, but if there were some sample SIG layouts you could link here, I would be very interested to see how they're structured. That aside, I think having this slightly more formal code ownership mechanism is great, and it's definitely a net improvement over the current situation.

[dthaler]

I had some wording suggestions, but nothing blocking and certainly better than before so noting Approval.

[jhand2]

Tried to go through the docs and look for things that might need more discussion beyond the scope of this PR. Only found one in my opinion, but I welcome folks to look for others they want to flag.

[dthaler]

I think SIG-Attestation should also be responsible for tracking OESDK's alignment with attestation standards
(IETF RATS, TCG, etc.) and would like to see that stated explicitly. I personally spend a portion of my time doing just that.

[AevaOnline]

added

[dthaler]

I'd say someone else (maybe Hernan) would be better at this one

[AevaOnline]

I've removed all the chair appointments from this pass, so that SIGs can properly self-organize :)

[dthaler]

It would be good if Intel had representation in SIG-SGX, or even as chair

[jhand2]

Looks good. One suggestion might be to change the sig OWNERS files to be the minimal set of people we know should be approvers for each SIG (right now some SIGs include reviewers that don't work on those areas or this project anymore). We can add more people later as needed.

I would also be fine with merging this and removing people later, whatever people prefer

[AevaOnline]

As per CGC meeting and agreement on April 24th, I have updated this PR and will now merge it. I am noting this since a self-approval is uncommon, and was explicitly requested in the meeting.

Additional changes e.g., to establish the SIG memberships and chairs, shall be done in subsequent PRs.

[AevaOnline]

bors r+

[bors]

Timed out.

[AevaOnline]

bors retry

[bors]

Merge conflict.

[AevaOnline]

bors retry

[bors]

Build succeeded:

• continuous-integration/jenkins/branch