Plan for effectively scaling to handle increased service setup

[jongalloway]

From #9:

Add to this list, re: infrastructure:

Authenticode signing services;
Certificates for said signing;
.NET Foundation CLA bots;
Static / security analysis tools per the maturity ladder requirements;
Hosting / deployment for websites; and
Access control + ability to delegate to other project members for all of the above.
Today, in order for me to give another Akka.NET member the ability to setup CI for one of our sub-projects or plugins - is there a way I can do that without having to wait on a human being at the .NET Foundation?

What are the plans for scaling this?

My thoughts on high level plan is to scale the things that can't be automated is through the Project Support Action Group.

Organizationally, the action groups are run by board members (community elected) and staffed by action group volunteers (.NET Foundation voting members). It may require scaling through paying a vendor, but a decent amount of this can probably be handled by empowering volunteers by documenting processes and giving the right people access to service logins. We've had members volunteer and ask when they'll be given something they can help with, and this is a good example of that. We do have some funds we could use to pay for admin help through corporate sponsorship and member dues, it'll be up to the board to decide on how to spend the budget since paying for operational expenses takes away from money we could be donating to community events, projects, etc.

We were planning to get a better idea of the workload and how well the action group is able to handle it by extrapolating from our pilot project onboarding.

Thoughts?

[glennawatson]

Here's what we been considering on ReactiveUI to try and eliminate some need of getting new users onto Azure DevOps.

1. We are considering having a "Release" label. We would write a .ts azure devops script that would read the github PR and then add it to the build as a build tag. Azure DevOps has a "build tag" filter on the release system and then release when that tag was applied. This would limit the number of requests for users to the DevOps server.
2. We been considering GitHub actions as a CI. One issue with this approach is we don't control the sign client certificate and we'd have to integrate it into GitHub secret store. We definitely been working out ways of leveraging GitHub Actions more with automated Tweets when releases go out and stuff. We basically have been not wanting to go down this route because we annoyed @onovotny a bunch on previous issues.

With the GitHub actions approach it would allow us to be based on GitHub permissions to run. It does have some built in actions by the GitHub team for keystore storage and we could leverage the secrets store in the project/organisation.

[devlead]

For this to scale it's not fair to go rest on just @jongalloway and @onovotny shoulders, for a decent SLA we need a proper support channel.

And it's not fair to oppose more friction than needed upon maintainers, I would love this to be a positive thing where there's a recipe for success, where we offer something with hopefully better and with less maintenance if they would've done it them selves.

We shouldn't lock out possibility for projects to do their own infra, so important that the process for becoming certified should be documented and transparent.

[glennawatson]

I think relying on @jongalloway and @onovotny is problematic. I know on our project we know that @onovotny is especially busy so we've avoided poking him too much. People usually know when people are really busy and hate to interrupt them.