Today the model just lists what is required at each level. It is easy for someone to look at the requires as a list of work to do with no benefit to themselves or the project. Or to frame the requirements as "the .NET Foundation is pushing an enterprise agenda on OSS devs".
You should expand the requirements to give a reason for why an OSS project should do this, and include the benefit to the maintainer, e.g.
✔️ Project uses the .NET Foundation CLA bot
Setting up the CLA bot will ensure all contributors have accepted your projects copyright. It will protect the project and you as the maintainer against awful legal thing X and Y.
✔️ Roadmap is documented, via formal document and/or an issue query.
One of the most common questions to a project maintainer is when will the next release be. A roadmap lets users find out for themselves, reducing your workload.
✔️ Build scripts are documented and can be readily used by consumers.
Documented build scripts will help new developers build the project. This is helpful for new contributors, and developers who want to debug an issue for themselves.
Today the model just lists what is required at each level. It is easy for someone to look at the requires as a list of work to do with no benefit to themselves or the project. Or to frame the requirements as "the .NET Foundation is pushing an enterprise agenda on OSS devs".
You should expand the requirements to give a reason for why an OSS project should do this, and include the benefit to the maintainer, e.g.
✔️ Project uses the .NET Foundation CLA bot
✔️ Roadmap is documented, via formal document and/or an issue query.
✔️ Build scripts are documented and can be readily used by consumers.
etc
The .NET OSS library guidance follows this pattern and I think it has worked very well - https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/cross-platform-targeting