Thank you for your interest in contributing to this workshop. This guide covers how to submit changes and the style conventions for lab content.
-
Fork the repository.
-
Create a feature branch from
main:git checkout -b feature/your-change-description
-
Make your changes following the style guide below.
-
Test locally by running
bundle exec jekyll serveand verifying links and formatting. -
Submit a pull request targeting
mainwith a clear description of your changes.
- Use second-person voice ("you", "your") to address the student directly.
- Use present tense and active voice.
- Keep instructions concise and action-oriented.
Every lab follows this structure:
# Lab XX — Title
## Objectives
- Objective 1
- Objective 2
## Prerequisites
- Prerequisite 1
## Steps
### Step 1: Description
Instructions...
### Step 2: Description
Instructions...
## Checkpoint
Verification criteria...
## Summary
What the student learned...
## Next Steps
Link to the next lab...- Always specify the language in fenced code blocks (
powershell`,bash, ````yaml, ````bicep`). - Use
powershellfor PowerShell commands andbashfor shell commands. - Include expected output when it helps the student verify their work.
Use GitHub alert syntax for tips, warnings, and notes:
> [!NOTE]
> Additional context the student should know.
> [!TIP]
> Helpful shortcut or best practice.
> [!WARNING]
> Something that could cause issues if ignored.
> [!IMPORTANT]
> Critical information the student must follow.- Place screenshots in
images/lab-XX/directories. - Name files descriptively:
lab-02-psrule-output.png,lab-06-security-tab-filters.png. - Reference using relative paths:
. - Use the
scripts/capture-screenshots.ps1script for automated captures when available.
- Use relative links for cross-references between labs.
- Link to external documentation by URL with descriptive text.
Open an issue describing the problem, including which lab and step number is affected. Include error messages and your environment details (OS, tool versions).