Charter
We function as a professional research software engineering team. There is no “submit” button here. Instead, we use version control to manage the handoff of code and documentation. You must understand this workflow to do it right.
The main branch of your repository represents the production state.
Never break the main branch.
Code in main must always work, be tested, and be ready for deployment.
Never push directly to main.
(In fact, I disabled everyone’s ability to push directly to their main branch.)
During your daily work, you and your teammates develop features in isolated branches and merge them into a shared development branch, typically named dev.
This dev branch serves as your integration sandbox, where the messy work of combining different features takes place.
Stop adding new features when your team meets Charter Sprint objectives.
Create a release branch named charter from dev as soon as features stop.
This action isolates your deliverable from ongoing development.
The code and documentation are frozen, so you can finish the report without new commits breaking the build.
Once your charter branch is ready, you open a Pull Request (PR) on GitHub.
You must configure this PR to merge your charter branch into main.
Mark your Pull Request as a Draft when you open it.
A Draft PR signals to the instructor that you are still finalizing the documentation or formatting the report.
It lets you see file differences and ensure your Markdown renders correctly before you officially request a review.
The final step is the handoff.
When your report is committed, and your code is clean, you change the PR status from “Draft” to “Ready for Review.”
When you update PR status, you must request a review from everyone else in your team and the @dri-26s team.
It is the digital equivalent of placing a signed report on my desk.
I will review your submission directly within the Pull Request, adding line-by-line comments on your code and your writing.
If changes are required, you will push them to the charter branch, and the PR will be automatically updated.
Repeat this process until I approve and merge the work.
Sprint Report Template
You will create a file named reports/sprint-01.md in your repository.
Copy the following Markdown content into that file and fill in the bracketed sections.
Delete these instructions before submission.
# Sprint 01: Charter Report
**Team:** [Insert Team Name]
<br>
**Date:** [Insert Date]
<br>
**Authors:** [Insert Name(s) of Person Writing the Report]
## Scientific Status
_[This section replaces the traditional "Introduction." Do not assume I remember your specific project variation. Briefly re-contextualize the biological problem you are solving. Explain why this specific project matters. State the specific gap in knowledge or tooling you aim to fill by the end of the semester. Keep this high-level and accessible to an external scientist.]_
## Sprint Outcomes
_[This is the most critical section. You must explicitly state whether the goals of the Charter Sprint were met. Do not be vague. Culminate this section in a single, decisive sentence summarizing the status of your infrastructure and initial data acquisition.]_
### Definition of Done
_[Evidence is required here. If it is not linked, it does not exist. Include any visualization of your starting data here. Use standard Markdown image syntax: ``.]_
## Blockers and Friction
_[Distinguish between technical failures and scientific hurdles. If you spent three days fighting a dependency conflict in Pixi, document it here with the specific error message and how you resolved it. If you could not find a suitable dataset, explain the criteria you used to eventually select one. This section proves you are solving problems, not just following instructions.]_
## Planning
_[Bridge this work to the next sprint (Prototype). Define the specific technical goals for the next sprint. For example, "Now that the environment is set, we will write the Python script to batch-process the calculations" or "We will train the baseline model on the dataset."]_Rubric
The charter sprint report is worth 10 points distributed as follows.
| Section | Points | What earns full marks | What does not |
|---|---|---|---|
| Scientific Status | 1 | The biological problem is stated in your own words with enough context that a scientist outside your project could understand what you are doing and why. The specific gap your project addresses is clearly identified. You demonstrate that you have read and understood the relevant literature, not just restated the project specification. | A copy-paste or close paraphrase of the project specification. Missing or superficial explanation of why the target matters. No evidence of independent reading or understanding beyond what was handed to you. |
| Sprint Reporting | 2 | Honest, specific assessment of what was accomplished. The status sentence is precise and falsifiable. If goals were partially met or missed entirely, this is stated directly with an explanation of why. | Vague claims like “we made progress on the setup.” A status sentence that could apply to any team on any project. Overstating what was accomplished relative to the evidence in the repository. |
| Sprint Completion | 2 | The charter sprint objectives from your project specification are met. The “Definition of Done” section contains permalinks to the actual files, configurations, or scripts that prove the work was completed. If you acquired or generated starting data, a figure or summary is embedded directly in the report. | Objectives are partially met with no explanation of what remains or why. Missing or broken links. No embedded evidence. Objectives are unmet. |
| Blockers and Friction | 2 | At least one genuine technical or scientific problem is documented with specificity: what went wrong, what you tried, and how it was resolved or what your plan is if it remains open. Error messages or unexpected outputs are shown in code blocks. The distinction between technical failures and scientific uncertainties is clear. | A single sentence like “we had some issues with the environment.” No error messages or evidence. Problems described so generically that they could have been written without doing the work. This section left blank or marked as “N/A.” |
| Planning | 2 | The goals for the next sprint are specific, technical, and follow logically from the current sprint’s outcomes. You identify at least one dependency or risk. The plan reflects awareness of what your project specification asks for next. | A generic to-do list with no connection to your actual progress. Goals that are either trivially easy or impossibly ambitious with no justification. No mention of risks or contingencies. |
| Writing and Professionalism | 1 | Professional, concise scientific English. Markdown is well-formatted with proper headers, code blocks, and image syntax. The report could be handed to the project sponsor without embarrassment. Commit messages in the charter branch are descriptive and follow a consistent convention. | Sloppy formatting, broken Markdown rendering, grammatical errors that impede comprehension, or an unprofessional tone. Commit messages like “update” or “fix stuff.” |
Pull Request
Use the Pull Request ‘Body’ as your cover letter to summarize what to review. It helps the reviewer orient themselves before they dive into the code. Always fill out this section.