diff --git a/assets/site.css b/assets/site.css index 5cb7770..7de111f 100644 --- a/assets/site.css +++ b/assets/site.css @@ -346,6 +346,7 @@ pre code { .section { margin-bottom: 1.5rem; padding: 1.5rem; + scroll-margin-top: 1rem; border: 1px solid var(--color-light); border-radius: 16px; background-color: white; diff --git a/build_site.py b/build_site.py index d6cdbdf..4413dae 100644 --- a/build_site.py +++ b/build_site.py @@ -42,7 +42,7 @@ "student/pull-requests-and-reviews.md", "student/milestone-1-technical-design-and-repository.md", "student/milestone-2-proof-of-concept.md", - "student/week-10-checkpoint.md", + "student/week-11-checkpoint.md", "student/final-submission.md", "student/rubrics.md", "student/report-template.md", @@ -54,6 +54,7 @@ "projects/project-3-geospatial-intelligence.md", "projects/project-4-zoonotic-risk-prediction.md", "projects/project-5-rwanda-medical-assistant.md", + "projects/project-6-dengue-early-warning.md", ] PROJECT_DOCUMENTATION_ORDER = [ @@ -287,30 +288,33 @@ def parse_project_brief(path: Path) -> dict[str, str]: def build_project_brief_documents() -> list[dict[str, Any]]: - project_documents = [] + project_sections = [] for index, relative_path in enumerate(PROJECT_BRIEF_ORDER): content_path = PROJECT_DOCS_DIR / relative_path brief = parse_project_brief(content_path) - slug = slug_from_path(relative_path) - output_path = ( - BUILD_DIR / "project-documentation" / "projects" / slug / "index.html" - ) - project_documents.append( + _, body, _ = load_markdown_page(content_path) + title, body = extract_h1(body, brief["title"]) + project_sections.append( { - "page_id": f"project-docs:{relative_path}", - "page_title": brief["title"], - "nav_title": brief["title"], - "page_heading": brief["title"], - "sidebar_group": "Project Briefs", - "content_path": content_path.relative_to(ROOT).as_posix(), - "output_path": output_path, - "order": 4 + index, + "title": title, + "anchor": slug_from_path(relative_path), + "html": render_markdown(body), "lead": brief["lead"], "team_size": brief["team_size"], "short_description": brief["short_description"], } ) + overview_section = { + "title": "Overview", + "anchor": "overview", + "html": render_markdown(build_project_brief_overview(project_sections)), + } + tabbed_documents = [overview_section, *project_sections] + for index, section in enumerate(tabbed_documents): + section["index"] = index + section["step"] = index + 1 + overview_output = BUILD_DIR / "project-documentation" / "projects" / "index.html" overview = { "page_id": "project-docs:briefs", @@ -320,30 +324,41 @@ def build_project_brief_documents() -> list[dict[str, Any]]: "sidebar_group": "Project Briefs", "output_path": overview_output, "order": 3, - "body": build_project_brief_overview(project_documents, overview_output), + "tabbed_documents": tabbed_documents, + "no_pagination": True, } - return [overview, *project_documents] + return [overview] -def build_project_brief_overview( - projects: list[dict[str, Any]], output_path: Path -) -> str: +def build_project_brief_overview(projects: list[dict[str, Any]]) -> str: rows = [] for project in projects: + team_size = str(project.get("team_size", "")) + team_size = re.sub(r"\bstudents?\b", "", team_size, flags=re.IGNORECASE) + team_size = re.sub(r"\s+", " ", team_size).strip(" .,;") + project_number_match = re.match(r"Project\s+(\d+):", str(project["title"])) + project_label = ( + f"Project {project_number_match.group(1)}" + if project_number_match + else str(project["title"]) + ) rows.append( ( - f"[{project['page_title']}]({relative_url(output_path, project['output_path'])})", - str(project.get("lead", "")), - str(project.get("team_size", "")), + f"[{project_label}](#{project['anchor']})", + str(project["title"]), + team_size, str(project.get("short_description", "")), ) ) - table = markdown_table(rows, ["Project", "Lead", "Team size", "Short description"]) + table = markdown_table( + rows, ["Project", "Project title", "Team size", "Short description"] + ) intro = ( - "Each project has a full brief on its own page. " - "The table below summarizes all briefs." + "This page summarizes the proposed course projects. " + "Use the links below to jump to each full project brief. " + "Before writing Milestone 1, read your assigned project brief carefully and align your technical design with its proof-of-concept expectations." ) - return f"{intro}\n\n{table}" + return f"{intro}\n\n{table}\n\nThe proof-of-concept expectations in your assigned brief are binding for Milestone 2." def markdown_table(rows: list[tuple[str, ...]], headers: list[str]) -> str: @@ -570,6 +585,7 @@ def render_page( "page_heading": str(metadata.get("page_heading", "")), "sections": sections, "section_count": len(sections), + "no_pagination": bool(metadata.get("no_pagination")), "previous_week_url": ( relative_url(output_path, previous_week["output_path"]) if previous_week diff --git a/content/pages/home.md b/content/pages/home.md index 3083844..6655344 100644 --- a/content/pages/home.md +++ b/content/pages/home.md @@ -23,7 +23,7 @@ This course teaches the principles and practice of designing, building, and rigo ## Course Overview -The course is organized into **three thematic blocks** plus a final symposium. Each teaching week pairs one domain lecture with one engineering lecture, then applies the week's ideas in a project studio. +The course is organized into **three thematic blocks** plus a final symposium. Each teaching week pairs one context lecture with one engineering lecture, then applies the week's ideas in a project studio. {{ weeks_table }} @@ -33,7 +33,7 @@ The course is organized into **three thematic blocks** plus a final symposium. E Students study humanitarian systems, community health, epidemics, and health systems, then translate these constraints into engineering decisions. -**Domain themes** +**Context themes** - Humanitarian systems - Community medicine @@ -53,7 +53,7 @@ Students study humanitarian systems, community health, epidemics, and health sys Students explore how physicians reason, how decision support systems evolved, and why implementation is harder than engineering. -**Domain themes** +**Context themes** - Clinical reasoning - Diagnosis and triage @@ -72,7 +72,7 @@ Students explore how physicians reason, how decision support systems evolved, an Students trace how medicine decided to trust systematic evidence over expert authority, from early clinical trials to the current crisis in clinical AI evaluation. -**Domain themes** +**Context themes** - Clinical trials - Implementation science @@ -92,7 +92,7 @@ Students trace how medicine decided to trust systematic evidence over expert aut Students present final project outcomes and deployment-oriented documentation. -**Domain themes** +**Context themes** - Final synthesis - Project communication @@ -108,7 +108,7 @@ Students present final project outcomes and deployment-oriented documentation. | Item | Description | |---|---| | Weeks | 14 | -| Lectures | 24 paired lectures: 12 domain lectures and 12 technical lectures | +| Lectures | 24 paired lectures: 12 context lectures and 12 engineering lectures | | Project studios | 10 studio sessions with senior engineers to guide AI system development | | Weekly workload | 2h lectures, 1h exercise, 12h project development, 1h independent study | | Presentations | Midterm presentation and final project presentation | @@ -120,8 +120,8 @@ Students present final project outcomes and deployment-oriented documentation. | Session | Purpose | |---|---| -| Domain lecture | What is the context of the problem we are solving? | -| Engineering lecture | Translate domain concepts into engineering principles, algorithms, software, and deployment strategies. | +| Context lecture | What is the context of the problem we are solving? | +| Engineering lecture | Translate context concepts into engineering principles, algorithms, software, and deployment strategies. | | Studio | Apply the week's ideas to the semester-long project. | ## Assessment diff --git a/content/project-documentation/README.md b/content/project-documentation/README.md index 0ca7a45..032bf89 100644 --- a/content/project-documentation/README.md +++ b/content/project-documentation/README.md @@ -11,22 +11,18 @@ This page collects the student-facing project documentation for the course. | [`student/pull-requests-and-reviews.md`](student/pull-requests-and-reviews.md) | Practical guide for PRs and teammate reviews | | [`student/milestone-1-technical-design-and-repository.md`](student/milestone-1-technical-design-and-repository.md) | Week 3 technical design and repository instructions and rubric | | [`student/milestone-2-proof-of-concept.md`](student/milestone-2-proof-of-concept.md) | Week 8 proof-of-concept instructions and rubric | -| [`student/week-10-checkpoint.md`](student/week-10-checkpoint.md) | Non-graded checkpoint preparation guide | +| [`student/week-11-checkpoint.md`](student/week-11-checkpoint.md) | Non-graded checkpoint preparation guide | | [`student/final-submission.md`](student/final-submission.md) | Week 14 final submission, report, and live demo requirements | | [`student/rubrics.md`](student/rubrics.md) | Consolidated project rubrics | -| [`student/report-template.md`](student/report-template.md) | Suggested final report structure and individual contribution report guidance | +| [`student/report-template.md`](student/report-template.md) | Suggested final report structure and contribution statement guidance | ## Project Briefs -Each project brief has its own page. A quick summary of all briefs is shown on the Project Briefs overview page, which comes before the individual project pages. +The Project Briefs page starts with an overview section that links to each project, followed by the full project briefs on the same page. -| File | Project | +| Page | Contents | |---|---| -| [`projects/project-1-offline-translator.md`](projects/project-1-offline-translator.md) | Offline translator for low-resource languages | -| [`projects/project-2-public-health-messenger.md`](projects/project-2-public-health-messenger.md) | Interactive public health messenger | -| [`projects/project-3-geospatial-intelligence.md`](projects/project-3-geospatial-intelligence.md) | Geospatial intelligence for public health decisions | -| [`projects/project-4-zoonotic-risk-prediction.md`](projects/project-4-zoonotic-risk-prediction.md) | AI-powered zoonotic disease risk prediction | -| [`projects/project-5-rwanda-medical-assistant.md`](projects/project-5-rwanda-medical-assistant.md) | AI-powered medical assistant for health workers in Rwanda | +| [`projects/`](projects/) | Overview and all project briefs | ## Confirmed Technical Baseline diff --git a/content/project-documentation/projects/project-6-dengue-early-warning.md b/content/project-documentation/projects/project-6-dengue-early-warning.md new file mode 100644 index 0000000..02bcec8 --- /dev/null +++ b/content/project-documentation/projects/project-6-dengue-early-warning.md @@ -0,0 +1,105 @@ +# Project 6: AI-Powered Dengue Early-Warning Platform + +Proposed team size: 5 students. + +Project lead: To be confirmed. + +Keywords: machine learning, time series forecasting, public health, data visualization, full-stack development, explainable AI. + +## Short Description + +Build an AI-powered dengue early-warning platform that predicts upcoming disease incidence and turns these forecasts into interpretable information that public health decision-makers can explore and use. + +## Motivation + +Dengue outbreaks can place substantial pressure on health systems. Anticipating increases in cases can help public health agencies prepare resources, plan interventions, and communicate risk earlier. + +This project is built around the DrivenData DengAI: Predicting Disease Spread challenge. The competition provides the machine-learning component, but the project goes beyond competition scoring. Students should develop rigorous temporal validation, compare forecasting approaches, and turn the model into a usable decision-support platform. + +The final prototype should demonstrate the complete pipeline from reproducible data processing and ML experimentation to an interpretable forecasting service that could support public-health decision-making. + +Challenge link: https://www.drivendata.org/competitions/44/dengai-predicting-disease-spread/ + +## Intended Users + +Potential users include: + +- public health decision-makers; +- epidemiological surveillance teams; +- outbreak preparedness teams; +- analysts comparing dengue risk across time and locations; +- health agencies planning resources or interventions. + +## Possible Features + +Possible features include: + +- reproducible DengAI data ingestion and preprocessing; +- temporal train, validation, and test splits; +- comparison of baseline and stronger forecasting models; +- backend endpoint serving forecasts; +- interactive dashboard for historical incidence and forecasts; +- visualization of environmental conditions; +- uncertainty visualization; +- explanation of factors influencing predictions; +- forecast export or summary for decision-makers. + +The team should avoid treating the project as only a leaderboard exercise. The platform should make forecasts interpretable and usable. + +## Design Questions + +Consider: + +- What forecast horizon is most useful for a public health decision-maker? +- What temporal validation strategy avoids future leakage? +- Which baseline is meaningful for dengue incidence forecasting? +- How should uncertainty be represented to non-technical users? +- What environmental or seasonal factors appear to influence predictions? +- How should the system distinguish historical observations from forecasts? +- What action could a decision-maker take based on the dashboard? + +## Technical Directions + +Possible technical components include: + +- DrivenData DengAI dataset processing; +- time series feature engineering; +- baseline forecasting models; +- machine learning models for incidence prediction; +- temporal cross-validation or backtesting; +- model explainability; +- backend forecast service; +- interactive dashboard; +- visualization of historical cases, predicted cases, uncertainty, and drivers. + +## Proof-Of-Concept Expectation + +The proof of concept should demonstrate one valid dengue forecasting and decision-support path. + +Minimum convincing POC: + +- the system loads the DengAI data or a documented representative subset; +- the team defines a clear forecast target, city, time unit, and forecast horizon; +- the system uses a temporal split that avoids future leakage; +- the system trains or runs at least one baseline forecasting model; +- the system generates dengue incidence forecasts for a held-out period; +- the forecasts are displayed in a simple dashboard or visualization alongside historical incidence; +- the system shows at least one uncertainty, error, or explanation signal useful to a public health user. + +The POC may use one city, one baseline model, and a simple dashboard. It should not be only a competition notebook or only a static visualization without a reproducible forecasting path. + +## Evaluation Ideas + +Possible evaluation approaches include: + +- comparing against a seasonal or persistence baseline; +- using temporal backtesting; +- reporting the DrivenData metric and at least one interpretable error summary; +- analyzing errors by season, city, or outbreak period; +- evaluating calibration or uncertainty quality if uncertainty is provided; +- checking whether explanations align with known temporal or environmental patterns; +- testing whether the dashboard makes forecast limitations visible. + +## Final Demo Target + +The final demo should show the full path from data processing to forecast generation and dashboard exploration. A public health decision-maker should be able to inspect historical dengue incidence, predicted cases, uncertainty or error information, and explanations of important factors influencing the forecast. diff --git a/content/project-documentation/student/final-submission.md b/content/project-documentation/student/final-submission.md index 88f8655..9f15c36 100644 --- a/content/project-documentation/student/final-submission.md +++ b/content/project-documentation/student/final-submission.md @@ -2,7 +2,7 @@ Deadline: Friday of Week 14, December 18, 21:59. -Weight: 40% of the course grade. +Weight: 40% of the course grade, equivalent to 50% of the project grade. The final submission includes code, report, documentation, final presentation, and a live demo in front of the class. @@ -17,7 +17,7 @@ Required final artifacts: - reproducibility instructions; - demo instructions; - final presentation material; -- one individual contribution report per team member; +- individual contribution statement signed by all team members; - handover or maintenance documentation. ## Final Report @@ -40,22 +40,22 @@ The report should include: References and appendices do not count toward the 5-page limit. Appendices should support the report, not replace it. -## Individual Contribution Reports +## Individual Contribution Statement -Your repository must include one short individual contribution report per team member. +Your repository must include one signed team contribution statement. -Each report should be written by the student whose contribution it describes. It should include: +The statement should include: -- main technical, design, evaluation, documentation, and presentation contributions; +- each team member's main contributions; +- major implementation, design, evaluation, writing, and presentation responsibilities; - links or references to relevant pull requests, issues, commits, experiments, or report sections; -- decisions the student influenced and tradeoffs they handled; -- parts of the project they reviewed, tested, debugged, or helped integrate; -- any major blockers, handovers, or unfinished work relevant to their contribution. +- any substantial deviations from the expected contribution distribution; +- signatures or explicit signed approval from all team members. Recommended location: ```text -docs/individual-reports/.md +docs/contribution-statement.md ``` ## Final Presentation And Live Demo @@ -127,4 +127,4 @@ Avoid: - reporting only successful examples; - hiding limitations; - making the report longer by moving core content to appendices; -- submitting individual contribution reports that are vague or disconnected from repository evidence. +- submitting a contribution statement that is vague, unsigned, or disconnected from repository evidence. diff --git a/content/project-documentation/student/milestone-1-technical-design-and-repository.md b/content/project-documentation/student/milestone-1-technical-design-and-repository.md index 9beb496..06281a6 100644 --- a/content/project-documentation/student/milestone-1-technical-design-and-repository.md +++ b/content/project-documentation/student/milestone-1-technical-design-and-repository.md @@ -2,7 +2,7 @@ Deadline: Friday of Week 3, September 25, 21:59. -Weight: 10% of the course grade. +Weight: 10% of the course grade, equivalent to 12.5% of the project grade. ## Purpose @@ -14,7 +14,7 @@ Your technical design should also address the five recurring project questions f ## Assigned Project -Your team is assigned one of the proposed course projects. Read the brief for your project in `project-documentation/projects/` before writing the design. +Your team is assigned one of the proposed course projects. Read the brief for your project on the Project Briefs overview page before writing the design. Your technical design must be consistent with your assigned project brief. @@ -55,7 +55,7 @@ Your technical design should include: ## Additional Requirements For ML Projects -All five course projects involve prediction, classification, ranking, generation, retrieval, or risk scoring. Include: +All six course projects involve prediction, classification, ranking, generation, retrieval, or risk scoring. Include: - prediction target or model objective; - available data and data assumptions; @@ -80,6 +80,7 @@ Your repository should include: - CI that runs formatting checks, linting, type checks, and tests; - configuration separated from code; - instructions for obtaining or generating a small sample of the data; +- data licensing and provenance documented in `data/DATASET_LICENSE.md` and `data/data-provenance.md` when data is used; - no credentials committed to Git; - no large files committed to Git unless staff approved them; - evidence of pull-request-based collaboration. diff --git a/content/project-documentation/student/milestone-2-proof-of-concept.md b/content/project-documentation/student/milestone-2-proof-of-concept.md index 0e52b44..7612933 100644 --- a/content/project-documentation/student/milestone-2-proof-of-concept.md +++ b/content/project-documentation/student/milestone-2-proof-of-concept.md @@ -2,9 +2,9 @@ Deadline: Friday of Week 8, November 6, 21:59. -Weight: 20% of the course grade. +Weight: 20% of the course grade, equivalent to 25% of the project grade. -The midterm oral presentation is a separate 10% assessment. +The midterm oral presentation is a separate 10% course-grade assessment, equivalent to 12.5% of the project grade. ## Purpose @@ -46,7 +46,7 @@ Your milestone document should include: ## Project-Specific Expectations -Each project has its own proof-of-concept expectations. See the project brief for your assigned project in `project-documentation/projects/`. +Each project has its own proof-of-concept expectations. See your assigned project brief on the Project Briefs overview page. General examples: @@ -57,6 +57,7 @@ General examples: | Geospatial intelligence | One public health query triggers one verifiable spatial operation and displays evidence | | Risk prediction | One valid dataset path trains or runs a baseline, generates predictions, and displays risk information | | Medical assistant | One multilingual question goes through the interface, language/model pipeline, answer display, and speech-related path | +| Dengue early warning | One temporal data path trains or runs a baseline forecast, evaluates on a held-out period, and displays forecasts with uncertainty, error, or explanation information | Dummy or small data is acceptable only if clearly identified. A convincing proof of concept makes clear what is real and what is simulated. diff --git a/content/project-documentation/student/project-overview.md b/content/project-documentation/student/project-overview.md index d65ae99..22be6f1 100644 --- a/content/project-documentation/student/project-overview.md +++ b/content/project-documentation/student/project-overview.md @@ -27,21 +27,21 @@ Deadlines are set at 21:59. Students will choose on the first lecture whether to | September 7 | Week 1 | Project descriptions and scopes released | | September 20, 21:59 | Sunday of Week 2 | Group assignment finalized | | September 25, 21:59 | Friday of Week 3 | Technical design and reproducible repository skeleton | -| November 6, 21:59 | Friday of Week 8 | Proof of concept technical checkpoint and midterm oral presentation | -| November 23-27 | Week 10 | 30-minute team checkpoint | +| November 6, 21:59 | Friday of Week 8 | Proof of concept technical checkpoint and separate midterm oral presentation | +| November 23-27 | Week 11 | 30-minute team checkpoint | | December 18, 21:59 | Friday of Week 14 | Final submission | ## Assessment -The table below mirrors the assessment structure in the course overview. +Course-grade weights have priority. The project-related components account for 80% of the course grade; the project-grade equivalents below normalize those components to 100% of the project grade. -| Component | Weight | Project Documentation Mapping | -|---|---:|---| -| Project report and code, with final presentation with a live demo | 40% | Final submission | -| Initial submission: conception and reproducible base code | 10% | Technical design and reproducible repository skeleton | -| Midterm checkpoint: technical project design | 20% | Proof of concept technical checkpoint | -| Midterm oral presentation with live demo | 10% | Week 8 oral presentation and live demo | -| In-class tests and quizzes, including ethics certification | 20% | Assessed outside the team repository | +| Component | Course Grade | Project Grade Equivalent | Project Documentation Mapping | +|---|---:|---:|---| +| Initial submission: conception and reproducible base code | 10% | 12.5% | Technical design and reproducible repository skeleton | +| Midterm checkpoint: technical project design | 20% | 25% | Proof of concept technical checkpoint | +| Midterm oral presentation with live demo | 10% | 12.5% | Week 8 oral presentation and live demo | +| Project report and code, with final presentation with a live demo | 40% | 50% | Final submission | +| In-class tests and quizzes, including ethics certification | 20% | Not part of project grade | Assessed outside the team repository | ## Repository-Based Submission @@ -77,7 +77,7 @@ By the end of the course, each team should submit: - a final report submitted as a PDF inside the repository; - a live demo during the final class presentation; - final presentation material; -- an individual contribution report for each team member; +- an individual contribution statement signed by all team members; - handover or maintenance documentation. ## What Counts As Success diff --git a/content/project-documentation/student/project-setup.md b/content/project-documentation/student/project-setup.md index 6f22376..39ddad4 100644 --- a/content/project-documentation/student/project-setup.md +++ b/content/project-documentation/student/project-setup.md @@ -80,15 +80,16 @@ Recommended structure: | |-- milestone-1-technical-design-and-repository.md | |-- milestone-2-proof-of-concept.md | |-- final-report.pdf -| `-- individual-reports/ -| `-- .md +| `-- contribution-statement.md |-- src/ | `-- / |-- tests/ |-- configs/ |-- scripts/ |-- data/ -| `-- README.md +| |-- README.md +| |-- DATASET_LICENSE.md +| `-- data-provenance.md `-- outputs/ `-- README.md ``` @@ -158,6 +159,11 @@ If your project needs data, include a `data/README.md` explaining: - how to download or generate a small sample; - what should not be committed. +Also document dataset licensing and provenance: + +- `data/DATASET_LICENSE.md` should describe usage rights, redistribution terms, attribution requirements, and anonymization or de-identification status; +- `data/data-provenance.md` should describe where each dataset came from, when it was obtained, how it was processed, and known limitations or biases. + ## Configuration Separate configuration from code. diff --git a/content/project-documentation/student/report-template.md b/content/project-documentation/student/report-template.md index 8b3ad40..d2a671d 100644 --- a/content/project-documentation/student/report-template.md +++ b/content/project-documentation/student/report-template.md @@ -41,27 +41,28 @@ Summarize how to run the project and where to find documentation in the reposito ``` -## Individual Contribution Reports +## Individual Contribution Statement -Each student must submit a short individual contribution report in addition to the team final report. +Each team must submit one signed team contribution statement in addition to the team final report. Recommended location: ```text -docs/individual-reports/.md +docs/contribution-statement.md ``` -The individual report should explain the student's own work, using concrete evidence rather than general claims. +The contribution statement should explain each student's work, using concrete evidence rather than general claims. It should include: -- main technical, design, evaluation, documentation, and presentation contributions; +- each team member's main technical, design, evaluation, documentation, and presentation contributions; - links or references to relevant pull requests, issues, commits, experiments, or report sections; -- decisions the student influenced and tradeoffs they handled; -- parts of the project they reviewed, tested, debugged, or helped integrate; -- any major blockers, handovers, or unfinished work relevant to their contribution. +- decisions each student influenced and tradeoffs they handled; +- parts of the project each student reviewed, tested, debugged, or helped integrate; +- any major blockers, handovers, or unfinished work relevant to the contribution distribution; +- signatures or explicit signed approval from all team members. -This is an individual report, not a shared team confirmation document. It should be written by the student whose contribution it describes. +This is a shared team confirmation document. It should be signed or explicitly approved by all team members. ## Writing Advice @@ -83,5 +84,6 @@ Appendices may include: - prompt templates; - data dictionaries; - extra evaluation details. +- contribution statement. Core arguments should remain in the 5-page report body. diff --git a/content/project-documentation/student/rubrics.md b/content/project-documentation/student/rubrics.md index f21d364..f3978f8 100644 --- a/content/project-documentation/student/rubrics.md +++ b/content/project-documentation/student/rubrics.md @@ -6,15 +6,15 @@ The teaching team may adjust the final grading details before the project starts ## Course Assessment -The table below mirrors the assessment structure in the course overview. The detailed rubrics in this document cover the repository-based project components and the midterm oral presentation. In-class tests, quizzes, and ethics certification are assessed separately. - -| Component | Weight | Project Documentation Mapping | -|---|---:|---| -| Project report and code, with final presentation with a live demo | 40% | Final submission | -| Initial submission: conception and reproducible base code | 10% | Technical design and reproducible repository skeleton | -| Midterm checkpoint: technical project design | 20% | Proof of concept technical checkpoint | -| Midterm oral presentation with live demo | 10% | Week 8 oral presentation and live demo | -| In-class tests and quizzes, including ethics certification | 20% | Assessed outside the team repository | +Course-grade weights have priority. The project-related components account for 80% of the course grade; the project-grade equivalents below normalize those components to 100% of the project grade. The detailed rubrics in this document cover the repository-based project components and the midterm oral presentation. In-class tests, quizzes, and ethics certification are assessed separately. + +| Component | Course Grade | Project Grade Equivalent | Project Documentation Mapping | +|---|---:|---:|---| +| Initial submission: conception and reproducible base code | 10% | 12.5% | Technical design and reproducible repository skeleton | +| Midterm checkpoint: technical project design | 20% | 25% | Proof of concept technical checkpoint | +| Midterm oral presentation with live demo | 10% | 12.5% | Week 8 oral presentation and live demo | +| Project report and code, with final presentation with a live demo | 40% | 50% | Final submission | +| In-class tests and quizzes, including ethics certification | 20% | Not part of project grade | Assessed outside the team repository | ## Milestone 1: Technical Design and Reproducible Repository diff --git a/content/project-documentation/student/week-10-checkpoint.md b/content/project-documentation/student/week-11-checkpoint.md similarity index 98% rename from content/project-documentation/student/week-10-checkpoint.md rename to content/project-documentation/student/week-11-checkpoint.md index c49c183..c989c73 100644 --- a/content/project-documentation/student/week-10-checkpoint.md +++ b/content/project-documentation/student/week-11-checkpoint.md @@ -1,4 +1,4 @@ -# Week 10 Checkpoint +# Week 11 Checkpoint Timing: November 23-27. diff --git a/templates/layout.html.j2 b/templates/layout.html.j2 index 7e6b4e4..efd857d 100644 --- a/templates/layout.html.j2 +++ b/templates/layout.html.j2 @@ -87,12 +87,15 @@ {% endif %}
+ {% if not no_pagination %}
Step 1 of {{ section_count }}
+ {% endif %}
{% for section in sections %} -
+

{{ section.title }}

{{ section.html | safe }}