Proposal to Standardise Repository Names as operations-engineering-*

[jasonBirchall]

I propose standardising all our repository names to follow the format operations-engineering-*. This change aims to bring clarity and organisation to our repository infrastructure, making it easier for current and future team members to navigate and understand our projects.

Proposal:

• Rename all existing repositories to start with operations-engineering-, followed by a specific descriptor that reflects each repository's purpose.

Objective:

• To enhance navigability and collaboration within our team.
• To create a clear, organised, and intuitive repository naming system.

I'd like to hear your thoughts on this proposal.

[connormaglynn]

For things that are internal and 100% owned by us - yes I completely agree! ✅

Where I get a bit dubious is for repositories that are more service orientated, such as aws-root-account, github-collaborators, dns-iac - these things are MoJ wide 🗺️ Slapping our team name as a pre-fix doesn't sit as well with me, initial thoughts for reasoning behind that are:

• These can be used as references for the entire MoJ, so a change in team name shouldn't result in renaming these repositories that people have to keep track of
• People currently referencing these repositories will need to be updated appropriately, as it'd be quite jarring if people have documentation on how to create a collaborator to find we've broken the link
• These repositories act as a Service UI (at the moment) for the user, feels like the name should fit the naming standards - and adding our team name on the front I don't believe meets that

On the other hand though, there are benefits of it like:

• Users are more aware that we 'own' these repositories and should contact us for help and questions (increasing awareness of our team and responsibilities)
• Makes us finding our repository estate much easier
• Helps new joiners find our estate
• Helps users find which "things" we look after i.e. if they see operations-engineering-aws-root-account then they look for operations-engineering which leads them to operations-engineering-dns
• (There's potentially other ways to get the above benefits though 🤔 )

I'm not convinced either way, but something we should consider! 😁 and again, for our internal repositories, 100% agree ✅

[jasonBirchall]

Thank you for your insights, Connor. This is a really interesting point:

These can be used as references for the entire MoJ, so a change in team name shouldn't result in renaming these repositories that people have to keep track of

I agree, as there will be services we own and maintain that belong to the same organisation. To address this, it might be wise to consider placing aws-root-account and github-collaborators on a list of exceptions. This way, we can revisit their naming conventions later when we focus our efforts more closely on that area.

[PepperMoJ]

My name is Sam Pepper and I support this proposal.

[tamsinforbes]

Here's my 🪙 🪙

• Yes for our repos operations-engineering-* makes sense, my only pain point is the prefix is very long, so when the number of characters displayed is truncated you can't distinguish repo names easily; but I see no reasonable way round this, and other teams are doing the same thing; unless we rename our team... 🫠
• For the other less obviously our repos I have no strong opinion either way, except that if we are responsible for them then perhaps there is benefit to prefixing them.

[jasonBirchall]

Thanks, Tamsin. I agree. The name should be shorter. Perhaps the decision is <team_name> rather than being explicit about the current name. I have considered requesting a team rename, as operations engineering carries too many connotations with the "old" way of running operational software, in my opinion.

[tamsinforbes]

I'd support exploring a team rename. 🌑 ✨

[SteveMarshall]

As I mentioned on Slack, I think there's a distinction between those things for which Ops Eng are the custodian for all of MOJ (eg DNS, technical guidance), and things that are related to the team itself.

For those things where the team is a custodian for the wider org, the repo should definitely not be namespaced to include the team name, because operations-engineering-dns (for example) implies the repo only contains that DNS config which relates to the Ops Eng team, whereas just dns makes it clear that it's the root DNS config for all of MOJ.

For things where the repo is specifically related to the job of the Ops Eng team, though, I think it makes sense to namespace things. For example… a dashboard that allows you all to triage PRs across all the services OE owns might reasonably be in a repo called operations-engineering-pr-dashboard.

The other thing to bear in mind is those things where the owner might change over time: in those cases, it might make sense to have a stand-alone name that isn't coupled to Ops Eng, so that we don't have to rename it when the ownership changes. Again, these are likely to be the sorts of things where you're custodians for the whole of MOJ, or some large portion.

[jasonBirchall]

Thanks, Steve; this is exactly the sort of insight we were looking for. 🚀

[jasonBirchall]

ADR PR is linked here
ministryofjustice/operations-engineering-runbooks#199