Existing documentation for requesting new Gerrit repo

https://www.mediawiki.org/wiki/Gerrit/New_repositories

Very Important:: Deployments are run by Volunteer community

So schedule enough time for deployment enough for the correspondence

@Atieno wondering if the GitLab roadmap affects our strategy? https://www.mediawiki.org/wiki/GitLab/Roadmap

Notes from meeting with Release Engineering and Testing

How to contact release engineering with questions: https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Contact
https://wikitech.wikimedia.org/wiki/PipelineLib [container based CI]
https://wikitech.wikimedia.org/wiki/Blubber [docker file creation]
https://wikitech.wikimedia.org/wiki/Deployment_pipeline [current deployment pipeline]

We need to break this one into smaller pieces of work. We'll do this during grooming.

Next steps for this task:

• Pull it into this sprint
• Expound on the current outlined processes
• Send the doc to team members for review

The deliverable is something we can hand over to an Engineer to follow when deploying a new Service/API

Atieno has started to Expound/add flesh to the current skeleton deployment playbook

Update notes from review sync with @apaskulin

• The documentation is not for the deployment process, it's a prep process before handover to the SRE team for deployment, branding it as a "deployment process" sends the wrong signals and assumes it's the actual deployment work. So we should frame it as a new service cheat sheet

• We should document current process and not what we wish the process was. In as much as improvements can be made to current system, documenting the improved workflow does not legitimize it

• Link out to docs that lives somewhere else

• In addition to above we should not create processess for teams, they should create and publish their own, for example we have in our current doc to ping Release Engineering for new Gerrit repos so Release Engineering might start receiving 1,000 daily repo requests from a communication what we have broadcast yet this is not the officially documented process and they may not be aware of this new responsibilty we have placed on them

• If we are to publish this to the wider community then the decision points should be all inclusive. For example the Community may not have access to internal team members in the DACI like Release Engineering

• It's never advisable to have 2 copies of documentation, in this case we would have one copy for internal Engineers and second copy for Community. But it might be helpful to publish an internal version

• Publishing the shortcuts would ofcourse lead everyone to the shortcut, noone would choose the 10 day option yet there's a 10 minutes one - but the shortcuts are not the official processess

Notes from sync with @FJoseph-WMF and @apaskulin

• https://www.mediawiki.org/wiki/Wikimedia_services_policy is what's officially published right now and is closest to the doc we have
• probably updates to this and/or something in Wikitech in the ServiceOps space maybe..?
• Above doc is policy, ours is execution

Action items for @Atieno

• Go through the policies doc see how it align to what's on the doc
• Remove direct pinging people on slack(back doors)
• Instead Reference public intake forms for the different teams - teams official entry points
• A good fit for the doc would be Wikitech as a brand new page, not edits to a pre-exisiting page