← MSBAi Home

GitHub Strategy for the MSBA Programs

Status: Proposal, pending approval. Nothing in here has been built. One exception: §7, the move into the University of Illinois GitHub Enterprise, is declined as of 2026-07-28. That is Vishal’s own call as proposer and org administrator, not an approval of anything else here. It is the only item in the document that is settled rather than requested. Proposed by: Vishal Sachdev, 2026-07-28 Approvers: Ron Guymon, Heather Aldridge, Cheng Li Last revised: 2026-07-28 (enterprise move declined and recorded in §7; the sole-owner problem promoted to the headline governance ask in §5.1; version-control PLO given a home in program/program_learning_outcomes.md, which is now the copy of record for its wording and its taught/reinforced/assessed map; the document narrowed to items that need someone other than the proposer to decide, with the proposer’s own setup work removed) Scope: Program level, both delivery formats (MSBAi online and on-campus MSBA). The course-level companion for BADM 554 is a separate document, referenced in §2.

Sourcing convention. Claims marked [found] are traceable to a file in this repo or a cited external source and are quoted inline. Claims marked [unverified] are inference or secondhand and need confirmation before anyone relies on them. Nothing in the recommendations section rests on an unverified claim without saying so.

1. The ask

Four decisions, all of them program-level. One is the most important governance item in this document and should not wait for the other three.

Premises, not asks. Three things are settled and are the proposer’s own calls as instructor of record and organization administrator. They are stated here because later sections rest on them, not because anyone is being asked to approve them. (a) Business-Analytics-at-Gies already exists and becomes the single organization for both MSBA formats; no new org is created (§5). (b) The legacy BADM554 organization is being wound down, which closes the live privacy exposure described in §8. (c) GitHub Classroom is not used (§6). Only one of the three has a program-level dimension: whether the on-campus MSBA joins the same organization is a genuine question and is asked in §12.

What this proposal is not asking for. No budget. No new software licences. No new staff. No new student cost. GitHub is free for what we need, and Copilot is free for verified students [found: internal decision registry, “GitHub Copilot free for verified students — restored (2026-07-26)”].

The one thing that is genuinely urgent is decision 1. Vishal is currently the sole administrator of the organization that will hold team work for two degree programs. That is a single point of failure on an institutional asset, and unlike everything else in this document it has no external dependency and no lead time. It can be fixed the day it is approved. It should be fixed before the Fall 2026 cohort arrives, not after.

One option was evaluated and is no longer on the table. Moving the organization into the University of Illinois GitHub Enterprise was researched in detail and declined by Vishal on 2026-07-28 (§7). The research is preserved in §7 rather than deleted, because the question will be asked again. Declining removes most of the conditions and risks that used to sit in this document. It makes exactly one problem worse, and that problem is decision 1.

2. Why this is a program decision and not a course decision

BADM 554 is the first course in the sequence, so GitHub gets taught there. That makes 554 the natural teaching venue. It does not make GitHub a 554 topic.

Three reasons the decision has to sit above the course:

Students keep the account for the whole degree and past it. A GitHub account created in Week 1 of course one is the same account used in the capstone fifteen months later. If each course invents its own conventions, students relearn the tool six times and the portfolio never accumulates. The whole value of version control as a skill is that it compounds, and compounding is a program property.

The identity and roster mapping is a program asset. One organization, one membership list, one place where a student’s GitHub handle is linked to a person. Six course-owned orgs means six roster mappings, six sets of stale members, and six places to check when a student withdraws. This is the same argument that put the LMS at program level.

It affects assessment design in every course, not just 554. Copilot is now assumed present in the standard toolkit [found: program/tools.md §2], and the program’s assessment model stages work as pre-AI, AI, and post-AI with a declared AIAS level [found: design/assessment_strategy.md]. Those two facts collide (§9). A course cannot fix that on its own without diverging from the program.

Course-level companion document. The detailed BADM 554 design (repo model, week-by-week git surface, failure modes, submission mechanics) is ~/teaching/badm554/docs/superpowers/specs/2026-07-28-github-strategy-proposal.md. This proposal is consistent with it and does not repeat it. Where the two documents overlap, this one governs the convention and that one governs the delivery.

3. What the program owns and what a course owns

The dividing line: the program owns identity and convention, the course owns content and ephemera.

The practical test. If a student would have to learn it twice because two courses did it differently, it belongs to the program. If it only exists while a term is running, it belongs to the course.

