The working agreements for this fictional SlopU studio: individual work, visible assistance, accessible interfaces and honest handovers.
Policies and support#
Scope#
These are the designed policies of this fictional SlopU course. They are not ANU policy, and this website does not operate a real enrolment or submission service.
Submission and dates#
Each brief owns its release date, due date, required toolkit and marking weights. Due times are 23:59 in Canberra. In an offering of this course, the submission record consists of the deployed URL, repository URL and submitted commit/tag, supplied to the convenor at the studio handover. This prototype provides the briefs and materials; it does not collect uploads.
Keep the submitted version available for review. A short recording or screenshot can document a failure that is difficult to reproduce, but does not replace the working frontend.
Extensions and feedback#
Bring a timing problem to the convenor before the deadline and agree a revised date in writing. An extension changes the date, not the work required. Unarranged late work is not assessed until the convenor has reviewed the circumstances. These are course arrangements rather than an automated penalty scheme.
The next studio review offers formative feedback while the project is still changeable. Assessment feedback follows the published criteria and identifies one strength, one consequential failure and one next development step. Ask for a criterion-based review if the feedback and the observed behaviour disagree.
Individual work and assistance#
Projects are individual. Discuss architecture, review one another’s interfaces and use documentation. Attribute copied or adapted code and assets. Record agent assistance in your repository: what you asked for, what you changed and how you verified it. You must be able to explain every submitted boundary; an assistant’s assertion that something works is not evidence.
Do not submit a peer’s project or invented testing results. A declared limitation is more useful than a success claim the next developer cannot reproduce.
Data and simulated services#
Use invented accounts, patients, messages and article content. Authentication tokens are inert fixture values. Consultation, medicine, logistics and payment flows are simulations. Never enter real patient details or payment information. No clinical judgement or backend implementation is assessed.
A hidden button is not an authorisation boundary. Explain how a real server would enforce the permission, and make the local simulation reject the forbidden action as well as hiding its control.
Access and support#
Use semantic controls, visible focus, labelled inputs and readable error messages. Check keyboard use and both desktop and phone layouts. Do not communicate state through colour alone. Offer a textual explanation alongside diagrams and charts.
Bring access needs to the convenor so the form of participation can change while the learning outcome remains clear. For technical help, bring reproduction steps, expected and actual behaviour, and the smallest relevant code excerpt to the weekly studio.