What to Submit (deliverables on OnQ)
Submit to OnQ once you finish all steps
- Live URL: link to your deployed site (to check successful launch).
- Repository link: link to your GitHub repo with code.
- Evidence of your review for your partner's website: paste the direct URL of your review on your partner’s repo, as well as two screenshot images of your comments/review. The direct URL can be either:
- Pull Request link (e.g.
https://github.com/partner-username/queens-student-page/pull/3) if you reviewed via PR - Issue link (e.g.
https://github.com/partner-username/queens-student-page/issues/5) if you used the issue template
- Pull Request link (e.g.
- Evidence of your implementation for your partner's review of your website: describe what changes your partner recommended, and how you implemented them.
Step 0: Sign in (or create a GitHub account)
~1–2 minutes
- Go to GitHub and sign in. New? Click Sign up and choose the free plan.
- Confirm your email so Pages can publish later.
- Encouraged: Apply for the GitHub Student Developer Pack. It gives free GitHub Pro and access to GitHub Copilot Chat (AI assistant) for free!
Tips & fixes
- No verification email? Check spam or click Resend verification.
- Forgot password? Use Forgot password on the sign‑in page.
- Student Pack rejected? Re‑apply with your Queen’s email and a photo of your student card.
Step 1: Create your repository
~2 minutes
Explainer: A repository (“repo”) is like a special online folder where all the code, images, and history for your project are stored. GitHub keeps track of changes over time, like a timeline.
- Click the + in the top bar → New repository.
- Name it
queens‑student‑pageand check Add a README. - Choose Public, add MIT License → Create repository.
Tips & fixes
- Repo name taken? Try
queens‑student‑page‑2025. - Private repo? GitHub Pages works only on Public (unless paid plan).
Step 2: Add your homepage
~4 minutes
Explainer: HTML is the language of web pages. It uses “tags” like <h1> for headings, <p> for paragraphs, and <img> for images. The browser reads this file top to bottom and displays it as a page.
Add a file named index.html at the root (main level) of the repo and paste this starter. The red comments show where to personalize.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>My Queen’s Student Page</title>
<link rel="stylesheet" href="style.css"/> <!-- do not change this line -->
</head>
<body>
<header>
<h1>Welcome to My Page</h1> <!-- change this heading to your name -->
</header>
<main>
<!-- ====== ABOUT SECTION (edit the text) ====== -->
<h2>About Me</h2>
<p>I am a student at Queen’s School of Computing. I’m interested in <!-- replace with interests -->.</p>
<!-- ====== PHOTO (upload me.jpg to repo root, then update the src below) ====== -->
<img src="me.jpg" alt="Your Name portrait" width="240" height="240" />
<!-- ====== PROJECTS/COURSES (add or rename items to courses instead of projects) ====== -->
<h2>Projects</h2>
<ul>
<li>Project One — one sentence description.</li>
<li>Project Two — coming soon.</li>
</ul>
<!-- ====== CONTACT (update your links) ====== -->
<h2>Contact</h2>
<p>Email: <a href="mailto:student@queensu.ca">student@queensu.ca</a></p>
<p>LinkedIn: <a href="#">add your link here</a></p>
</main>
</body>
</html>
Tips & fixes
- Where to place? The file is at the top level of your repo, not inside a folder.
- Wrong name? Must be exactly
index.html.
Step 3: Add Queen’s branding (style.css)
~3 minutes
Explainer: CSS is the language that styles your HTML. It controls colors, fonts, spacing, and layout. By separating style (CSS) from structure (HTML), it’s easier to update the look without touching the content.
Create a file named style.css (at the same level as index.html) and paste:
:root {
--red:#b90e31; --gold:#fabd0f; --blue:#002452;
}
body { font-family: system-ui, sans-serif; margin:0; background:var(--red); color:#fff; }
header { background:var(--blue); color:#fff; padding:1rem; }
main { background:#fff; color:#1a1a1a; max-width:900px; margin:2rem auto; border-radius:12px; padding:1.5rem; }
a { color: var(--blue); }
/* === personalize below by changing colors or spacing === */
/* example: make headings blue and a bit larger */
h2 { color: var(--blue); font-size: 1.6rem; }
/* example: make your photo round */
img { border-radius: 12px; }
Tips & fixes
- Not working? Ensure
<link rel="stylesheet" href="style.css">is inside<head>ofindex.html. - Colors look off? Double‑check the hex codes.
- Long code lines overflow? Scroll the code block; boxes now scroll horizontally if needed.
Step 4: Enable GitHub Pages
~3 minutes
Explainer: GitHub Pages is a free hosting service. When you enable it, GitHub takes your index.html and style.css files and serves them on the public web. That’s how your code “lives online” at a real URL.
- Go to Settings → Pages.
- Set Source → Deploy from a branch.
- Choose Branch
main, Folder/root→ Save. - Wait for the green check, then open the link.
Tips & fixes
- 404? Wait a minute and refresh.
- No URL? Confirm repo is Public and branch/folder are set.
Step 5: Personalize & publish updates
~6–7 minutes
Explainer: HTML + CSS together make your website. HTML is the “skeleton” (sections, text, images). CSS is the “skin and clothes” (colors, fonts, layout). Every change you make and commit to GitHub will trigger GitHub Pages to redeploy your live site.
You have two options:
- Manual edits: Open
index.html. Use the existing structure and follow these instructions:- Change the page title: In the
<title>tag inside<head>, replaceMy Queen’s Student Pagewith your own name. - Header with your name: Find
<h1>Welcome to My Page</h1>and replace the text with your name. - About Me: In
<main>, replace the sample paragraph with a few sentences about yourself. - Add a photo: Upload an image (e.g.,
me.jpg) to repo root. Then add:<img src="me.jpg" alt="Photo of Your Name" width="240" height="240" /> - Projects: After About section:
<h2>Projects</h2> <ul> <li>Project One — one sentence description.</li> <li>Project Two — coming soon.</li> </ul> - Contact: At bottom of
<main>:<h2>Contact</h2> <p>Email: <a href="mailto:student@queensu.ca">student@queensu.ca</a></p> <p>LinkedIn: <a href="https://linkedin.com/in/yourprofile">linkedin.com/in/yourprofile</a></p>
- Change the page title: In the
- With Copilot Chat: After the Student Pack is active, in VS Code ask Copilot to personalize your page, e.g., “Insert my name into the page title and header.”
Tips & fixes
- Image not showing? Ensure file is uploaded at repo root and filename matches exactly.
- Broken layout? Keep new sections inside
<main>...</main>. - Made a mistake? Revert to an earlier version: Go to your repo → Code tab → click the commit count (e.g., "15 commits") → find the working version → click the commit hash → click Browse files → copy the URL. Then go back to Code tab → Add file → Upload files → drag your backup files or use the web editor to manually restore the working content. Alternative: Click the commit hash → click Revert button (if available) → Create revert commit.
Step 6: Pair up & peer review (homework) — full instructions
~20–25 minutes total (10–12 per partner)
A) Invite your partner (so they can be assigned as reviewer)
- Open your repo → Settings → Collaborators and teams (sometimes shown as Manage access).
- Click Add people → type your partner's GitHub username → Add.
- Your partner must accept the email/in-app invite. (Without accepting, they can still comment, but you can't formally assign them as a reviewer.)
Tips
- Public repos allow comments from anyone; adding as collaborator enables formal Review assignments and suggestion commits.
- If Collaborators and teams isn't visible, ensure you're the repo owner.
B) Create a "review Pull Request (PR)" in your repo
- On the Code tab, open the branch dropdown (it says
main) → typepeer-review-prep→ Create branch. - Edit a tiny thing in
index.html(e.g., add a comment<!-- TODO: improve About text -->) → Commit. - Click the yellow banner "Compare & pull request" → title:
Peer Review: <Your Name>. - In the PR description, paste your live URL + any questions you have for the reviewer.
- On the right side, under Reviewers, assign your partner (after they accepted the invite).
C) Partner: conduct the peer review using the Code Review Checklist
Goal: Apply the CISC 121 Code Review Checklist to evaluate your partner's webpage for readability, correctness, maintainability, and best practices.
- Go to your partner's repo → Pull requests tab → open the PR titled Peer Review: ...
- Open the live URL in a new tab to test functionality.
- Click Files changed to review the code line-by-line.
- Use the Code Review Checklist below to guide your review. Leave at least one comment per checklist category (8 total minimum).
- For each comment, follow SMART feedback principles (see guidelines below).
- When finished, click Review changes (top-right) → write a summary → choose Comment, Approve, or Request changes → Submit review.
The Code Review Checklist (from CISC 121)
| Checklist Item | What to Check For |
|---|---|
| 1. Functionality | Does the code work correctly? Test the live site: click all links, verify images load, check for console errors. |
| 2. Clarity | Is the code easy to read and understand? Check for meaningful element names, clear headings, no jargon. |
| 3. Structure | Is the code organized in small parts (semantic HTML)? Verify proper use of <header>, <main>, heading hierarchy, etc. |
| 4. Maintainability | Is it easy to update later? Ensure styles are in CSS (not inline), repeated patterns use classes, colors use CSS variables. |
| 5. Performance | Does the code run efficiently? Check image file sizes, avoid redundant CSS, ensure page loads quickly. |
| 6. Security | Does it handle bad inputs safely? Verify no personal phone/address exposed, external links are trustworthy, no inline scripts from unknown sources. |
| 7. Documentation | Are the comments useful? Check README explains setup, HTML comments clarify sections, commit messages describe why changes were made. |
| 8. Testing | Are edge cases handled? Test on mobile/desktop, try broken image paths, click mailto/external links, verify accessibility (alt text, contrast). |
How to Give SMART Feedback
Every comment you leave should follow the SMART framework from CISC 121:
- Specific: Point to the exact file, line, or behavior. Say what to change.
Example: "Inindex.htmlline 23, the<img>tag is missing analtattribute. Addalt='Photo of [Name]'for accessibility." - Measurable: Define what "better" means with a concrete check (e.g., test passes, page loads faster, no console errors).
Example: "Reduceme.jpgfrom 2MB to under 500KB so the page loads in under 2 seconds on slow connections." - Achievable: Suggest a realistic fix given the scope and skill level of CISC 121.
Example: "Replace inline styles with a CSS class. For instance, change<p style='color:blue'>to<p class='highlight'>and define.highlight { color: var(--blue); }instyle.css." - Relevant: Keep feedback aligned with the homework goals (functionality, clarity, structure, etc.). Avoid nitpicks that don't improve the page.
Example (good): "This heading should be<h2>instead of<h3>to maintain proper hierarchy."
Example (avoid): "I prefer green over blue" (personal preference, not relevant). - Time-bound: Indicate priority or timeline.
Example: "Fix the broken LinkedIn link before merging this PR" or "Consider adding a footer in a future update."
✅ Good feedback: "In
style.css line 12, the background color #fff and text color #f0f0f0 have low contrast (WCAG fail). Change text to #1a1a1a for readability. Fix before merge."
How to leave comments in GitHub
- Line-specific comment: In Files changed, hover over a line → click the blue + → type your SMART feedback → Add review comment.
- Suggest a code change: Click Insert a suggestion button → edit the code block → Add review comment. The author can apply it with one click.
- General comment: Use the Conversation tab for issues that span multiple files (e.g., "All images are missing alt text").
- Attach screenshots: Drag-drop images into the comment box to show visual issues (e.g., layout bug on mobile).
D) Author: respond to feedback & apply changes
- Open your PR → read all comments in Conversation and Files changed tabs.
- For suggestion blocks, click Apply suggestion (or Add suggestion to batch) → Commit.
- For other feedback, edit the files directly (via web or local) → commit with a descriptive message referencing the feedback (e.g., "Fix alt text per @partner's review").
- Reply to each comment to acknowledge it or ask clarifying questions.
- When all critical issues are resolved, click Merge pull request → Confirm → Delete branch. GitHub Pages will redeploy automatically.
E) Quick reference: Review comment examples by checklist item
Expand for example comments
- Functionality: "The LinkedIn link in line 34 points to
#(nowhere). Update to your actual LinkedIn profile or remove it. Fix before merge." - Clarity: "In line 18, the heading 'Stuff' is vague. Change to 'My Projects' or 'Coursework' so visitors understand the section. Fix before merge."
- Structure: "Lines 20–25 nest an
<h3>directly under<h1>with no<h2>. This breaks heading hierarchy. Change<h3>to<h2>." - Maintainability: "Line 30 uses inline style
style='color:#b90e31'. Move this tostyle.cssas.red-text { color: var(--red); }so future color changes are centralized." - Performance: "
me.jpgis 3.2MB. Compress to under 500KB using TinyPNG or similar. Goal: page load under 2 seconds on 3G. Fix before merge." - Security: "Line 40 includes your phone number. Remove it unless you intend to make it public. If intentional, acknowledge this comment."
- Documentation: "README is empty. Add a sentence: 'Personal student page for CISC 121. Edit
index.htmlto update content.' Can follow up after merge." - Testing: "The
<img>in line 28 has noaltattribute. Addalt='Portrait of [Your Name]'for screen-reader users. Fix before merge."