4. The proposed program learning outcome

PLOs had never been documented anywhere in this repository. Lorena Nicholas confirmed in April that “program-level learning outcomes remain the same as the residential version”, but the formal list was never written down here, and documenting it has been an open action item since 2026-04-10 [found: internal action-item and open-questions trackers].

This proposal still does not solve that, and it should not: defining the outcome set for a degree is a faculty and program-leadership exercise, not a drafting one. What it does is give the work a home. program/program_learning_outcomes.md now exists as an explicitly incomplete stub holding one outcome, in the shape AACSB guidance asks for, with the rest of the list flagged as requiring program-leadership input. The document says plainly that it is not an authoritative list. The outcome below is its first entry; the two are kept identical, and that file is the one to edit.

The shape follows Martin Maurer’s accreditation guidance already recorded in the decision registry: observable, measurable verbs; each outcome mapped to a specific artifact and rubric; assessable at the individual level and not only at the team level [found: internal decision registry, “AACSB capstone learning outcome design: Martin Maurer’s guidance”].

Proposed PLO: Version-controlled professional practice

Graduates manage, evidence, and present analytical work using industry-standard version control.

Specifically, a graduate can:

1. Maintain a repository of their own analytical work, committing incrementally so that the history is a truthful record of how the work developed.
2. Collaborate on a shared repository with teammates, using branches and pull requests, and resolve the conflicts that collaboration produces.
3. Evaluate AI-generated work before committing it, and document what the AI contributed and how it was verified.
4. Present a public repository as professional evidence of their capability to an external audience.

Note what is deliberately absent: any requirement to recall git commands. The outcome is about the practice, not the syntax. That is consistent with the program stance that execution is the part AI handles and judgement is the part the student owns [found: design/why_show_your_thinking.md, Specify / Execute / Verify].

Where it is taught, reinforced, and assessed

Not duplicated here. The taught / reinforced / assessed table lives in program/program_learning_outcomes.md under PLO 1, and that is the only copy. In one line: taught in BADM 554 as course one, reinforced in every subsequent course by a commit-permalink submission convention that costs no new content, assessed summatively at the capstone (where the portfolio history is individual-level evidence behind a team grade, which is what AACSB requires) and formatively in BADM 554 through a single oral-defense prompt that consumes no grade weight.

Why the capstone is the right assessment location and not course one. Assessing it in 554 would assess a skill three weeks old. Assessing it at the capstone assesses whether it stuck across fifteen months, which is what a program outcome is supposed to measure. It also lands the LOA data collection in the place the program has already identified as the primary integrated assessment point [found: internal decision registry, “AACSB capstone learning outcome design: Martin Maurer’s guidance”].

Cost of adding this outcome: two paragraphs. It requires no new course, no new assignment, and no new video. The reinforcement mechanism is a submission format, not a lesson. The dependency worth naming when approving it: that reinforcement convention has to be adopted in all six courses. Without it the outcome is a single-course topic assessed fifteen months later.

5. One organization: Business-Analytics-at-Gies

Recommendation: use the org that already exists. Business-Analytics-at-Gies currently holds two repositories and is effectively dormant. It becomes the single home for both the online and on-campus MSBA.

Do not create a new organization. A new org would need the same governance work, would fragment whatever history exists, and would signal to nobody. Reviving a dormant org costs nothing.

One org, both formats. The on-campus MSBA will also start using GitHub. Separating the formats into two orgs would duplicate every convention in this document and guarantee drift between them. Sections are separated by team naming and repository naming inside one org, which is what GitHub teams are for. Whether the on-campus MSBA joins is the one part of this that is not the proposer’s to decide, and it is asked in §12.

The legacy BADM554 organization, which is Fall 2025 GitHub Classroom residue, is being wound down separately by the instructor. That is not an approval item, but it matters here for one reason: it is what closes the live privacy exposure described in §8.

5.1 Governance: who owns the org

⚠ The single most important item in this document

Ask: add at least one additional owner to Business-Analytics-at-Gies before any student work lands in it, and write down a succession plan for what happens if Vishal stops teaching BADM 554.

Vishal is currently the sole administrator of the organization that is proposed to hold team repositories, template repositories, and shared conventions for two degree programs across an indefinite number of cohorts. If that one account is lost, locked, or simply moves on, there is no second person who can add an owner, transfer a repository, remove a departed member, or recover access. Nothing in this document degrades gracefully from that state.

