Merge pull request #34 from Niodus/update

ran linter to remove whitespace

Author: idmac75

.markdownlint.yaml

@@ -0,0 +1,10 @@
+# Autoformatter friendly markdownlint config (all formatting rules disabled)
+default: true
+blank_lines: false
+bullet: false
+html: false
+indentation: false
+line_length: false
+spaces: false
+url: false
+whitespace: false

.trunk/.gitignore

@@ -0,0 +1,4 @@
+*out
+*logs
+plugins
+user_trunk.yaml

.trunk/trunk.yaml

@@ -0,0 +1,10 @@
+version: 0.1
+cli:
+  version: 0.16.1-beta
+lint:
+  enabled:
+    - actionlint@1.6.16
+    - git-diff-check@SYSTEM
+    - gitleaks@8.11.0
+    - markdownlint@0.32.2
+    - prettier@2.7.1

LICENSE.md

@@ -1,4 +1,4 @@
-MIT License
+# MIT License
 
 Copyright (c) [2022] [Scott McCarthy]
 

docs/about.md

@@ -1,44 +1,12 @@
-# Pallor lacertos
+---
+title: About
+summary: About the Author
+author: Scott McCarthy
+date: 18/08/2022
+---
 
-## Avidae Pleuronius vetus soceri hominesque semina
+Welcome to my DevOps page. My name is Scott McCarthy and I am a professional DevOps engineer.
 
