Document how rules repositories are added/removed

[alexeagle]

We'll probably host some popular rulesets in this GitHub org.

Why?

• The SIG can be funded by donation of IP from companies, in addition to money or engineering resources
• This can give a signal to their users that they are in a "more supported" state, as opposed to hosting on a personal org
• We can do global janitor things to help everyone out

Before we start bringing these in, we need to decide policy bits:

• what makes a ruleset more valuable for us to host
• what is required of a ruleset coming in
• what commitments do people make?
• how do we mechanically perform the move such that everything correctly redirects
• what happens when a ruleset wants to leave or is out of compliance with some policy

[jsharpe]

A good example for the kind of ruleset we might want to host is rules_cuda that is hidden inside tensorflow/runtime. See https://github.com/tensorflow/runtime/issues/56; I have suggested that it would be a good candidate to live in bazel-contrib as it as a ruleset clearly has wider reach than just tensorflow and there have been various forks of the ruleset overtime which all live in various personal repos in various states of maintenance.

Its also an interesting case for bzlmod as in its current form it patches rules_cc which wouldn't fit into the current bzlmod structure.

[jsharpe]

https://github.com/bazel-contrib/SIG-rules-authors/issues/27 is starting to highlight some of the criteria we need to establish for this.

Observations of criteria being established from that issue:

• Convention for naming repo
• Convention for naming workspace - suggestion is bazel-contrib/<repo_name> -> contrib_<repo_name>
• Does the ruleset better live in a bazelbuild ruleset? Is the appropriate bazelbuild ruleset accepting external contributions?
• Who is going to maintain the ruleset?

@keith raised the concern about "migrating everything and becoming a wasteland for low usage repos" however I think that you can use archiving of repositories to solve this to some extent; I propose that rulesets that are members should ensure support for LTS versions of bazel and that we should (with some notification and grace period) archive anything that doesn't meet this criteria. I think this would provide a clear mechanism to users to know which repos are actively supported but without breaking anyone by removing repos from the github org.

[alexeagle]

"who is going to maintain" - this also begs the question, what reputation does this person have, and do they have an employer backing the repo with other engineers to replace this person when they eventually move to another project? @shs96c certainly has an excellent reputation in the Bazel community for example. But how do we tell that without being biased or exclusionary?

"ensure support for LTS versions of bazel" and "actively supported" is the hard part. How can we tell? Maybe we require that rulesets have some bazel-in-bazel integration tests that ensure the compatibility, but we don't really know if there's good coverage. If users file issues and the maintainers don't respond in X months does that mean we archive the ruleset?

The SIG has some funding now, so if someone has a couple hours to write up a document they could bill for that time.

[nkoroste]

Criteria for accepting rule sets into this repo and avoid them from getting stale:

1. Must have a clear owner (POC)
2. Must have clear readme outlining the goal of these rules, how to use them etc.
3. Must have examples
4. Must have tests that are running continuously
5. Must have an SLA of replying to issues/PRs in 2-3 weeks (exact timing TBD)
6. Must have at more than one person who are committed to review/approve PRs? Encode as a CODEOWNERS file.
7. Must publish semver releases. Optional: follow the same release pattern as the rules-template does

[keith]

I think this is a good list. I think we should also codify the failure cases for this, because realistically without directly funding folks we won't really be able to hold them accountable to specific SLAs long term, and folks could leave the projects at any time, leading to us needing to find new maintainers, or archive the project etc.

[alexeagle]

8. Needs to work with LTS Bazel version
9. Include the rules in bazel-central-registry, keep that CI green

When something no longer meets the criteria:

• typically reacting to someone reporting that a repo seems unmaintained (but possibly some health monitoring as part of #2
• give the maintainers X months to remedy
• we archive that repo https://github.com/MobileNativeFoundation/foundation/pull/12/files#diff-eac92d6eaf27f899d71c3bfc7a36c0caea85e712b2aaf394faf1f1eebb7b69c0R54 as an example

[cloudhan]

@jsharpe Now I am developing a pure starklark implementation for cuda rules. Just FYI.