Week 3 Lab — Team Norms and Evaluation Methodology

CSIC30216 · Fall 2026

Goal

Establish team norms and shared AI guidelines before building begins, and draft an evaluation plan that shapes your design decisions from the start.

Working style: Project teams throughout · Total time: ~70 minutes

No fixed roles. Every part below is completed by the team together, not led by a named role.
Where this goes: both the draft guidelines and the evaluation plan feed directly into Checkpoint 1 (due Week 6). What you write today is a first draft you will build on, not a throwaway exercise.

Part 1 — Repository Setup (15 minutes)

The team works through this together — TA-guided, whole class at the same pace. Follow this order exactly. It is not the same order a quick summary might suggest, and doing it out of order can lock your team out of its own setup (see the note at Step 5).

Repos are public this semester, not private. This avoids a real GitHub limitation: branch protection on private repositories requires a paid GitHub Pro account, which we can't assume everyone has set up in time for today. Public repos get full branch protection on the free tier. One consequence worth knowing: your code and PR history will be visible to anyone, including future semesters' students — reusing another team's work, past or present, is still subject to the same academic integrity policy as anything else in this course.

Before Step 1 — Don't Have a GitHub Account Yet?

If you've never used GitHub before, do this first — ideally before class, since it only takes a few minutes but you don't want to be doing it while your team waits on you.

  1. Go to github.com and click Sign up (top right).
  2. Enter an email address, create a password, and choose a username. Pick a username you're fine having attached to your work for the rest of the semester and beyond — it'll show up on every commit and PR.
  3. Verify your email address (check your inbox for a confirmation link/code from GitHub).
  4. Use the same email here that you'll use in Step 2 below (git config --global user.email) — keeping them consistent avoids confusing mismatches later between what git logs locally and what GitHub shows online.
No credit card or paid plan needed for anything in this course — everything here works on a free GitHub account.

Before Step 1 — One-Time Git Setup

If anyone on your team has never used git from the command line before, do this first. It only needs to be done once per computer, not once per repository.

  1. Open a terminal (Terminal on Mac/Linux, Git Bash or PowerShell on Windows) and check whether git is already installed: 
    git --version
    If you see a version number, you're set. If you get an error, install git from git-scm.com/downloads and re-run the check.
  2. Tell git who you are — also once per computer: 
    git config --global user.name "Your Name"
git config --global user.email "the-email-you-used-for-github@example.com"
  3. The first time you push to GitHub from this computer, you'll likely be prompted to authenticate — usually a browser sign-in window, or a request for a personal access token. If this fails or looks confusing, flag a TA immediately rather than troubleshooting alone. It's a common first-time hiccup and much faster to fix with help than to debug solo.

Step 1 — Create the Repository

Step 2 — Add Teammates as Collaborators

Step 3 — Clone the Repository to Your Computer

"Cloning" downloads a full local copy of the repo onto your computer, already connected to GitHub so you can push changes back later. Every team member does this individually — you each need your own local copy, not a shared one.

In your terminal, navigate to wherever you keep coding projects, then run:

git clone https://github.com/your-team/your-repo.git
cd your-repo

Step 4 — Add the PR Template and DECISIONS.md Before Turning On Branch Protection

This order matters. Once branch protection is on, every change — including these setup files — has to go through a pull request, and if you've also required an approval, you can get stuck needing a second reviewer before anyone else has even accepted their invite. Doing this step first avoids that entirely.

Easiest done through the GitHub website directly, not your local clone.

## What this PR does
[One sentence]

## Decision (required if a significant choice was made)
Decision: [what was chosen]
Why: [what problem this solves or what alternative it beat]
Alternative rejected: [optional]
Led by: [name]
# Decisions Log

## 2026-09-21 — Initial code steward
**What:** [Name] is the initial code steward for the team.
**Why:** [one sentence — e.g. "volunteered," "has the most git experience so far," "assigned by team agreement"]

Back in your terminal, pull these new files into your local clone so everyone's copy is up to date:

git pull origin main

Step 5 — Now Enable Branch Protection on main

The TA walks the room and confirms this is done before any team moves on.

Step 6 — Practice the Real Workflow

Rather than just checking that protection works, everyone does one real practice PR — this doubles as your first hands-on rep with the workflow you'll use for the rest of the semester.

  1. In your terminal, inside your cloned repo folder, create your own branch: 
    git checkout -b your-name-test
  2. Make a small, harmless change — for example, add your name to a new file: 
    echo "- Your Name" >> CONTRIBUTORS.md
  3. Stage, commit, and push your branch: 
    git add CONTRIBUTORS.md
git commit -m "Add my name to CONTRIBUTORS.md"
git push origin your-name-test
  1. On GitHub, you should see a banner suggesting you open a pull request from your new branch. Click Compare & pull request.
  1. Fill in the PR template your team added in Step 4, and click Create pull request.
  1. Optional, if time allows — prove the rejection directly. Try pushing straight to main instead of through a branch: 
    git checkout main
echo "test" >> CONTRIBUTORS.md
git add CONTRIBUTORS.md
git commit -m "direct push test"
git push origin main
    This should be rejected, with an error along the lines of remote: error: GH006: Protected branch update failed. Exact wording varies slightly by GitHub version — a rejection of some kind is what you're looking for.
  1. Have one teammate — ideally the code steward — review and merge at least one of the team's practice PRs, so everyone also sees what a merge looks like from the reviewer's side.
  2. Do not move on until the TA has confirmed at least one successful practice PR merge for your team.
Timing: if your team has git beginners, budget 20–25 minutes rather than 15. The one-time setup and the six-step practice rep are the parts most likely to run long for a first-time user.

Part 2 — Draft AI Usage Guidelines (25 minutes)

The team works through this together. Produce a first draft using a simplified three-section template.

Section 1 — What AI tools we plan to use, and what we will use each for

A specific tool-to-task mapping, not "we will use Claude." Examples of the level of specificity to aim for:

Notice the pattern in each: name the specific tool (not just "AI"), name the specific task, and name what it is not for. That last part is what most vague guidelines skip — "we will use Claude for code" doesn't tell a new teammate where the line is.

Section 2 — How we will document AI interactions

What goes in the prompt engineering log, and what goes in the collaboration log. Examples:

The pattern here: name what triggers a log entry, what doesn't, and which of the three places (prompt log, DECISIONS.md, PR description) each kind of AI interaction belongs in. A guideline that just says "we'll log our AI use" doesn't tell anyone what counts as "use." A decision is different from an interaction — it needs the reasoning to survive, not just the transcript.

Section 3 — How we will handle disagreements about AI output quality

Who has final say, and what evidence is required. Examples:

The pattern here: name a specific person or role who breaks the tie (not "the team decides," which is where disagreements come from in the first place), and name the actual evidence that counts — not "if it looks good," which is exactly the vague standard Slide 9 warned against.
This is a first draft, not the finished product. The full five-section guidelines are produced in the Week 12 lab. The goal today is to establish norms before your team starts making AI-assisted decisions together.

Part 3 — Draft Evaluation Plan (25 minutes)

The team works through this together.

Problem Grounding (10 minutes)

Three questions:

Evaluation Plan Draft (15 minutes)

Four fields:

Grading Checklist (2%)

← Back to Calendar