Pull Request Guidelines
PR Title Convention
Use conventional commit format with priority labels:feat- New featurefix- Bug fixdocs- Documentation onlyrefactor- Code restructuring without behavior changetest- Adding or updating testsstyle- Code style changes (formatting, etc.)perf- Performance improvementschore- Maintenance tasks, dependencies
[P1]- Critical: Security issues, broken features, blocking bugs[P2]- Important: Significant improvements, major bugs, essential docs[P3]- Enhancement: Nice-to-have features, optimizations, minor fixes
PR Description Template
Every PR should include these sections:Before Submitting
-
Build and Test Locally
-
Follow Code Conventions
- Review
.github/copilot-instructions.md - Review
CLAUDE.mdfor architectural patterns - Match existing code style
- Review
-
Update Documentation
- Update
CHANGELOG.mdfor user-facing changes - Update
docs/ARCHITECTURE.mdif changing patterns - Add XML doc comments for public APIs
- Update
-
Commit Messages
- Use meaningful commit messages
- Reference issue numbers where applicable
- Keep commits focused and atomic
Code Standards
C# Conventions
Namespaces:- Core library:
Intune.Commander.Core.* - Desktop app:
Intune.Commander.Desktop.* - File-scoped namespaces:
namespace Intune.Commander.Core.Services;
- Enabled everywhere
- Use
?for nullable types - Use
!null-forgiving operator sparingly
- Private fields:
_camelCase - Public members:
PascalCase - Interfaces:
IInterfaceName - Async methods: Always end with
Async
- Must be
partial classfor CommunityToolkit.Mvvm source generators - Inherit from
ObservableObject - Use
[ObservableProperty]and[RelayCommand]attributes
Graph API Patterns
Manual Pagination (Required): Never usePageIterator - it silently truncates results on some tenants.
- End with
Asyncsuffix - Return
TaskorTask<T> - Accept
CancellationToken cancellationToken = defaultas last parameter - Be
asyncall the way up (no.Result,.Wait(), or.GetAwaiter().GetResult())
UI Thread Rules
CRITICAL: Never block the UI thread.Service Implementation Pattern
Every Intune object type service follows this pattern:Testing Requirements
Unit Tests Are Required
Every new or changed code must include tests. PRs without adequate test coverage will not be merged. Coverage Requirement: 40% line coverage (enforced in CI)Unit Test Conventions
Framework: xUnit with[Fact] or [Theory]
Test Structure:
- Test class:
{ClassUnderTest}Tests - Test method:
{MethodName}_{Scenario}_{ExpectedBehavior} - Test file mirrors source structure
- Happy path
- Edge cases
- Null handling
- Exception scenarios
Mocking with NSubstitute
Important:GraphServiceClient is NOT mockable (sealed SDK). Use reflection-based contract tests for Graph services.
NSubstitute patterns:
Integration Tests
For tests that require actual Graph API calls:- Use
IntTest_AutoCleanup_prefix for created objects - Clean up in
finallyblocks - Read-only tests are safe for any tenant
Documentation Standards
Code Comments
XML Doc Comments for Public APIs:- Use
//comments sparingly - Only for complex logic that isn’t self-documenting
- Code should be self-documenting where possible
Documentation Files
CHANGELOG.md:- User-facing changes
- Release notes
- Breaking changes
- Architectural decisions
- Design patterns
- Technical constraints
- Getting started
- Build instructions
- Quick reference
- Current PR organization
- Merge order
- Dependencies
Review Process
What Reviewers Look For
- Correctness: Does it work as intended?
- Tests: Are there sufficient tests?
- Code Quality: Is it maintainable and readable?
- Documentation: Are changes documented?
- Breaking Changes: Are they necessary and documented?
- Performance: Any obvious performance issues?
- Security: No credentials, sensitive data, or vulnerabilities?
Addressing Review Feedback
- Respond to all comments
- Make requested changes or explain why not
- Push new commits (don’t force-push during review)
- Re-request review after addressing feedback
Git Workflow
Branching
Never commit directly tomain. All changes go through feature branches and pull requests.
Branch naming:
- Feature:
feature/description(e.g.,feature/wave7-scripts) - Fix:
fix/description(e.g.,fix/lazy-load-guard) - Docs:
docs/description(e.g.,docs/update-architecture)
Commit Messages
Format:Creating Pull Requests
Wave Implementation
The project uses a Wave system for implementing new Intune object types. Seedocs/issues/ for detailed tracking:
- Wave 1: Endpoint Security, Admin Templates, Enrollment
- Wave 2: App Protection, Managed App Configs
- Wave 3: Tenant Administration
- Wave 4: Autopilot, Device Management
- Wave 5: Conditional Access, Identity
Getting Help
- Questions about implementation: Check
CLAUDE.mdanddocs/ARCHITECTURE.md - Questions about PR process: See
PR_STATUS.md - Questions about code patterns: See
.github/copilot-instructions.md - Stuck on something?: Open a draft PR and ask for guidance
PowerShell Scripts
If contributing PowerShell scripts:- Use ASCII-only characters - No Unicode decorations (e.g.,
━─→✓✗○—) - Save
.ps1files with ASCII encoding - Target PowerShell 5.1+ compatibility
- Unicode breaks PowerShell 5.1 parsing
License
By contributing to Intune Commander, you agree that your contributions will be licensed under the MIT License.Related Documentation
- Architecture Overview - Core architecture decisions
- Technology Stack - Dependencies and versions
- Services - Service patterns and Graph API integration
- Testing - Testing frameworks and patterns
- Building - Build commands and development workflow