This used to be someone else’s problem to solve. The University enterprise will not provision an organization without two named owners with NetIDs [found: help.uillinois.edu KB 2185], so the move in §7 would have made the fix structural: a requirement of the platform rather than something a person has to remember. With the enterprise move declined (§7), that safety net is gone and this reverts to a policy commitment that has to be made deliberately and kept deliberately. Declining the enterprise move made most things simpler and made exactly this one thing worse, which is why it is promoted here from a recommendation to the headline ask.

It is also the cheapest item in the document. It needs a name and about a page of procedure. There is no budget, no lead time, no external dependency, and no reason to wait for any other decision here.

What “add a second owner” means concretely:

• Minimum two owners at all times, as a standing rule and not a one-time act. Vishal as the operational owner. The second should be a program administrator rather than another instructor, because the failure this protects against is a faculty member leaving, and adding a second faculty member does not protect against that. Heather Aldridge or the equivalent program-operations role is the right shape.
• The second owner is a real owner, not a formality. GitHub organization Owner role, not billing manager and not team maintainer. An owner who cannot independently add a third owner has not removed the single point of failure.
• Two-factor recovery is part of the ask. Both owner accounts have 2FA with recovery codes stored somewhere the program can reach, not only in one person’s password manager. A second owner who is locked out is not a second owner.

The succession plan, which is the other half of the ask. A second owner protects against sudden loss of access. It does not answer what happens when Vishal stops teaching BADM 554, which is a foreseeable and probably scheduled event rather than an accident. Write down, in one page, before student work lands:

1. Who inherits operational ownership of the org, by role rather than by name, so the plan survives the person who wrote it.
2. What happens to the repositories. Team and template repos are org-owned and stay with the org (this is only true if they are created in the org in the first place, per §3, rather than on an instructor’s personal account). Student portfolio repositories are on students’ own accounts and are unaffected by any faculty change, by design (§8.1).
3. Who runs the recurring duties listed below when the current instructor is not there to run them.
4. A review trigger, so the plan is re-read when the instructor of record for BADM 554 changes, and not only when something has already gone wrong.

The recurring governance duties, whoever is holding them:

• Course instructors get organization-team maintainer rights, not owner rights. They can create and manage repos for their course without being able to delete the org or remove members.
• On a faculty change, the departing instructor’s team maintainer role is removed and their repositories stay with the org, because they were always org-owned. Nothing is stranded on a personal account.
• On a term ending, that term’s team repos are archived rather than deleted.
• On a cohort graduating, someone prunes the membership list. This is a named duty, not an assumption. Removal is a manual owner action with no automation, so if nobody owns it, graduated students stay members indefinitely. There is no automated fallback either way (§7.2 found no documented automation inside the enterprise either), so this duty carries the whole weight.
• Never use “internal” repository visibility. This one is now mostly moot: “internal” visibility only exists for organizations inside an enterprise, so a standalone free organization cannot offer it. Keep the rule written down anyway, because it is a trap if the enterprise question is ever revisited (§7): “internal” there means readable by every U of I GitHub member across all three campuses, not by our program [found: answers.uillinois.edu/systemoffices/102099]. Private or public, nothing in between.

6. Premise: no GitHub Classroom

Not an approval item. GitHub Classroom is not used. That is the instructor’s call about his own course infrastructure, made on the basis of the Fall 2025 trial, and it is stated here only because two things later in this document depend on it.

Why it matters to the program. Now that version control is a proposed learning outcome (§4), the provisioning is the lesson: creating a repository from a template, cloning it, wiring the remote, and pushing for the first time are exactly what a student must be able to do unaided. Classroom performs all four invisibly, so the student learns to accept an invitation. It also creates repositories that belong to the organization rather than to the student, and a recruiter link that resolves to a course org is a transcript, not a portfolio.

The two consequences that show up elsewhere. Roster mapping is done by a single Week 1 Canvas onboarding assignment rather than by Classroom automation, which is why the FERPA position in §8 can keep the roster entirely in Canvas. And the student’s primary artifact is a repository they own, which is why a faculty change strands nothing (§5.1) and why the public-versus-private question in §8.1 is the student’s to answer.

7. The University of Illinois GitHub Enterprise question: evaluated and declined

