System Contributions and Curriculum Retrospective
This is a review and reflection checkpoint, not a new lesson or assignment. Use already completed work; do not start new CodeRunner submissions or add project requirements.
Evidence and reflection checklist
- Explain How Prior CSP Community or Nonprofit Experience Led to an OCS System Contribution
- Review Two Mentor Reviews and Community N@tM Feedback with Project, Demo, and How-It-Is-Made Evidence
- Identify Individual Design, Implementation, Integration, and Testing Evidence
- Map Demonstrated Skills to CS112 and CS113 Topics without Claiming Uncompleted Layers
- Document System Foundations, Maintenance Handoff, and Next Iteration Ideas for CSA2
- Propose One Future Teaching Topic Individually or with Up to Two Teammates and Coordinate Classroom Contributions
Identify what you can explain independently, point to an existing test or demonstration, and record a misconception or next-step idea. A team demonstration is not evidence that every member implemented each layer. Evaluate only the advanced layers you actually completed.
Revisit earlier work
- Sprint 3 capstone objectives and evaluation evidence
- OCS Assignments System capstone
- Gamification and onboarding capstone
- Admin and security capstone
Alternate examples remain in the CS112, CS113, CSA2, and Java reference collections. Browsing them does not create an assignment.
From a project to a lasting system contribution
Use existing work to explain how your prior-year CSP community or nonprofit project experience prepared you to contribute to OCS. Identify what is now integrated into the shared system, what remains a prototype or proposal, and what future students can maintain or extend. A public demo does not by itself establish that a feature is integrated.
Point to existing interface contracts, integration tests, documentation, and known limitations. Explain how these make your contribution a foundation for future cohorts rather than a disposable sprint project. Record handoff gaps and next-step ideas; this retrospective does not require new implementation.
Mentor and community review cycle
Review the team’s two mentor reviews and community N@tM presentation completed before week 13. For each, identify the project discussed, the demonstrated behavior, and the explanation of how it is made. Link retained feedback and distinguish revisions already made from ideas for later iterations.
Explain your own role using existing design, code, integration, and test evidence. Group attendance, activity counts, and a teammate’s implementation are not substitutes for individual explanation. This project/demo/technical-discussion cycle continues throughout the year.
Curriculum connections and the CSA2 handoff
| Connection | Reflection using existing evidence |
|---|---|
| CSA2 progression | Which Java/Spring models, persistence, APIs, design plans, team roles, and review practices will you carry into the next trimester? |
| CS112 outline | Which OOP, collection, persistence, or Web-interface concepts can you explain and demonstrate? Identify the relevant subtopic and your individual evidence; database persistence alone does not demonstrate file I/O. |
| CS113 outline | What design-before-coding and testing evidence exists? Claim specific data structures, algorithms, or efficiency analysis only where your work supports them; feature names such as AI or analytics do not establish mastery. |
| Java Reference | Which existing lessons helped you understand your implementation, and which concepts need strengthening in CSA2? Browsing a reference is not a new assignment. |
Summarize what you can demonstrate independently, one misconception corrected through review, and one next-iteration idea. These connections support curriculum review, not automatic college credit. Advanced CS113 layers remain differentiated opportunities; do not claim work you have not completed.
Choose a future topic and classroom contribution
Use the upcoming CSA course plan, CS112 outline, CS113 outline, and Java Reference to select one future learning topic you want to help teach. Work individually or with up to two other teammates: two to three students total.
Record a short proposal in your existing review ticket:
- Topic and timing: Name the topic, link its existing lesson or outline section, and identify its planned teaching week when available. Choose upcoming instruction, not new work for an AP-review or presentation week.
- Starting point: Explain which current skills or project experience prepare you, and what you still need to learn. Selecting a topic is not claiming mastery.
- Teaching contribution: Propose a focused explanation, demonstration, guided activity, or CodeRunner exercise that helps classmates understand and practice the concept. Build on existing material rather than duplicate it.
- System or classroom value: Explain how the topic connects to your OCS feature or improves a reusable classroom learning resource.
- Individual roles: List the one to three participants and each person’s proposed teaching or development contribution.
- Feedback and coordination: Bring the proposal to teacher review to coordinate topic coverage, preparation, and delivery in a later instructional week.
Week 12 is for choosing and proposing the contribution, not completing a new lesson, CodeRunner submission, or system implementation. Carry the reviewed proposal into CSA2 preparation; later teaching should include feedback and evidence of each participant’s contribution.