Your repository, and the team agreement

ISOM 472 — Fall 2026/2027

Dr. Mohammad AlMarzouq Week 2 — second class

ISOM 472: Project in IS — Kuwait University

Three things today

1. Your first pull request

The whole room, together, once.

3. Your proposal — questioned, and decided out loud.

You leave today knowing whether your project is accepted, and what to fix if it is not.

ISOM 472: Project in IS — Kuwait University

Your repository exists

github.com/isom472-fall2026/team1 … team5

  • One per team. Everything you hand in this semester lives in it
  • Accept the invitation — it is in your email and in your GitHub notifications
  • Until you accept, you cannot push anything

If you cannot see your repository, say so now, not at the end of the hour.

ISOM 472: Project in IS — Kuwait University

It is already published

isom472-fall2026.github.io/team1/docs/

  • Your page is live right now. It shows placeholder text until you edit it
  • Edit docs/index.html, open a pull request, merge it
  • About a minute later the page updates by itself. There is no publish button

This is where your proposal is presented from. It is checked as reachable, not as beautiful.

ISOM 472: Project in IS — Kuwait University

First: is this commit yours?

Every commit carries an email address. If it is not the one on your GitHub account, GitHub cannot tell the commit is yours.

In GitHub Desktop: Settings › Git › Author — on Windows, File › Options. Your name, your KU email, Save.

git config --global user.name  "Your Name"
git config --global user.email "you@ku.edu.kw"

Or type those two lines. Same file either way — and the email must already be on your GitHub account.

A grey icon next to your commit means it did not count. Your individual mark is read out of work GitHub can see is yours.

ISOM 472: Project in IS — Kuwait University

The loop — once, together

  1. Branch — a line of work that does not disturb anyone else's
  2. Commit — a saved point, with your name on it
  3. Pull request — your branch, offered for review
  4. Review — a teammate says what they checked
  5. Merge — it becomes part of the real thing

Nobody moves to the next step alone. We do all five, in this room, on one small change each.

ISOM 472: Project in IS — Kuwait University

Why you cannot push to main

  • Try it and GitHub refuses. That is the rule, not a fault
  • Everything reaches main through a pull request that somebody else approved
  • Nobody approves their own work

It is set once, for every team repository. You cannot switch it off, and neither can I without leaving a trace.

ISOM 472: Project in IS — Kuwait University

What you just did

  • The work is visible, and it is attributed to you
  • Someone else read it before it became real
  • Nothing reached main without both of those

This is the loop for every piece of work for the rest of the semester. It is also how your individual mark is read.

ISOM 472: Project in IS — Kuwait University

Now, the team agreement

Fifteen minutes, while you are all sitting together, with your laptops open.

ISOM 472: Project in IS — Kuwait University

What it covers

  • Hours each of you can realistically give, and how to reach you fastest
  • When we meet, and how fast we answer each other
  • What happens when someone goes quiet — who says something, and when
  • Signed by every member

It is in your repository: docs/team-agreement.md. Fill it in now, sign it here, and it is part of Phase 1.

ISOM 472: Project in IS — Kuwait University

You sign it here, twice

1. By hand

You type your name in the table and commit it yourself.

A signature is a commit from your own account. Typed text with someone else's commit behind it is not a signature.

The second signature is the check: a laptop where Antigravity cannot do this is a laptop we fix today, not in week 6.

ISOM 472: Project in IS — Kuwait University

The exercise, in order

  1. Phase 1 Lead — ask Antigravity to open the issue: everyone signs, Antigravity works on every laptop
  2. Phase 1 Lead — branch <issue>-sign-the-team-agreement
  3. Everyone — fill in your own row, type your name, commit and push
  4. Everyone — ask Antigravity to add your handle and the date, commit, then you push
  5. Phase 1 Lead — open the pull request. A teammate reviews and merges
  6. Phase 1 Lead — ask Antigravity to check every row and close the issue

The three prompts are written out in docs/prompts.md — do not retype them from this slide.

ISOM 472: Project in IS — Kuwait University

Free, because you are a student

GitHub Pro

Free while you are enrolled. Private repositories, Pages on them, and Codespaces.

Also in the pack: JetBrains, MongoDB Atlas, Notion, a free .me domain, Azure credit.

Apply at github.com/settings/education/benefits. It is not automatic and it is not instant.

ISOM 472: Project in IS — Kuwait University

Applying — and the three ways it fails

  1. Upload a clear, dated proof — student ID, class schedule or transcript. Blurry or undated is the most common rejection
  2. Use your KU email on the account, and make your GitHub name match your real name
  3. Apply today, not the night you need it — approval takes days, not minutes

If you graduate this term: your access may not renew in the final weeks. Do not build your December on it.

ISOM 472: Project in IS — Kuwait University

Proposals — the rest of the hour

  • Nobody presents. I question each team directly, from your own page on screen
  • Seven minutes each, and the whole room listens
  • I say the decision out loud — accepted, or returned with a reason and a date

