Workflows Update

.github/ISSUE_TEMPLATE/bug.yml

@@ -0,0 +1,41 @@
+name: Bug Report
+description: Report something not working with the project's code.
+type: Bug
+labels: [bug]
+# See https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-githubs-form-schema
+body:
+  - type: markdown
+    attributes:
+      value: >
+        Thank you for helping us by reporting a bug issue!
+        Help us help you get things fixed.
+  - type: textarea
+    id: what-happened
+    attributes:
+      label: What happened?
+      description: Also, what did you expect to happen?
+      placeholder: Tell us what you see!
+    validations:
+      required: true
+  - type: input
+    id: version
+    attributes:
+      label: What version of our software are you running?
+      placeholder: "I don't know..."
+      description: >
+        It can really help if you let us know what version of our software you are using.
+        Sometimes the fix to the bug has already been implemented and all that is needed is an update, but this will let us know for sure.
+  - type: textarea
+    id: environment
+    attributes:
+      label: Where were you running our software?
+      description: >
+        Operating system, browser, shell, anything to help us know what environment our software is (not) working within.
+        Sometimes, this is vital.
+  - type: textarea
+    id: logs
+    attributes:
+      label: Relevant log output
+      description: >
+        Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.
+      render: shell

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,5 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Security Problems
+    url: https://www.itservices.manchester.ac.uk/help/connect/
+    about: Security problems should be reported via Connect.

.github/ISSUE_TEMPLATE/feature.yml

@@ -0,0 +1,28 @@
+name: Feature Request
+description: >
+  A request for a new feature to be added, for the software to do something that it did not previously do. Typically will take the form of a "User Story" and hence assumes that issue type.
+type: Feature
+labels: ["user story"]
+body:
+  - type: markdown
+    attributes:
+      value: >
+        Thank you for making a suggestion of something new we should do.
+        Usually, the more detail you can provide about what you think we should do, the easier it is to implement.
+  - type: textarea
+    id: requested-feature
+    attributes:
+      label: What are you asking for
+      description: >
+        Please describe what it is you want.
+      placeholder: More information usually helps here.
+    validations:
+      required: true
+  - type: input
+    id: version
+    attributes:
+      label: What version of our software are you running?
+      placeholder: "I don't know..."
+      description: >
+        It can really help if you let us know what version of our software you are using.
+        Sometimes, features may already exist in later versions and all that is needed is an update, but this will let us know for sure.

.github/ISSUE_TEMPLATE/task.yml

@@ -0,0 +1,22 @@
+name: New Task
+description: A request for something to be done that isn't really a bug fix or a new feature.
+type: Task
+labels: ["task"]
+body:
+  - type: markdown
+    attributes:
+      value: >
+        We know not all things to do with a repository are clearly bug fixes or new features.
+        Life isn't that simple.
+        If you need to ask for anything else, this is for you.
+  - type: textarea
+    id: task
+    attributes:
+      label: What do you want us to do?
+      description: >
+        What is this task to be about?
+        Please provide us with as much information as you think is relevant.
+      placeholder: >
+        I would like you to hop on one foot and let slip the doves of peace!
+    validations:
+      required: true

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,48 @@
+---
+name: Pull Request
+about: For submitting a code change.
+---
+
+<!--
+Hi there!
+
+Thanks for helping to contribute to this repository.
+Your contribution is very much appreciated.
+
+Donal Fellows (@dkfellows) on behalf of University of Manchester Research Software Engineering.
+-->
+
+<!--
+Here's a few things to think about when writing a PR; feel free to edit things around.
+-->
+
+## Issue Description
+
+<!-- These are things to put in the main description of the PR. Also pick a pithy title! -->
+
+### What Issue does this PR fix?
+Is this fixing an issue? If so, please `#ref` its ID. This helps a lot!
+<!-- An issue is not required for submitting a PR, but it is strongly encouraged for all but the most trivial of fixes (like a spelling mistake in the README). -->
+
+For extra magic, write that reference as this sentence: `This fixes #ref.` or this `Closes #ref.`
+This causes the PR to _automatically_ close the referenced issue when merged.
+
+### What does this PR do?
+What do you think this PR does? We can see what it _actually_ does by reading the code,
+but it's very helpful to have a short description of what you _intend_ it to do.
+
+### Do you know who could review this PR?
+Don't forget to Request a Review from a team member when this PR is ready.
+<!-- If you know it's going to take quite a bit more work before it is ready for review, consider making this a Draft PR instead, via the dropdown on the Submit button. -->
+
+## Standard Review Checklist for _Authors_
+<!-- These do not all apply to every PR, and some are easy YESes. You don't have to get everything on the list ticked off, but it's a very good starting point for a top-quality feature change. -->
+<!-- If you can change these checklist items to be something checked automatically instead of manually, so much the better. If you've got that working, you might be able to remove them from the checklist and make them Required workflow checks instead. -->
+- [ ] Does the code change do what it is claimed to do? <!-- Keeping PRs small makes this easier. -->
+- [ ] Is the code change able to be built? <!-- Whatever that means for the particular case. -->
+- [ ] Is the code change tested? <!-- Testing is a complex topic... -->
+- [ ] Is the code change documented? <!-- Particularly important for API changes. -->
+- [ ] Does the code change follow the repository's style guide, if there is one? <!-- Internal consistency aids readability and reviewability. -->
+<!-- Adding more items to this checklist is fine, but it adds friction for both developing and reviewing. -->
+
+The [RSE handbook](https://livemanchesterac.sharepoint.com/:b:/r/sites/UOM-ITS-Research-IT/Shared%20Documents/RSE%20Team/Read-Only/Policies%20and%20Processes/RSE_Agile_Methods_Handbook.pdf?csf=1&web=1&e=CNE4Nm) has further guidance to reviewers.

.github/workbench-docker-version.txt

@@ -0,0 +1 @@
+v0.2.8