The Piccadilly Circus Games have now finished.
You are viewing an archive of the Piccadilly Circus Games Competition. Join our Discord for the latest information.
Rubrics
Index of Rubrics used for scoring award tasks. Rubrics score by criteria on a simple high-to-low point range of 3-1.
Explainer Video Rubric
Criteria | 3 | 2 | 1 |
---|---|---|---|
Detail | Video is detailed in explanation and description of thematic content and processes from the brief | Video is somewhat detailed but does not accurately describe or explain the brief | Video gives no detail or explanation from the original brief |
Originality | Content is original and enhances the brief | Content is original but just copies the brief | Content is just a copy of a pre existing video with our brief |
Delivery | Delivery of explanation or how to is clear, concise and accurate | Delivery of explanation or how to is clear but not particularly accurate | Delivery of explanation or how to is unclear and/or inaccurate |
Production | Video, audio and editing is of high quality | Video, audio and editing is of medium quality | Video, audio and editing is of low quality |
Blog Post Rubric
Criteria | 3 | 2 | 1 |
---|---|---|---|
Detail | The blog contains a very detailed writeup of the information present in the brief. This detail is clear to understand and correct through your explanations. There is no lack of information making the subject seem unclear | The blog is a somewhat detailed accurate representation of the brief but particular parts are unclear and hard to understand. Explanations are not thorough thus there isn’t complete understanding on the subject | The blog lacks any detail and actually makes it harder to understand the original information provided in the brief. No clear explanation of understanding is delivered on the subject supplied in the brief |
Creativity | In writing the blog you have used your imagination and creativity to explain the briefs in a way that is very effective and unique to you. This creativity is present all throughout the blog | In writing the blog you have tried to use your imagination and creativity to explain the briefs in a way that is very effective and unique to you but this is not explicitly clear to the reader | In writing the blog you have not used your imagination and creativity to explain the briefs and this is very obvious to the reader. The blog is almost a repetition of the brief with unnecessary added detail |
Correctness | The blog is written in absolutely correct standard English, with complete sentences, and completely error-free | The blog is written in generally correct standard English, with complete sentences, and is relatively error-free | The blog is not written in correct standard English, without complete sentences, and is riddled with errors |
Development | Each paragraph does support or expand the central idea of the blog. The idea of each paragraph is explained and illustrated through examples, details, and descriptions | Each paragraph somewhat supports or expands on the central idea of the blog. The idea of each paragraph is somewhat explained and illustrated through examples, details, and descriptions | Each paragraph lacks support or clarity on the central idea of the blog. The idea of each paragraph is not explained or illustrated through examples, details, and descriptions |
Infographic Rubric
Criteria | 3 | 2 | 1 |
---|---|---|---|
Detail | Infographic is detailed in explanation and description of subject matter from brief | Infographic is somewhat detailed but does not accurately describe or explain the brief | Infographic gives no detail or explanatory coverage of the original brief |
Creativity | In creating the infographic you have used your imagination and creativity to explain the brief in a way that is very effective and original | In creating the infographic you have tried to use your imagination and creativity to explain the briefs in a way that is very effective and unique to you but this is not explicitly clear to the reader | In creating the infographic you have not used your imagination and creativity to explain the briefs and this is very obvious to the reader. The infographic does not add much to the brief |
Clarity | The infographic clearly explains the topic and theme with a strong and coherent narrative flow | The infographic is generally clear but the narrative progression could be clearer. It has no errors | The infographic is disjointed and fails to clearly explain its theme and topic. It contains errors |
Visual impact | The infographic is concise, doesn’t cloud by displaying too much detail, focuses on the important content, good use of colour | The infographic is concise, but overly detailed, making it harder to understand | The infographic is cluttered, chooses colouring badly, is hard to read and doesn’t make sense |
Developer Tooling Rubric
Criteria | 3 | 2 | 1 |
---|---|---|---|
Project complete and open | Code implements sufficient features to provide a functional MVP. The code is open source and properly licensed. Licensing is permissive, how to contribute clear and code open making contribution easy. Further development path is clear. | Code is a viable MVP with a clear development path but does not implement all MVP features. Licensing is clear. | Implementation is incomplete and lacks a clear development path to provide an MVP. Licensing isn’t clear or source code is closed preventing community development to MVP. |
Code | Programming language and code dependencies utilise current versions. Code uses language frameworks, common conventions and design patterns. Reused code libraries are from sources with active maintainers and user communities. Error handling and consideration of fallbacks. Code is commented and project includes tests and CI showing a commitment to release and maintenance of quality software. | Programming language and code dependencies utilise current versions. Code is linted and programming language and code dependencies utilise current versions and releases. Errors handling is in place. | Code doesn’t make use of language conventions and is inflexible or hard to maintain. Reused libraries lack active maintenance or user community. Project demonstrates significant reuse of existing code (e.g. a project fork) without code additions that represent a significant contribution to the code or development effort. |
UI | CLI user prompts and -help is clear and give intuitive guidance on usage to the first-time user. If a GUI is provided, design style is concise without unnecessary verbosity. |
UI is complete and intuitive to use. | UI is incomplete, prompts non-intuitive and hard to follow. |
Community value | Project adds new feature coverage to existing Autonity tooling or provides new Autonity tooling. Project can be reused by other tooling projects. Developer tooling for building with Autonity is significantly enhanced. | Project extends or builds on the feature coverage provided by existing Autonity or EVM ecosystem tooling. Project contributes to improving the tooling available to the Autonity user community. | Project adds no or little new functionality to that provided by existing Autonity tooling or a reused EVM ecosystem tool codebase. |
Use case Rubric
Criteria | 3 | 2 | 1 |
---|---|---|---|
Protocol | Protocol design is crypto-economically secure, tradeoffs in design properties have been considered, and protocol semantics and logic are clear. | Protocol design is considered with trade-offs and rationale for design choices clear. | Protocol rationale and semantics are not clear. |
Innovation | Project is a new concept or an innovative improvement of existing work. | Project has originality or builds on existing work. | Project reuses an existing design without improvement. Project adds no or little relevant functionality to the reused codebase. |
Decentralisation | Design is decentralised and has no single points of failure or trust impacting resilience. Governance / decision making is open and shared with the community. | Design exhibits centralisation points but protocol design has a rationale for this and a clear path to full decentralisation | Design is centralised and monolithic. A single point of failure risks outage. |
UI | CLI design style is concise without unnecessary verbosity. User prompts and -help is clear and give intuitive guidance on usage to the first-time user. If a Front End dApp GUI is provided it may have decentralised hosting. Front end design has considered design style (font, sizing for common screen sizes, brand colouring. The user journey is intuitive. |
UI is complete and intuitive to use. The user journey is clear, giving a clean UX. | UI is incomplete, prompts non-intuitive and hard to follow. |
awesome-autonity Rubric
Criteria | 1 | ||
---|---|---|---|
Valid resource entry | The submitted resource entry is relevant to the Autonity community and vision - see https://autonity.org/. The resource entry is a new resource that has not already been listed in the awesome-autonity GitHub README. The submission is made in accordance to the repo’s Contribution Guidelines. |