Release v1.1.0 (#35)

.gitignore

@@ -164,4 +164,3 @@ cython_debug/
 # VSCode
 
 .vscode/
-/.idea/.gitignore

README.md

@@ -1,4 +1,10 @@
 # [RAP Community of Practice](https://NHSDigital.github.io/rap-community-of-practice/)
+![CI](https://github.com/NHSDigital/rap-community-of-practice/actions/workflows/main.yml/badge.svg "CI badge indicating passing or failing status")
+[![Release Version](https://img.shields.io/github/v/release/nhsdigital/rap-community-of-practice "Release version")](https://github.com/NHSDigital/rap-community-of-practice/releases)
+[![MkDocs Material](https://img.shields.io/badge/style-MkDocs%20Material-darkblue "Markdown Style: MkDocs")](https://squidfunk.github.io/mkdocs-material/reference/)
+[![licence: MIT](https://img.shields.io/badge/Licence-MIT-yellow.svg)](https://opensource.org/licenses/MIT "MIT License")
+[![licence: OGL3](https://img.shields.io/badge/Licence-OGL3-darkgrey "licence: Open Government Licence 3")](https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/)
+
 
 > **This material is maintained by the [NHS Digital Data Science team](mailto:datascience@nhs.net)**.
 >

docs/acknowledgements.md

@@ -9,6 +9,6 @@ The **NHS Digital Data Science Skilled Team** has been the core of this work, bu
 | [Helen Richardson](https://github.com/helrich)|[Jonny Laidler](https://github.com/JonathanLaidler) |[Harriet Sands](https://github.com/harrietrs)  |  [Maakhe Ndhlela](https://github.com/maakhe)|
 |:----------------------------------|:-----|:----|:---|
 | __[Connor Quinn](https://github.com/connor1q)__|__[Alistair Jones](https://github.com/alistair-jones)__ |__[Daniel Goldwater](https://github.com/DanGoldwater1)__ | __[Joseph Wilson](https://github.com/josephwilson8-nhs)__|
-| __[Philip Hoang Le](https://github.com/philip-le)__ |__[Sam Hollings](https://github.com/SamHollings)__ |__[Abbie Prescott](https://github.com/abbieprescott)__ | |
+| __[Philip Hoang Le](https://github.com/philip-le)__ |__[Sam Hollings](https://github.com/SamHollings)__ |__[Abbie Prescott](https://github.com/abbieprescott)__ |__[Xiyao Zhuang](https://github.com/xiyaozhuang)__ |
 
 **You guys really put the "champion" in RAP Champion!!!**

docs/example_RAP_CoP_page.md

@@ -0,0 +1,113 @@
+# Page Template
+
+## Some introductory subtitle
+
+!!! tip "TLDR"
+    - **very brief** summary of the main findings
+    - any key links i.e. to forms or other things people need fill in
+    - try to keep it to just three
+
+??? question "Why should we care?"
+    - Brief summary of why this is important
+    - any key links of background
+    - We can have a bigger section on this below
+
+??? success "Pre-requisites"
+    * Some information on what someone might need to be familiar with before they can use this page
+
+    |Pre-requisite | Importance | Note |
+    |--------------|------------|------|
+    |[Some link to some other guide we have](https://nhsdigital.github.io/rap-community-of-practice/)|Necessary/Helpful|Any comment we have on this|
+    |some other guide|Helpful|another note|
+
+!!! info inline end
+    XKCD comics can also be great at grabbing attention:
+
+    ![An amusing comic about marketing](https://imgs.xkcd.com/comics/immune_system.png "An amusing comic about marketing")
+
+**Don't forget to update the `mkdocs.yml` file to add this page, so it appears in the nav bar!**
+
+Here we need some bit explaining the background of the thing the page is talking about
+
+- keep it brief
+- make it clear what it is and what the benefit is
+- don't go into details of the methods, but perhaps highlight some of the key approaches described below
+
+## First subtitle of the main content
+
+Talk about the issue  break it down into steps.
+
+We might even include a little diagram:
+
+```mermaid
+graph LR
+    A[Have an idea] --> B{Make a page};
+    B -->|Pull Request| C[Colleagues Review];
+    C --> D[Feedback];
+    D --> B;
+    B ----->|Approved| E[Publish!];
+```
+
+Consider linking to other pages and try and extract the general concept from language specific implementations, i.e. we could have a pager about "functions", and then link to specific pages on how to do functions in Python and R.
+
+Also, have a look on the following pages to see if they have guidance we could link to, or adapt
+- [Quality Assurance of Code for Analytics](https://best-practice-and-impact.github.io/qa-of-code-guidance/intro.html)
+- [Turing Way](https://the-turing-way.netlify.app/welcome.html)
+- [Central RAP Guidance from GSS](https://analysisfunction.civilservice.gov.uk/support/reproducible-analytical-pipelines/)
+
+## General subsection template
+
+Write some content here
+
+### General subsubsection template
+
+This might be on some specific aspect of the subsection
+
+#### General subsubsubsection template
+
+We might need to get even more specific, but probably wont use this as much!
+
+## Further subtitles
+
+You can include code snippets `inline` or in blocks:
+
+```Python
+    print("hello world")
+```
+
+You might also want to hide large code snippets:
+
+??? example "Some big code snippet"
+    ```Python
+    print("HA, I lied, it's only a small code snippet")
+    ```
+
+!!! note
+    Admonition blocks can be helpful to bring out key points
+
+    See [mkdocs guidance]()
+
+## Further subsections
+
+Continue to work through the subject, but we don't have to make the pages long -  a short page can be just as useful!
+
+You can include pictures, however referencing them requires a few steps back in the directory tree (see below):
+
+![image-alt-text](images/add_file.PNG "Some random picture")
+
+You can also have tabs:
+
+=== "Tab 1"
+    We can put whatever we want in here
+    ```Python
+        def somefunc(a):
+            return None
+    ```
+
+=== "Tab 2"
+    And in here something completely different, such as a diagram
+    ![alt text](images/branch_info.JPG "Some random picture")
+
+## Useful Links
+
+- Provide any useful links people might need to further their learning

docs/implementing_RAP/accessibility-how-to.md

@@ -8,12 +8,13 @@ Accessibility regulations have been implemented for all public sectors and gover
 > **See the [NHS "digital service manual"](https://service-manual.nhs.uk/accessibility) on accessibility and why it matters**.
 
 We follow suit at NHS Digital, building up on government accessibility directives, releasing and maintaining a wide range of NHS services and products, encompassing accessibility standards in each project development's phase:
-* **product and delivery:** including the questions product or delivery managers need to be asking.
-* **user research:** from identifying target groups and accessibility challenges to including users with access needs in research and practicalities like making your research sessions more accessible on the day.
-* **content:** how to write effective, clear content as well as headings, good link names, handling images in content and making multimedia accessible.
-* **design:** it includes, for example, colour contrast, designing new components (only after you've tested existing ones) and handling errors in forms.
-* **development**, including information on how to make your service accessible for those who can’t use a mouse or trackpad and rely on keyboards or joysticks.
-* **testing:** different kinds of testing (user research, manual and automated) and the wide range of things that may need checking.
+
+- **product and delivery:** including the questions product or delivery managers need to be asking.
+- **user research:** from identifying target groups and accessibility challenges to including users with access needs in research and practicalities like making your research sessions more accessible on the day.
+- **content:** how to write effective, clear content as well as headings, good link names, handling images in content and making multimedia accessible.
+- **design:** it includes, for example, colour contrast, designing new components (only after you've tested existing ones) and handling errors in forms.
+- **development**, including information on how to make your service accessible for those who can’t use a mouse or trackpad and rely on keyboards or joysticks.
+- **testing:** different kinds of testing (user research, manual and automated) and the wide range of things that may need checking.
 
 > **Find out more on how NHS Digital works on [making digital services accessible](https://digital.nhs.uk/blog/transformation-blog/2019/making-digital-services-accessible)**.
 

docs/implementing_RAP/how-to-publish-your-code-in-the-open.md

@@ -71,3 +71,5 @@ Once a new publication's repository is published on GitHub, feel free to update
 - [Be open and use open source](https://www.gov.uk/guidance/be-open-and-use-open-source)
 - [The benefits of coding in the open](https://gds.blog.gov.uk/2017/09/04/the-benefits-of-coding-in-the-open/)
 - [Open source repositories by the Government Digital Service](https://github.com/alphagov)
+
+*NHS Digital is not affiliated with any of these websites or companies.*

docs/implementing_RAP/updating-your-published-code.md

@@ -0,0 +1,137 @@
+# How to update your published code
+
+## Introduction
+
+!!! tip "TLDR"
+
+    - Update your published code as often as you feel the need to (managers
+      discretion)
+    - Keep the [publishing code checklist][1] in mind, though its up
+      to your manager if a full check is required
+    - A **`publish` branch** and **merge requests** helps you check
+      only what has changed, **saving time**
+    - when approved you can move your code over to the public repo
+    ([see the existing guidance][2])
+    - consider using [releases][5], [semantic versioning][4] and
+    [CHANGELOG.md][6]
+
+??? question "Why should we care?"
+
+    - Hopefully, all of our published code will be updated someday
+    - on that day you might need this guidance
+
+??? success "Pre-requisites"
+
+    |Pre-requisite | Importance | Note |
+    |--------------|------------|------|
+    |[Publishing Code in the Open][1]]|Necessary|You need to have done this before, or at least understand the process|
+    |[Intro to Git](..\training_resources\git\intro-to-git.md)|Necessary|There will be some use of GitHub and GitLab so knowing about Git is needed|
+
+After you've [published your code][1] for the first time, you may go on to do subsequent additions, changes and updates to the codebase held in our internal "development" repositories. It will then be time to update the code that has been published.
+
+!!! info "NHS Digital colleagues"
+
+    See our internal confluence pages on [**"Git, GitLab and GitHub"**][3] which explains our internal setup.
+
+This is pretty straightforward and follows the same process as described in
+"[Publishing Code in the Open][1]", however hopefully the guidance here will
+help you save time.
+
+![xkcd comic update](https://imgs.xkcd.com/comics/update.png "comic showing
+someone ignoring a critical update which prevents random laptop fires due
+it requiring a laptop restart")
+
+## How to do the update
+
+If you're developing your code on a private repo (either **GitLab** or 
+**Github**), it's a good idea to keep a branch on your "`development`" repo
+which is **identical** to your public "`publish`" repo. This means that you can
+easily see what changes there are between your published code and the "main"
+branch of your development repo.
+
+This means that when you are ready to update your published code:
+
+**First**, in your private repo:
+
+=== "GitHub"
+
+    1. do a `pull-request` (a.k.a. `merge`) from your `main` branch into your 
+    `publish` branch ![pull request button](../images/pull-request-button.jpg 
+    "picture showing the pull request button")
+
+    2. if required by your manager, go through the 
+    "[Publishing Code in the Open][1]" process and checklist
+
+           - focus on just the things in the `pull-request' that have
+           **changed** ![files changed button](../images/pull-request-files-changed-button.jpg "picture showing the pull request files changed button")
+
+    3. when you're happy with the changes and they have been **"approved"** in
+    the `pull-request` you can move the code from `publish` branch to the
+    public repo ([see the existing guidance][2])
+
+=== "GitLab"
+
+    1. do a `merge-request` (a.k.a. `merge`) from your `main` branch into your
+    `publish` branch ![pull request button](../images/gitlab merge request button.jpg "picture showing the pull request button")
+
+    2. if required by your manager, go through the 
+    "[Publishing Code in the Open][1]" process and checklist
+
+           - focus on just the things in the `merge-request' that have **changed**
+           ![files changed button](../images/gitlab merge request changes button.jpg "picture showing the pull request files changed button")
+
+    3. when you're happy with the changes and they have been **"approved"** in the
+    `merge-request` you can move the code from `publish` branch to the public repo
+    ([see the existing guidance][2])
+
+It's good practice to make a new branch and do a `pull-request` in your public 
+repo too, but you could also just make the changes durectly to the `main` branch
+of the public repo.
+
+## Versioning and Changelogs
+
+When you update your code, you've done the pull request, and it's all ready to
+be moved over to the public repo, it's a good time to tag the repo with a 
+[semantic version][4] (in GitHub this can be done using the ["release"][5]
+functionality). You could also maintain a [`CHANGELOG.md`][6] so users can easily
+see what has changed since your last version release.
+
+If you do a release with a version in the private repo, **make sure you also 
+release with the same version tag on the public repo**.
+
+## How often to update the published code?
+
+!!! tip "Main Points"
+
+    - ultimately it's up to the person who "owns" the codebase and the needs 
+    of the stakeholders
+    - small changes can probably be batched up and then the published code 
+    updated less frequently
+
+Each codebase (for a publication, package or whatever) will be different and
+will need changing at different rates, decided by the needs of the stakeholders,
+available resources and the person in charge of that codebase. 
+
+For example, for an annual publication, if some changes are made, might not be 
+necessary to update the existing published codebase immediately, especially if 
+they're small, minor fixed. However, If it's an important, change such as a new 
+feature (i.e. some new metric) then it would probably help any stakeholders to 
+see that published as soon as possible.
+
+## Useful Links
+
+- [GitHub pull requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests "guidance on github pull requests")
+- [GitLab merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/)
+- [GitHub Releases][5]
+- [Semantic Versioning][4]
+- [Keep a changelog][6]
+
+*NHS Digital is not affiliated with any of the websites or companies linked to 
+above.*
+
+[1]: how-to-publish-your-code-in-the-open.md
+[2]: how-to-publish-your-code-in-the-open/#moving-your-code-to-the-nhs-digital-github
+[3]: https://nhsd-confluence.digital.nhs.uk/pages/viewpage.action?spaceKey=KH&title=Github+-+publishing+your+code
+[4]: https://semver.org/
+[5]: https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository
+[6]: https://keepachangelog.com/en/1.0.0/