# Participating Safely on GitHub

This guide explains **how to participate in a GitHub repository safely and intentionally**, without software development experience and without risk to systems or records.

Participation on GitHub is **deliberate, reviewable, and reversible**.

---

## A note before you begin

You cannot accidentally:
- Change production systems
- Deploy software
- Modify files without review
- Hide changes from history

Everything described below is **non-destructive by default**.

---

## 1. Reading content (zero risk)

You can safely:
- Read files
- Navigate folders
- Follow links
- Share links with others

Reading content:
- Does not notify repository owners
- Does not require an account
- Does not create or modify records

This is the most common and safest form of engagement.

---

## 2. Creating an Issue (asking a question or raising a concern)

An **Issue** is a structured discussion.

Issues are commonly used to:
- Ask questions
- Request clarification
- Suggest improvements
- Flag concerns or gaps
- Track discussion topics

### What happens when you create an issue
- No files are changed
- Nothing is approved or rejected
- Discussion is visible and attributable
- Context is preserved over time

Issues are often the **preferred starting point** for engagement.

---

## 3. Suggesting an edit (browser-based, no local tools)

GitHub allows you to suggest edits **directly in the browser**.

Typical flow:
1. Open a file
2. Select **Edit**
3. Make a proposed change
4. Submit the suggestion

This creates a **proposed change**, not an approved one.

### Important clarification
- Your suggestion does **not** modify the repository
- The change must be reviewed before acceptance
- Discussion can occur before any decision

This is similar to “track changes” in document review.

---

## 4. Forking a repository (making your own copy)

A **fork** creates a personal copy of a repository under your account.

Forks are useful when:
- You want to experiment
- You want to draft changes independently
- You want a reference copy for learning

Forking:
- Does not affect the original repository
- Is reversible
- Requires no approval

The original repository remains unchanged.

---

## 5. Opening a Pull Request (requesting a change)

A **Pull Request** is a formal request to apply a proposed change.

Pull requests allow:
- Review before acceptance
- Discussion and clarification
- Explicit approval or rejection
- A permanent record of the decision

### What a pull request does *not* do
- It does not force changes
- It does not bypass review
- It does not remove accountability

Pull requests function as **review gates**.

---

## 6. Review and approval

After a proposal is submitted:
- Reviewers may ask questions
- Changes may be requested
- The proposal may be approved or declined

All outcomes are:
- Documented
- Attributable
- Preserved for future reference

No outcome occurs without intentional action.

---

## 7. Permissions and roles

Not everyone has the same permissions.

Common roles include:
- Read-only (view content)
- Commenter (participate in discussion)
- Contributor (propose changes)
- Approver (accept or reject changes)

Permissions are explicitly granted and can be revoked.

---

## 8. What happens if a mistake is made

Mistakes are:
- Visible
- Correctable
- Reversible

Prior versions remain accessible, and corrective changes can be proposed transparently.

Mistakes are expected and manageable.

---

## 9. When to pause and ask questions

It is appropriate to pause if:
- You are unsure what an action does
- You are unfamiliar with a term
- You are unclear on permissions
- You want confirmation before proceeding

Asking questions before acting is good governance.

---

## 10. Summary

Safe participation on GitHub follows a simple progression:

1. Read
2. Discuss
3. Propose
4. Review
5. Approve (or decline)

Each step is intentional, logged, and reviewable.

---

## Why this matters in government environments

Participating safely ensures:
- Accountability
- Traceability
- Transparency
- Respect for governance boundaries

GitHub supports collaboration **without requiring risk** when used intentionally.