GithubHelp home page GithubHelp logo

ministryofjustice / technical-guidance Goto Github PK

View Code? Open in Web Editor NEW
26.0 129.0 13.0 940 KB

How we build and operate products at the Ministry of Justice. • This repository is defined and managed in Terraform

Home Page: https://technical-guidance.service.justice.gov.uk/

License: MIT License

HTML 81.55% JavaScript 0.70% Makefile 14.49% SCSS 3.25%
operations-engineering

technical-guidance's Introduction

Technical guidance

repo standards badge

How we build and operate products at the Ministry of Justice. This repo is inspired by, and borrows from, GDS's technical guidance site.

It's built using the gov.uk tech-docs-template, and hosted using GitHub Pages.

Getting started

To preview the site locally, we need to use the terminal, and run:

make preview

This will create a local web server, at http://localhost:4567 This is only accessible on our own computer, and won't be accessible to anyone else.

To test the URLs:

make check

Making changes

To make changes, edit the appropriate Markdown files in/below the source/documentation directory.

Make sure to make changes in a branch, and issue a pull request when you want them to be reviewed and published.

Publishing changes

Any changes merged into the main branch will be published automatically.

Every change should be reviewed in a pull request, no matter how minor, and we've enabled branch protection to enforce this.

technical-guidance's People

Contributors

aliuk2012 avatar andyrogers1973 avatar antonybishop avatar bagg3rs avatar ben-al avatar connormaglynn avatar daverog avatar davidread avatar dependabot-preview[bot] avatar dependabot-support avatar dependabot[bot] avatar digitalronin avatar github-actions[bot] avatar jabley avatar jakemulley avatar jasonbirchall avatar jennyd avatar joelgsamuel avatar mattmachell avatar stevemarshall avatar timja avatar warmana avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

technical-guidance's Issues

Update out of hours support guidance to advise on what level of seniority staff on call should be

As @Tocacar says in #55:

Also, perhaps we need to include a statement on which level of staff is acceptable to be on call, which is possibly where things become tricky. My feeling is that senior and mid level developers can be on call, however, probably not two mid levels. It's probably infeasible to require a senior to be on call. I'm interested to hear thoughts here. I feel a junior can a secondary and should experience on call, but possibly not if a mid-level is primary? I suppose decisions will need to be made pragmatically on a team by team basis, but some guidance will probably be useful.

User access removed, access is now via a team

Hi there

The user benmillar-cgi either had direct member access to the repository or had direct member access and access via a team.

Access is now only via a team.

If the user was already in a team, then their direct access to the repository has been removed.

If the user was not in a team, then the user will have been added to an automated generated team named repository-name-<read|write|maintain|admin>-team and their direct access to the repository has been removed.

The list of Org teams can be found at https://github.com/orgs/ministryofjustice/teams or https://github.com/orgs/moj-analytical-services/teams.

The user will have the same level of access to the repository via the team.

The first user added to a team is made a team maintainer, this enables that user to manage the users within the team.

Users with admin access are added to the admin team as a team maintainer.

If you have any questions, please contact us in #ask-operations-engineering on Slack.

This issue can be closed.

Guidance for external pull requests

We have an open repo within the MOJ Org on github, recently we had a PR from a dev based in Brazil.

It is a tiny PR adding a test and removing a TODO to add some tests later.

A month previously I would have thanked the developer and merged the PR but this was opened shortly after a vuln disclosure around github actions potentially leaking secrets so I was looking for some guidance

Steps:

  • Add CONTRIBUTORS.md file to template.

Link Checker Report

Summary

Status Count
🔍 Total 125
✅ Successful 116
⏳ Timeouts 1
🔀 Redirected 0
👻 Excluded 8
❓ Unknown 0
🚫 Errors 0

Errors per input

Errors in README.md

Update tagging guidance to more clearly show mandatory fields

Some teams are struggling to provide all the detail we'd like to have. It'd be nice to have a minimal set of tags we want people to use. Also, we should relegate infrastructure-support to optional, because it may often (particularly in the Cloud Platform) be the same as owner.

Incomplete formatting and missing words

Not sure exactly whether this is intentional, but on technical-guidance/principles/development-principles.md there are a lot of errors in both formatting and missing words, for example, there is this:

### 1. Share the knowledge
If you have knowledge which is unique to you, it is your responsibility to share it.
We follow “[github flow](https://guides.github.com/introduction/flow/)”, to keep branches small and short-lived, and ensure knowledge is shared.
If you produce something reusable, package it (e.g. with pypi or rubygems) & share it with others on [MoJ Reuseables]( https://github.com/ministryofjustice/moj-reusables)
All non-throwaway code should be reviewed - no-one is 100% right, 
100% of the time… be aware that ‘throwaway’ code has a nasty habit of

### 2. Code should be correct, clear, concise - in that order

When you get to point 4, you've started prefixing lines with *'s to get bullets. And, what is happening with the "'throwaway' code" line?

Obscure space in documentation due to text wrapping

Problem with 'Documenting owners of infrastructure' (https://technical-guidance.service.justice.gov.uk/documentation/standards/documenting-infrastructure-owners.html)

Reading the docs, its hard to spot the space in <team-name>: <team-email>. due to text wrapping. The risk of leaving this unresolved, could cause inconsistency with tagging across the organisation.

Screenshot:

image

On this line:

- `owner`: The team responsible for the overall service. Should be of the form `<team-name>: <team-email>`.

A branch protection setting is not enabled: codeowners require reviews

Hi there
The default branch protection setting called codeowners require review is not enabled for this repository
This option affects a pull request, i.e a PR will need to be reviewed and approved by a CODEOWNER before it can be merged.
See repository settings/Branches/Branch protection rules
Either add a new Branch protection rule or edit the existing branch protection rule and select the Require review from Code Owners option
Create a .github/CODEOWNERS file
Add a or multiple entries of @ministryofjustice/team_name to the CODEOWNERS file
The team_name shall be a team from within the MoJ teams: https://github.com/orgs/ministryofjustice/teams
See GH Codeowners documentation: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
See the repository standards: https://github.com/ministryofjustice/github-repository-standards
See the report: https://operations-engineering-reports.cloud-platform.service.justice.gov.uk/github_repositories
Please contact Operations Engineering on Slack #ask-operations-engineering, if you need any assistance

Link Checker Report

Summary

Status Count
🔍 Total 127
✅ Successful 118
⏳ Timeouts 0
🔀 Redirected 0
👻 Excluded 8
❓ Unknown 0
🚫 Errors 1

Errors per input

Errors in source/documentation/principles/frontend-development-principles.html.md.erb

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.