perl6-infra: rules and guidelines

[rba]

We like transparently decide about the upcoming infrastructure changes together.

I therefore propose change on a service level or for a group of services. A service could be for example "hosting perl6.org static website" and an example for a group of service could be "dns hosting".

There will always be a proposed solution. If there is no better proposal in the comments, we will start implementing the proposed solution, a week after opening the issue.

Here is how we like to handle the Perl6 Infrastructure. Feel free to comment.

Rules and guidelines

1. Automate everything
2. Everything is a service
3. Categorize the service and add additional attributes (monitored, backuped, static, dynamic, redundant, CDN)
   1. hack
   2. build
   3. run
4. Use top level domains perl6.org, rakudo.org, moarvm.org
5. Use subdomains to separate services
6. Make sure every service has at least two admins and every core member has access
7. All technical usernames and passwords are stored securely in either a password tool or at least in an encrypted document
8. Where possible add the admins to a 3-party-services and give authorization. For services with a single user, create a technical user (e.g. perl6-infra).
9. Use what‘s already there, operate own service where needed (DNS services instead of running bind ourselves; github instead of gitolite on a server, etc.)
10. Choose free or sponsored services wherever possible
11. Keep infrastructure documentation updated

[AlexDaniel]

Make sure every service has at least two admins and every core member has access

What's a “core member”? This typically used to refer to rakudo core developers, which we have a lot nowadays (51 currently). Do all of them need access? And why?

Also, I wonder if it's possible to create some sort of git-based thing for access. For example, let's say there's a service that I want to tweak. I can commit to the corresponding git repo, and then ping whoever maintains that service so that they pull the changes. This way lots of people would be able to propose changes (making it easier to contribute), yet only a few will have proper access so there's no security problem.