A returned proposal is not a penalty. It is a rewrite, and the date is already on your slip.

ISOM 472: Project in IS — Kuwait University

What Phase 1 needs, before you leave

Where
The proposal, in its eight sections docs/proposal.md
The same thing published as a page your repository's page address
The team table filled in README.md
The team agreement, signed twice by everyone docs/team-agreement.md
One commit from every member, showing their name the repository
Everyone has accepted the repository invitation GitHub

The Phase Lead creates the tag phase-1 when the last of those is merged. The tag is what gets graded.

ISOM 472: Project in IS — Kuwait University

Next class: what your system must do

Requirements, user stories, and how six people build at once.

ISOM 472: Project in IS — Kuwait University

Session 4 of 29. Room 1001, 08:00-09:15. Laptops open from the first minute. Phase 1 is delivered today, so the deck is deliberately thin: it exists to run the walkthrough and to put the agreement in front of them, and then it gets out of the way for the proposals, which take the larger half of the session.

Say the shape at 08:00 so nobody is waiting for their turn without knowing when it comes. The walkthrough has to finish by 08:23 or the proposals lose a team.

Walk the room while this is on screen. The two failures are a student who never made a GitHub account and a student whose invitation is sitting unaccepted in an inbox they do not read. Both are two minutes here and a lost week otherwise. Repositories are named by team number; that is deliberate and it is not negotiable, because everything else keys off it.

Open one team's page on the projector. Seeing the placeholder live does more than any explanation, and it makes the Wednesday deliverable concrete: the page is not something they build, it is something that is already running and that they edit.

This is the single most expensive five minutes of the semester and it is invisible if it goes wrong — the student works all term and the record shows a stranger. Do it from the front in GitHub Desktop, on the projector: Settings, Git, Author tab, name, pick the KU address, Save. The dialog says so itself — "these preferences will edit your global Git config file" — which is the whole reason the two commands are the same act. Then check the avatar on the commit they make in the next ten minutes. A student whose KU address is not in the Email dropdown has not added it on github.com yet; that is Settings › Emails, and it needs the confirmation mail. Steps and the screenshot are on the setup page and in docs/setup.md in their repository.

The change is trivial on purpose: each student adds their own name to the team table in README.md. Trivial content, real mechanics. Do not allow anyone to run ahead; the point is that all five steps happen once with help available.

Expect at least one student to have already hit this last night and assumed their access was broken. Name it early. The rule is what makes the individual mark readable — every change has an author and a reviewer, and neither can be the same person.

Land the principle while they are still looking at their own pull request on the screen. "Work invisible in the repository did not happen" is the line to repeat.

Teams are formed and the repositories are open. This is the only moment in the semester when all of that is true and nothing is yet due, so the agreement gets written honestly rather than defensively.

Do not let them treat this as paperwork. The clause that matters is the quiet member: teams that have not agreed it in September carry the person silently until week 12 and then ask me to fix it in week 13. Say that out loud — it is the reason the page exists, and every class has at least one team that needs it.

Say why it is twice before anyone calls it busywork. The agreement is the errand; the real exercise is the loop and the tools — branch, issue, two commits per person, one pull request, one review, one close — on content where a mistake costs nothing. Every step is one they will repeat all semester.

Fifteen minutes, and it is the first time the agent touches their repository, so walk the room rather than reading this list out. Two failures to expect: a git identity that is not theirs, which shows as a grey avatar and is fixed by slide 5's two lines, and Antigravity not signed in, which is the whole reason the check exists — those students sign by hand and stay behind for two minutes. Antigravity may open and close issues and commit; it does not push, open a pull request, approve or merge, and that rule is in AGENTS.md and holds today.

Copilot is not the tool this course builds with — Antigravity is — so frame this as "claim what you are owed", not as a change of stack. The honest caveat is worth saying: the student tier picks the model for you, so what they see in a demo on a teacher account may not reproduce on theirs. Supabase, Vercel, Netlify and Figma are no longer in the pack; nothing in this course depends on them being there, because we use each platform's own free tier.

The last line matters more here than in any other course — this is the capstone, so a good share of the room is graduating, and Copilot access is re-evaluated monthly against enrolment. The fallback is the personal-key lane set up on 30 September, which is already in the plan. Do not let anyone leave thinking their AI access is guaranteed through the demo.

No presentations: open each team's published page on the projector and question them from it. It is faster, it is closer to a client conversation, and it removes the half of the exercise that taught nothing. Never cut the spoken decision — every team hears every other team's decision, which is the cheapest teaching in the course. The minutes saved here pay for the signing exercise.

Read the last line twice. The tag is the one mechanic nobody has done before and the delivery note in their repository has the steps. Anything merged after the tag belongs to Phase 2.

Close on the forward link. Any team whose proposal was returned should leave with the date in their hand, not in their memory.