Decision, 2026-07-28: no. Business-Analytics-at-Gies stays an ordinary organization on github.com. It does not move into the University of Illinois shared GitHub Enterprise.

This was the one item in this document with an external dependency, a lead time, and an unresolved blocking question. An earlier draft recommended yes, subject to three conditions. Vishal declined the move, which is his call as the proposer and the organization’s administrator, and it is recorded here as a decision on the record rather than something that quietly lapsed.

The research is kept below rather than deleted. It took real work, the University’s arrangement is not obvious, and someone will ask this question again in a year.

7.1 What was evaluated

Whether Business-Analytics-at-Gies should move inside the University of Illinois shared GitHub Enterprise, a U of I System service administered by AITS across all three campuses, rather than existing as an ordinary free organization on github.com owned by an individual faculty member.

7.2 What was verified, and how confident we were

The service page at web.uillinois.edu/github blocks automated retrieval, so the University’s public knowledge bases were read directly instead.

7.3 Why it was attractive, and what declining gives up

The case for moving was real, and it is worth stating plainly so the decline is not read as “there was nothing there”:

1. It would have solved the sole-admin problem structurally. The University will not create an organization without two named owners with NetIDs. Policy erodes; a provisioning requirement does not. This was the strongest argument and would arguably have justified the move on its own. It is also the one thing declining makes worse, which is why it is now the headline ask in §5.1.
2. NetID association would have given private roster mapping for free, without the program maintaining or securing a person-to-handle spreadsheet.
3. The enforced defaults matched our privacy posture: base member permission “None” and private-only repository creation, enforced by the platform rather than by instruction.
4. It cost nothing in money. The licence is shared system-wide.

Points 2 and 4 are conveniences. Point 3 we can and do set by hand in a free organization. Point 1 is the only real loss, and §5.1 is the answer to it.

7.4 What declining removes

Most of the conditions, risks, and unknowns in the earlier draft simply evaporate. They are listed explicitly, because their disappearance is the substance of the decision:

• No Copilot-seat risk. The blocking open question is void. Students’ free GitHub Education Copilot entitlement is untouched, because they are not joining any enterprise. The program-level tool assumption confirmed on 2026-07-26 stands with nothing left to verify.
• No public-repository restriction to work around. The enterprise defaults members to private-only repository creation. Outside it, the program sets its own posture, which is private by default and public by the student’s deliberate act (§8.1). That is now a program choice rather than a platform constraint, which is the right way round for a decision about students’ own work.
• No University-ownership question hanging over student work. The End User Service Agreement clause about the University controlling and possibly owning data in a University organization never attaches to anything here. The portfolio-repository boundary in §8.1 remains good practice; it is no longer load-bearing against a contractual claim.
• No provisioning lead time. Nothing waits on AITS: no request form, no reported two-week window, no risk of missing the term start. Everything in this document that is approved can be built the week it is approved.
• No added authentication friction. This was a named completion risk, not a nicety. Enforced SAML SSO on every organization access, which cannot be disabled, would have sat directly on top of the historic Day 1 blocker in this course (authentication failure on first push), for a cohort of working career pivoters often studying late at night with no support available [found: program/target_profile.md]. That layer is now simply absent. A documented authentication-recovery procedure in course one is still worth shipping; it just has one fewer failure mode to cover.
• No “internal” visibility trap, because internal visibility does not exist outside an enterprise. The rule stays written down in §5.1 in case the question is ever revisited.

What does not change: post-cohort member pruning is still a manual duty someone has to own (§5.1). It was going to be manual inside the enterprise too.

7.5 What would make this worth revisiting

Not a commitment to revisit, just the conditions under which the answer might differ:

• The sole-owner problem is not solved by policy. If §5.1 is approved and then does not actually happen, the structural fix the enterprise provides becomes the strongest argument all over again.
• The program grows past what one organization and one instructor can govern, for example the on-campus MSBA adopting this at scale, or a third program joining.
• An institutional requirement appears that University-affiliated code or student work live in University-controlled infrastructure.
• Someone gets the Copilot answer in writing and it is favourable, removing the one genuine unknown. githubsupport@uillinois.edu is the address; the question is whether joining a University organization affects a student’s GitHub Education Copilot Student entitlement, and whether any seats would be assigned to organization members.

If it is revisited, two conditions from the earlier draft are worth carrying forward: the student’s personal portfolio repository stays outside the enterprise, both so that it survives graduation and NetID deprovisioning and so that the University-ownership clause never attaches to a repository built on a student’s own personal data; and the Copilot answer comes in writing before anything migrates.

