GitHub for Non-Technical Staff

You don’t need to be a developer to use GitHub effectively. At Cadence OneFive, GitHub is where our code lives, but it’s also where we track work, collaborate on documentation, and manage our handbook. This guide covers everything you need to participate confidently.

What GitHub Is and Why We Use It

GitHub is a platform for storing code, tracking work, and collaborating on changes. We use it for:

• Code repositories — where our product (Momentum) and other projects live
• Issues — our ticket system for tracking all work (features, bugs, tasks)
• Pull requests (PRs) — how changes get proposed, reviewed, and approved
• GitHub Projects — our board for organizing and visualizing work across sprints
• This handbook — the source files live in a GitHub repository

Even if you never touch code, you’ll interact with GitHub issues, read PRs, and contribute to the handbook.

For a thorough introduction to GitHub’s interface, see GitHub’s official getting started guide.

Getting Access

During onboarding, you’ll be asked for your GitHub username. If you don’t have one, create a free account at github.com.

All permanent staff are added to the All Perm Staff team, which gives you access to the handbook repository. Developers are added to additional teams based on their role. Access follows the principle of least privilege — you get what you need for your job, and nothing more. See the GitHub Access Policy for the full breakdown.

Two-factor authentication is required. Set this up on your GitHub account before your first day if possible. GitHub’s guide: Configuring two-factor authentication.

Your Onboarding Issue

When you join, a GitHub issue is created from our onboarding template to track your progress. This is covered in the New Hire Guide, but here’s what you need to know about interacting with it:

• Check off items as you complete them by clicking the checkbox in the issue description
• Add comments to note blockers, questions, or context
• Keep it current — an up-to-date issue signals engagement; a stale one raises flags
• Bring it to every mini-360 as your progress report

This is your first real interaction with GitHub, and it’s a good way to get comfortable with the interface.

Our Ticket System: GitHub Issues

All work at Cadence OneFive is tracked as GitHub Issues — if you hear someone say “ticket,” they mean a GitHub issue. We use GitHub Projects as our board to visualize what’s in progress across the team.

You don’t need to know the full development workflow, but it helps to know that tickets range from Features (large bodies of work) down to Tasks (specific technical work) and Bugs (something broken, prioritized P0 through P3). For the full lifecycle and ticket types, see the Software Development Lifecycle.

Filing a Bug

The most common reason non-technical staff create issues is during Testing Tuesdays. When you find something:

1. Search existing issues first to avoid duplicates
2. Click New Issue in the appropriate repository
3. Select the Bug template
4. Describe what you saw, what you expected, and the steps to reproduce it — the more specific, the faster it gets fixed
5. Let the team know in the relevant Discord channel

Reading Issues and PRs

You may want to follow along with work that affects your area. A few tips:

• Go to github.com/CadenceOneFive and click the Issues tab on any repo to browse tickets
• Pull requests (PRs) are proposals to change code or content — read the description to understand what changed and why, or comment if you have relevant context
• For more on navigating issues, see GitHub’s guide to filtering issues

Contributing to the Handbook

The handbook is the most common way non-technical staff interact with GitHub directly. Every page has an “Edit this page” link at the bottom that takes you to the GitHub editor. The full process — creating branches, pull requests, and getting reviews — is documented in Contributing to the Handbook.

Testing Tuesdays

Every Tuesday, everyone in the company tests the product — regardless of role. This is where non-technical staff often encounter bugs that need to be filed as GitHub issues. When you find something:

1. Check if an issue already exists (search first)
2. If not, create a Bug issue with steps to reproduce

Linking GitHub to Discord

Connect your GitHub account to our Discord server so you get notified about PR activity:

1. In Discord, use the command /link your-github-username (pingbot)
2. Use /whoami to verify your link
3. Use /unlink to remove the connection

Key Terminology

Term	Meaning
Repository (repo)	A project folder containing code, docs, or both
Branch	A separate copy of the code where changes are made before merging
Commit	A saved set of changes with a description
Pull request (PR)	A request to merge changes from one branch into another
Merge	Combining changes from a PR into the main codebase
Issue	A ticket tracking a piece of work, bug, or request
Milestone	A release target that groups related issues

For a more complete glossary, see GitHub’s glossary.

Getting Help

• Ask in Discord — post questions in #ask-anything or your team channel
• Ask a teammate for a walkthrough of your first contribution
• GitHub’s own docs are excellent: docs.github.com