Project Specification: Equity Analysis Dashboard
Course: CSCI-2025: Data Manipulation and Visualization (Winter Term)
Client: Mark Heidrich, Associate Vice President for Institutional Effectiveness and Registrar
1. Project Overview
The class will function as a single data science consultancy divided into four “Feature Pods.” The goal is to build one unified Shiny Dashboard that allows academic departments to analyze equity gaps in their programs.
Instead of building four separate apps, we are building four Modules that integrate into a single “Golden Github Repository.”
2. Team Structure
A. The Core Team (Management)
A team of students responsible for overall project health and cross-team consistency. The team will be led by two VPs and Dr. Friedlander.
1. The Product Owner (The “Client VP”) * Responsibility: The “Voice of the Client” and Narrative consistency. * Concrete Deliverables (Coding): * Codes the Landing Page (The “Home” tab). * Writes global.R (loading data and packages). * Writes styles.css (defining colors/fonts). * Management Duty: Leads the UI, Shiny, and Narrative, Guilds. Directs teams on styling.
2. The Lead Architect (The “Tech VP”) * Responsibility: Repository health and final integration. * Concrete Deliverables (Coding): * Maintains app.R (the shell application). * Manages site deployment. * Codes the “About/Methodology” page. * Management Duty: Leads the Code and Data guilds. Accepts/rejects Pull Requests from Feature Teams.
3. Remaining Team Leads: See section on Guilds below.
B. The Four Feature Teams
The rest of the class is divided into four pods. Each pod owns one “tab” of the final application.
- Pod 1: Enrollment
- Pod 2: Performance
- Pod 3: Retention
- Pod 4: Outcomes
Individual Roles within Feature Teams
Every student has a specific title and responsibility within their team.
| Role | Responsibility | Key Deliverable |
|---|---|---|
| GitHub Sentinel / Team Leader | Manages the git branch, resolves merge conflicts, and manages renv.lock. |
The clean Merge; Repo health. |
| Data Steward (Data Engineer) | ETL processes and Privacy Protection. Masks data if N < 5. | clean_data.R; Anonymized datasets. |
| Chart Artist (Viz Specialist) | Creates high-quality static visualizations. | Plot functions (e.g., plot_gpa()). |
| Interface Architect (Shiny Dev) | Wires the UI/Server logic. Connects inputs to the plots. | ui and server module code. |
| Narrative Lead (Context/QA) | Writes dynamic “Mad Libs” text to interpret charts automatically. | renderText() logic; Help tooltips. |
3. Collaboration: “The Guilds”
To ensure the dashboard looks cohesive, students with matching roles across teams will meet in “Guilds”.
- The Code Guild (Sentinels): Led by the Lead Architect. Agrees on Git branching and dependencies.
- The UI Guild (Chart Artists): Led by the Product Owner. Decides aesthetic conventions (colors, fonts, themes).
- The Data Guild (Stewards): Agrees on variable naming conventions and the “Small N” suppression threshold.
- The Shiny Guild (Interface Architects): Standardizes UI layout and input types across modules.
- The Narrative Guild (Narrative Leads): Standardizes the “Mad Libs” text structure for consistency takes and maintains notes.
4. Technical Architecture
The “Golden Repo”
Students will clone a repository pre-scaffolded by the instructor.
global.R: Shared libraries and data loading (Read-Only).app.R: The main shell application (Read-Only).modules/:mod_enrollment.R(Pod 1 Workspace)mod_performance.R(Pod 2 Workspace)mod_retention.R(Pod 3 Workspace)mod_outcomes.R(Pod 4 Workspace)
data/: Stores the clean data files.renv/: Manages package dependencies.
5. Development Workflow Rules
- Branching: Use Trunk-Based Development. Branch from
main->feature/team-name-> PR back tomain. - No Direct Pushes: All code must enter
mainvia a Pull Request (PR). - The “Sentinel” Rule: Only the Team GitHub Sentinel is authorized to open a PR.
- Dependency Lockdown: Do not install new library packages without instructor approval. If approved,
renv::snapshot()must be run immediately.