-Lorem markdownum Nesseo si clamat iussit plangoris boumque! Convexa vocem:
-remotus, fugientem augustae pariter luco mensae flexit: a ad ero. Peliden
-protinus ventis mira ministerio, Aeetias refugitque thalamoque conspexi fiunt
-Bacchiadae manus tumulo. Ferre omnis viventi pulsant hora sinit tardi non;
-aeternamque terra **mediique**; sed adest cum quibus? [Aut
-adspicit](http://www.nebulas.com/neveunda) aquarum funduntur, oris paulatim
-rapidas in inquit pharetra undas emisit, sumpta nunc; speciosa.
+I love to help people with their technology challenges, particularly in the DevOps space so decided the best way I can help is to capture my knowledge in the form of a Wiki.
 
-- Subit at clade
-- Vosne invitis quaeras quid lactis senectam murmur
-- Extendit curvantem mutati Niobe iuncti nos excipit
-- Inpetus quos membra iacentia Tantalus sceptri imbres
-- Velut pedem
-- Narrare neque unum coniunx suorum
-
-## Palato sanguine parvo ne caterva cursus
-
-Attonitus fratrisque nescio strage. Omnibus ipso. Adsum et deos veteremque tuos
-gravitate non Styga perbibit Aonidum qua sentiet laboris et tamen *mediis*.
-
-1. Neque Solis
-2. Meritis potest curae Pirithoum ac mihi Annus
-3. Et cognoscere iacit consequitur et fretum fatisque
-
-## Cecinisse Cynthia est perit lanugine
-
-Nam *atque invidiam*, semper *ille manus colorem* arcus mentitis. Suco aquis
-duorum Hylonome neque; illic sed hominum, scelerum.
-
-Hominis flumina tollit, unguibus in nunc, donec fixa este abibas tamquam. Vesana
-Noctem cogeris castumque tympana misera me numina longius sit *ferebam*
-Corinthiaci sua valebam, licere Morphea, gratulor. Petis ministros amantis.
-Labentibus legit dum Achilles non inmoritur, ipse deducere, nec. Ignibus est
-stillataque: aestus perluit obverterat Actaeas eripiam pictis in comitem
-**obortae vellet**: sepulcri de locus nulla.
-
-Medusae radice: anilem movebatur tanta, ab non mirabile tauros et dempto.
-Geminatis vivatis nulla, alii pro sentiet tamen fixa? Navigat plura
-exspectatoque Inachides inmansuetusque sororis, vix victrix; nisi ille diuque
-quae est.
+If you would like to know more about me, then please see my [LinkedIn page Bio](https://www.linkedin.com/in/scott-mccarthy-7747a820/)

docs/best-practices/continuous-planning/agile-development/sprint-planning.md

@@ -1,88 +1,88 @@
----
-title: Sprint Planning
-summary: A guide to sprint planning
-author: Scott McCarthy
-
----
-## Overview
-
-During the [sprint planning](https://www.agilealliance.org/glossary/sprint-planning), the team discusses and agrees on the scope for the upcoming sprint.
-
-## Goals
-
-- Select the **stories** that will be implemented in the sprint.
-- Estimate the **effort** required for the stories in the sprint.
-- Split the stories into **tasks**.
-
-General guidance:
-
-- The sprint planning should happen at the beginning of the new sprint (or at the end of the previous one). It usually lasts between 1 and 4 hours depending on the size of the team and duration of the sprint.
-- Each story should be able to be completed within the duration of the sprint. Otherwise, the story should be broken up into multiple stories.
-- Each task duration should be somewhere between 2 and 8 hours.
-
-## Participation
-
-**Everyone** in the team should participate in the sprint planning, including the Product Owner.
-
-Specific roles:
-
-[**The ScrumMaster**](https://www.agilealliance.org/glossary/scrum-master/):
-
-- Facilitate the conversation.
-- Ensure everyone is heard.
-- Remind scrums/agile/other principles and sprint planning goals if necessary, updating the working agreement where needed to ensure a mapping between principals and what is working/not working for the team.
-
-[**Product owner**](https://www.agilealliance.org/glossary/product-owner/):
-
-- Prior to the sprint planning: performs some [backlog refinement](backlog-management.md#backlog-refinement) to ensure that each story that they want to propose for the new sprint (*)  
-- Is in the correct position in the backlog, by right priority order.
-- Is attending the [definition of ready](team-agreements/definition-of-ready.md)- Do NOT pre-assign stories to the future sprint. This is the purpose of the sprint planning.
-- During the meeting:
-  - Clarify team's questions and improve the story accordingly, if necessary.
-  - Describe to the team the stories that they propose for the sprint.
-  
-**All team members**:
-
-- Listen to the product owner story description.
-- Ask questions to make sure everyone understands each story properly.
-- [Estimate](sprint-planning/estimation.md) the effort for each backlog item, as a team.
-- Split each story into tasks.
-- (Optional) self assign first task to team members.
-
-*(\*) some teams find useful to define a **[Definition of ready](team-agreements/definition-of-ready.md)** that describes the list of things that needs to be done in each story before the **product owner** can propose it for a **sprint**. The list proposed here is the classic minimal definition of ready.*
-
-## Impact
-
-Sprint planning key benefits:
-
-- Everyone participates, the entire team is aware of the scope of the sprint.
-- The team has an agreement on the goal of the sprint.
-- Each team member takes responsibility in the sprint scope by participating in the story's discovery, prioritization and estimation.
-- Creates a channel to communicate, discover and discuss dependencies.
-
-## Measures
-
-- How many stories needed more work before being presented (and were rejected because they were not clear enough)?
-- How realistic was the estimation of effort?
-- Team satisfaction (can be assessed during the retrospective): does everyone in the team feel included in sprint planning?
-
-## Facilitation Guidance
-
-Prior to the meeting:
-
-- Set sprint goal.
-- Make sure the backlog is prioritized.
-- Make sure each story that is a candidate for next sprint is [ready](team-agreements/definition-of-ready.md).
-
-During the meeting:
-
-- Confirm team capacity. This should be done using the average velocity (number of points achieved per sprint) and removing the project vacations/holidays/off days. If it helps, you can get the daily average velocity, divide by the number of team members and multiply by number of off days.
-- Timebox (for instance: half of the meeting for story selection, half of the meeting for task splitting).
-- Agree on how much capacity needs to be "saved" for bug fixing (might depend on the sprint).
-- Ensure everyone understands each story that is selected for the sprint.
-- Ensure everyone participates in story effort estimation.
-
-Other considerations:
-
-- Take into account off days (vacations, national holidays, unavailability).
-- When the backlog reaches a size that makes it difficult to manage by one team, you might want to split into different work streams. This might require thinking about [scrum of scrums](scrum-of-scrums.md) and all related ceremonies.
+---
+title: Sprint Planning
+summary: A guide to sprint planning
+author: Scott McCarthy
+---
+
+## Overview
+
+During the [sprint planning](https://www.agilealliance.org/glossary/sprint-planning), the team discusses and agrees on the scope for the upcoming sprint.
+
+## Goals
+
+- Select the **stories** that will be implemented in the sprint.
+- Estimate the **effort** required for the stories in the sprint.
+- Split the stories into **tasks**.
+
+General guidance:
+
+- The sprint planning should happen at the beginning of the new sprint (or at the end of the previous one). It usually lasts between 1 and 4 hours depending on the size of the team and duration of the sprint.
+- Each story should be able to be completed within the duration of the sprint. Otherwise, the story should be broken up into multiple stories.
+- Each task duration should be somewhere between 2 and 8 hours.
+
+## Participation
+
+**Everyone** in the team should participate in the sprint planning, including the Product Owner.
+
+Specific roles:
+
+[**The ScrumMaster**](https://www.agilealliance.org/glossary/scrum-master/):
+
+- Facilitate the conversation.
+- Ensure everyone is heard.
+- Remind scrums/agile/other principles and sprint planning goals if necessary, updating the working agreement where needed to ensure a mapping between principals and what is working/not working for the team.
+
+[**Product owner**](https://www.agilealliance.org/glossary/product-owner/):
+
+- Prior to the sprint planning: performs some [backlog refinement](backlog-management.md#backlog-refinement) to ensure that each story that they want to propose for the new sprint (\*)
+- Is in the correct position in the backlog, by right priority order.
+- Is attending the [definition of ready](team-agreements/definition-of-ready.md)- Do NOT pre-assign stories to the future sprint. This is the purpose of the sprint planning.
+- During the meeting:
+  - Clarify team's questions and improve the story accordingly, if necessary.
+  - Describe to the team the stories that they propose for the sprint.
+
+**All team members**:
+
+- Listen to the product owner story description.
+- Ask questions to make sure everyone understands each story properly.
+- [Estimate](sprint-planning/estimation.md) the effort for each backlog item, as a team.
+- Split each story into tasks.
+- (Optional) self assign first task to team members.
+
+_(\*) some teams find useful to define a **[Definition of ready](team-agreements/definition-of-ready.md)** that describes the list of things that needs to be done in each story before the **product owner** can propose it for a **sprint**. The list proposed here is the classic minimal definition of ready._
+
+## Impact
+
+Sprint planning key benefits:
+
+- Everyone participates, the entire team is aware of the scope of the sprint.
+- The team has an agreement on the goal of the sprint.
+- Each team member takes responsibility in the sprint scope by participating in the story's discovery, prioritization and estimation.
+- Creates a channel to communicate, discover and discuss dependencies.
+
+## Measures
+
+- How many stories needed more work before being presented (and were rejected because they were not clear enough)?
+- How realistic was the estimation of effort?
+- Team satisfaction (can be assessed during the retrospective): does everyone in the team feel included in sprint planning?
+
+## Facilitation Guidance
+
+Prior to the meeting:
+
+- Set sprint goal.
+- Make sure the backlog is prioritized.
+- Make sure each story that is a candidate for next sprint is [ready](team-agreements/definition-of-ready.md).
+
+During the meeting:
+
+- Confirm team capacity. This should be done using the average velocity (number of points achieved per sprint) and removing the project vacations/holidays/off days. If it helps, you can get the daily average velocity, divide by the number of team members and multiply by number of off days.
+- Timebox (for instance: half of the meeting for story selection, half of the meeting for task splitting).
+- Agree on how much capacity needs to be "saved" for bug fixing (might depend on the sprint).
+- Ensure everyone understands each story that is selected for the sprint.
+- Ensure everyone participates in story effort estimation.
+
+Other considerations:
+
+- Take into account off days (vacations, national holidays, unavailability).
+- When the backlog reaches a size that makes it difficult to manage by one team, you might want to split into different work streams. This might require thinking about [scrum of scrums](scrum-of-scrums.md) and all related ceremonies.