8. FERPA and privacy

Three rules, one of which fixes something that is wrong right now.

Rule 1: organization membership is private, and the membership list is never published. GitHub organization membership can be public or private per member. Default it to private. A public member list of a course organization is a published class roster.

Rule 2: no identifiable information in repository names, ever. This is the one that is currently broken, and program leadership should know about it. The legacy BADM554 organization holds Fall 2025 GitHub Classroom repositories named after individual students, which is how Classroom works by default: assignment-3-jsmith. Those URLs are a per-student record on a third-party platform, and any of them that are public are a published one. The exposure is live today.

Closing it does not need a decision here: the instructor is winding that organization down, the repositories concerned are student work from a closed term with no retention reason to keep them on a third-party platform, and none of it is in the organization this proposal is about. What program leadership should take from it is the rule, not the cleanup. Treat it as the cautionary example whenever anyone proposes an automation that generates repository names from a roster, which is precisely the shape of automation Classroom offers.

Rule 3: the roster mapping lives in Canvas, not in GitHub. Canvas is already the FERPA system of record. The student’s GitHub handle is submitted through one Canvas assignment and the mapping stays there. A pseudonymous handle is acceptable; the Canvas submission is what ties it to a person. This is one of the quieter arguments against GitHub Classroom, which necessarily replicates an identified roster into GitHub in order to function at all.

8.1 What may and may not be required of a student

The governing principle: the university may require a student to produce work. It may not require a student to publish personal information on a third-party platform as a condition of a grade.

This contradicts a line currently in the program documentation, and I am asking to change it. design/faculty_resources.md states “All projects in public repos. Commit history used for contribution assessment” [found: design/faculty_resources.md §3.1]. The first half of that should be softened program-wide to private by default, public by the student’s deliberate act. The second half is fully preserved and is unaffected: the instructor is a collaborator on every repository and can read the commit history whether or not it is public.

The reason this matters most acutely in BADM 554 is that it is the one course built on students’ own personal data exports (their own streaming, viewing, or fitness history). Compelling a student to publish a repository built on their own listening history is not a defensible course requirement no matter how carefully the ignore file is configured. But the principle is not 554-specific and should be a program-level position, not a quiet local exception.

Making the repository public in the final week remains the goal. It is how the portfolio promise gets kept. It should be a coached, deliberate act with a scrub checklist, not a points-bearing requirement.

8.2 The technical control that does the actual work

Policy does not prevent a data leak; a shipped .gitignore does. Every program template repository ships with data directories, environment files, and export formats already ignored, before a student ever sees it. This is a program-owned standard (§3) precisely so that no course has to remember it. Git history preserves a committed file after deletion, so this control has to work by construction rather than by instruction.

9. The Copilot assessment problem

This is the section that has consequences beyond GitHub, and it needs a program-level answer.

9.1 The problem, stated plainly

The program’s assessment model stages individual work as pre-AI, then AI, then post-AI, with an AI Attribution Log recording what the AI contributed [found: design/assessment_strategy.md]. The point of the pre-AI phase is to capture the student’s own unassisted thinking before the assistant touches it.

GitHub Copilot is now a standard, free, assumed part of the toolkit [found: program/tools.md §2; internal decision registry, 2026-07-26], and it is installed in VS Code, which is the program’s primary IDE [found: program/design_principles.md Principle 4].

Copilot is ambient. It produces inline ghost-text suggestions continuously, without being asked, as the student types. So:

1. The pre-AI phase is not pre-AI. A student opens the notebook to write their own first attempt, and a complete answer appears in grey text before they have finished the first line.
2. It is invisible in the artifact. An accepted inline completion is indistinguishable from typed code. Nothing in the file records it.
3. Self-reported attribution will miss it. Not through dishonesty. The attribution log is event-shaped, with columns for date, tool, task, prompt, output, and how it was validated [found: design/assessment_strategy.md Appendix A]. There is no honest way to log four hundred inline completions. A student asked to do so will log nothing, or will invent something.

The net effect: in every course that uses the pre-AI framing, that phase is currently compromised, and the attribution log understates AI use by an unknown amount. This is not a GitHub problem. It arrived with the 2026-07-26 decision to assume Copilot, and no course has addressed it.

