Currently there's a governance repo & a governance page in the wiki. We need to consolidate these to a single resource.

We're going to move the wiki info to here, leave the wiki page where it is so there's another way to locate the information, then change the content of the page to point to this repo.

Proposal to add CONTRIBUTING and PROCEDURES file to governance repo.

----DRAFT-----

CONTRIBUTING and PROCEDURES

Code of Conduct & Diversity

All activities related to the L3AF project must adhere to our Code of Conduct and Diversity policies

Licensing

All contributions must conform to the licensing guidelines of the L3AF project

Issues

Issues are opened and managed in GitHub Issues under each repository: https://github.com/l3af-project

Ways to Contribute

• Code Contribution
• Issue submission, resolution, comment
• Wiki contribution- L3AF Wiki
• Contribution a document
• Ask a question or provide feedback to the project
• Share your knowledge!

General GitHub Workflow:

• https://docs.releng.linuxfoundation.org/en/latest/best-practices.html#github-workflow

Guidelines for Contributors:

• Each code submission should include an issue identifier number to reference what is being addressed by this change.
• Each code submission that includes new code branches must include automated test cases to exercise the new code branches added.
• Commits must be signed and DCO approved.
• Commits should be rebased into the latest branch's HEAD.
• Additionally, we recommend the following Best Practices: https://docs.releng.linuxfoundation.org/en/latest/best-practices.html

Guidelines for Committers/PTL:

• When performing code reviews, committers should check the following items:
  • Make sure CI versification was successful.
  • Verify that the submission contains appropriate test cases.
  • Verify that the commit message is explicit and is appropriate for the code being changed/added/removed.
• After code is merged, the committer should make sure any post CI processing was successful.
• Pull Requests require approval from the committers team for the respective repo.
• New committers can be selected by performing a TSC vote.

Branch Guidelines:

• Main development happens in the "main" branch.

Procedures:

• Governance and procedures for the project can be found here.
• A list of L3AF Technical Steering Committee Representatives can be found here.

We need to document what the inbound and outbound vulnerability management process is.

• Comparable from CCC: governance/security-response-policies.md at main · confidential-computing/governance (github.com)
• Microsoft comparable (less relevant for a foundation project): ebpf-for-windows/SECURITY.md at master · microsoft/ebpf-for-windows (github.com))
• LFx Security- https://docs.linuxfoundation.org/lfx/security/overview

There is work in progress linked at bottom of https://github.com/ossf/wg-vulnerability-disclosures

We need to document the Code of Conduct (ideally based on Contributor Covenant), and the process for reporting any issues.

According to https://www.contributor-covenant.org/ the latest is v2.1 and the "How to Adopt Contributor Covenant" section there explains what would need to be done.

Move https://github.com/l3af-project/l3af-arch/blob/main/RELEASES.md to this repository.

While you're at it, rename the file so it better reflects the contents of the file (release process).

Require PR to commit, no direct checkins

And make sure CODEOWNERS and the actual permissions to merge match

Today the technical charter does not appear to be available publically anywhere I can find.

https://wiki.lfnetworking.org/display/L3AF/L3AF%3A+Technical+Charter%2C+Milestones+and+Deliverables has a title that implies it's there, but it's not.

The wiki also links to https://wiki.lfnetworking.org/display/L3AF/L3AF+Technical+Charter+-+Final?preview=/56068498/56068502/Revised%20L3AF%20Technical%20Charter%206-25-2021.docx%20(1).pdf but that link just gives permission denied.

It should be checked into this repo in a format (e.g., markdown) that makes it easy to propose and review any changes to the technical charter. LF legal (Scott Nicolas) has already stated that as long as the content is the same, format translations such as to PDF or markdown are fine.

IIRC, the charter (at least) is mentioned on the l3af.io website. Review the site, create a list of things that need to change to point to the governance repo, then ask LF to make those changes for us.

To make the project friendlier for new users/contributors, we should create a top-level README.md file for the l3af-project GitHub organisation.

Here's a pointer on how to do that.

The README should, at minimum (and not necessarily in this order)…

1. Point to the CoC
2. Point to the Contributing file
3. Summarise what stuff is in which repo
4. Point to a 'getting started' guide
5. Point to the mailing list, slack, meetings, wiki

Most of the files mentioned here can exist in the .github repo then be inherited by other repos (if they aren't overridden by local files).

Document this in this repo and/or in the overall CONTRIBUTING doc.

Now that L3AF is a sandbox project for LFN, we get to send a representative to the TAC.

Whom shall we send? Who would like to take this on for the community?

E.g., to add assignees and labels

This is related to #6, inasmuch as it's about who has what permissions on which repos (and how they get them).

The L3AF Technical Charter says that code to run in "the kernel" must be GPL-2.0. Though it also allows the TSC to accept alternate licenses.

Feedback was previously provided that "the kernel" should at minimum be changed to "the Linux kernel" but that change does not appear to have been done.

This issue is that the governance repo should document the latest TSC policy for licenses.
Example 1) if one wanted an xdp-root program that can run on both Linux and Windows, is the disjunctive "GPL-2.0 OR Apache-2.0" acceptable for a contribution? What process would one go through?

Example 2) Should we say that the TSC will only consider OSI Approved Licenses? (https://opensource.org/licenses)

And if it doesn't, please add it. Don't surprise people with it after they've already committed and sent over a PR.

Review the wiki for anywhere it mentions governance docs/processes and redirect those pages to this repo instead.

Also, if you find any instances of docs/processes that still need to move to this repo, open a separate issue for each one.

Should there be an issue triage process? E.g., do all design proposals come to the TSC, or do the maintainers of each repo have their own issue triage process?
Are issues discussed in a meeting or merely in github? Or slack?

We have open weekly calls, but it's not clear who exactly is a TSC member and who is a community participant.

The L3AF governance page gives the project a lot of flexibility on this, at least for the first 24 months.

Change the wiki page to point to a markdown file in this repo.

Now that L3AF is a sandbox project for LFN, we get to send a representative to the MAC.

Whom shall we send? Who would like to take this on for the community?

Here's what the CCC recommends projects adopt, I don't know if LFN has similar guidance for its projects:

Training
Maintainers are recommended to take the Linux Foundation course: Inclusive Open Source Community Orientation

Any contributor who may present in a CCC sponsored forum is recommended (and in some cases may be required) to take the Linux Foundation course: Inclusive Speaker Orientation

Inclusive writing style guides
An open source best practice is to document style requirements. This makes it easier for new contributors to conform to community norms without guessing and reduces unproductive practices like "bike shedding". Example style guides include: https://github.com/torvalds/linux/blob/a5f526ecb075a08c4a082355020166c7fe13ae27/Documentation/process/coding-style.rst#4-naming https://docs.microsoft.com/en-us/style-guide/bias-free-communication https://developers.google.com/style/inclusive-documentation

It can be barebones at the moment. We can iterate on it as needed after that.

Should document the process for selecting/updating maintainers of each repo

Presumably for new repos (issue #5), the maintainers are approved by the TSC at the time the repo is created.

For existing repos, does adding/removing someone as a maintainer need TSC approval or is that delegated to the existing maintainers of that repo or what? We should document the answer.

Need to document the process for adding new repos under github.com/l3af-project

Per TSC discussion today, the process is to bring the proposal to the TSC who will vote on it. If approved, any member of the TSC can then create the repo.