9.2 The options, honestly

Option A: name the toggle. Tell students to disable inline suggestions during the pre-AI phase. In VS Code this is a single setting, github.copilot.enable, also reachable from the Copilot status icon in the bottom bar. Cost: one instruction. Weakness: unverifiable and entirely dependent on compliance. It is an honour-system control on the exact thing we are trying to observe.

Option B: redesign what pre-AI means. Stop treating the pre-AI phase as “write the code yourself” and start treating it as “state what you are going to do and why”. The student writes, before touching the data: the question being answered, the shape of the answer they expect, and what result would tell them they got it wrong. Cost: every assignment using the framing needs its pre-AI prompt rewritten once, roughly an hour each, plus a paragraph in the assessment strategy. Strength: autocomplete cannot supply any of it. Copilot can complete a query. It cannot predict what a specific student expects the answer to look like, and it cannot state what would falsify it.

Option C: move pre-AI out of the editor. Do the pre-AI phase in Canvas, or on paper, or in a plain text box with no assistant present. Cost: adds a tool and a context switch to every assignment. Weakness: fragments a single piece of work across two systems for an online cohort that already has a lot of tabs open, and it makes the pre-AI phase feel like an obstacle rather than part of the work.

Option D: drop the framing. Rejected. The pre-AI phase is load-bearing for the AIAS declarations and for the Learning Trajectory dimension. Dropping it would remove the program’s main evidence of individual thinking and would not be defensible at accreditation.

9.3 Recommendation

Adopt Option B as the program answer, with Option A alongside it as a supporting instruction.

Redesign the pre-AI phase to assess prediction and judgement rather than syntax recall. Ask students to commit, in writing, to what they expect before they see the result. Then have the AI phase produce the answer, and have the post-AI phase compare the two. The gap between prediction and result is the learning, it is visible in the artifact, and it is the thing that transfers to a job.

Name the toggle as well, framed as a one-time exercise rather than a permanent rule: in the first course, ask students once to turn inline suggestions off and notice what it feels like to think without them. That teaches a control they will need for the rest of their career, and it costs one paragraph.

Why this and not the alternatives. Option A alone is an unenforceable rule about an unobservable behaviour, which is the weakest form of assessment design available. Option C buys enforcement by making the work worse. Option B is the only one that makes the pre-AI phase more valuable than it was before Copilot existed, because “predict the answer, then check” is a better analytical habit than “write the query from memory” ever was. It also aligns exactly with the program’s own Specify / Execute / Verify framing, where execution is explicitly the part AI handles [found: design/why_show_your_thinking.md].

Cost, stated honestly. Every course using the pre-AI framing revises its pre-AI prompts once. About an hour per assignment. For a course with seven weekly assignments, that is one working day, one time. Plus one paragraph added to design/assessment_strategy.md defining the logging floor:

Log the decisions, not the keystrokes. Inline completions and autocomplete are assumed and do not need logging. Log any time AI produced something you evaluated and then accepted, rejected, or modified: a query you did not write yourself, a design option, a fix to an error you did not understand.

That paragraph is what makes the attribution log honest again. Without it, the log asks for something impossible and gets something fictional.

10. Cost and effort

No budget is requested. No licences, no staff, no student cost. Everything below is time, and only the time that follows from a decision someone else has to make. Setup work that falls to the proposer regardless (template repositories, the program .gitignore standard, the submission-convention text block, winding down the legacy organization) is tracked separately and is not an approver’s concern.

With the enterprise move declined (§7), there is no longer an external wait anywhere in this plan. Everything approved can start the week it is approved.

One timing dependency worth flagging even though it needs no approval: Copilot education verification has a lead time, so the verification instructions belong in pre-program onboarding rather than Week 1. A student who starts verification in Week 1 has no Copilot in Weeks 1 and 2. That sits with the Essentials onboarding course.

11. Risks

12. Open questions for the approvers

Questions 1 to 4 are the four asks in §1, restated as the specific thing each one needs answered. Questions 5 and 6 are resourcing questions that no decision in §1 settles.

1. Who is the second organization owner, and who signs off on the succession plan? (Ask 1, §5.1.) This is the most important question in the document and the only one with no external dependency. The recommendation is a program-operations role rather than a second instructor, for the reason in §5.1. It needs a name, not agreement in principle, and it should be settled before any student work lands in the org. With the enterprise move declined (§7), nothing else forces this.
2. Is the version-control outcome in §4 adopted, and will all six courses carry the reinforcement convention? (Ask 2.) The outcome text is already staged in program/program_learning_outcomes.md. Adopting the outcome without the cross-course submission convention leaves it a single-course topic assessed fifteen months later, so the second half of the question is the load-bearing one. Separately: who completes the PLO set, and when? That document is deliberately a stub with one entry. The rest of the outcome set is a program-leadership and faculty exercise, open as an action item since 2026-04-10 [found: internal action-item tracker], and it is a prerequisite for the AACSB curriculum map. Confirming outcome 1 does not close it.
3. Is the “all projects in public repos” line in design/faculty_resources.md open to being softened program-wide to private-by-default, public-by-deliberate-act (§8.1)? (Ask 3.) Or should BADM 554 hold a documented exception instead? The program-wide change is cleaner and the exception is a precedent.
4. Who owns the pre-AI redesign (§9.3) across courses? (Ask 4.) It is a program-level design change with per-course implementation. Is that the assessment strategy owner, or each instructor, or a coordinated pass?
5. Does the on-campus MSBA adopt this now or later? Adopting later is fine. Adopting differently is what costs. This is the one part of the single-organization premise (§5) that is not the proposer’s to decide.
6. Who answers a student’s GitHub problem at 11pm in Week 1? The failure curve is front-loaded and the online cohort is asynchronous. If there is no TA, this is an instructor time commitment that should be planned rather than discovered. Declining the enterprise move (§7) reduces this by removing the enforced SSO layer, but does not remove it.

Appendix: sourcing summary

Found in this repository, cited inline: the 2026-07-26 restoration of free Copilot for verified students and the monthly eligibility re-check; the student-paid base AI layer and the $500 cap; the AI Attribution Log Appendix A shape; the AIAS declaration convention; the Specify / Execute / Verify framing; the “all projects in public repos” line; VS Code plus Copilot as the primary IDE; Martin Maurer’s AACSB guidance on outcome wording and individual-level assessability; the fact that the program learning outcomes had never been documented, open as an action item since 2026-04-10 (now given a home, still incomplete, at program/program_learning_outcomes.md).

Found in the BADM 554 repository, referenced not duplicated: the course-level GitHub design at ~/teaching/badm554/docs/superpowers/specs/2026-07-28-github-strategy-proposal.md.

Settled inputs supplied by Vishal, not independently verified here: that Business-Analytics-at-Gies exists, is sole-admin, and holds two repositories; that the legacy BADM554 org holds Fall 2025 Classroom debris including per-student repository names and is being wound down; that GitHub Classroom was tried in Fall 2025 and judged not worth the overhead.

Found on University of Illinois public knowledge-base pages, read directly and quoted inline (§7.2), retained as the record of an evaluated-and-declined option: that the U of I System holds a shared GitHub Enterprise Cloud licence (answers.uillinois.edu/illinois/129281; help.uillinois.edu Service ID 535); that organization membership is tied to the personal GitHub account rather than the NetID, and that invitees may sign in with an existing GitHub account, which together establish SAML identity linking rather than Enterprise Managed Users (answers.uillinois.edu/systemoffices/102587 and /102588); that organization creation requires two owners by name and NetID and is requested through githubsupport@uillinois.edu (help.uillinois.edu KB 2185); the enforced settings, including required SAML SSO, base member permission of “None”, private-only repository creation, and the system-wide reach of “internal” visibility (answers.uillinois.edu/systemoffices/102099); and the End User Service Agreement’s data-classification limits and University-ownership clause (/102098).

Found in GitHub’s own documentation: the Enterprise Managed Users restrictions used for contrast in §7.2; the Copilot free-tier exclusion for users with organization or enterprise access; and the automatic cancellation of a personal Copilot plan when an organization seat is assigned.

Left unverified, and now moot unless the enterprise question is reopened (§7.5): whether joining a University organization affects a student’s free Copilot entitlement (this was the blocking question and it was never answered); the up-to-two-weeks provisioning estimate, which appears only in search results attributed to the 403-blocked service page; whether any session-timeout policy is enforced; and whether NetID deprovisioning removes organization membership automatically. All four would need answering from githubsupport@uillinois.edu before anyone relied on them. The service page at web.uillinois.edu/github returns 403 to automated retrieval, which is why the knowledge-base pages above were used instead.