82 lines
4.9 KiB
Plaintext
82 lines
4.9 KiB
Plaintext
|
# Proposal Rating Guidelines
|
||
|
|
## Scores
|
||
|
|
- 31337: Outstanding. Ex.: Went above and beyond (user stories split into small tasks, small tasks estimated,
|
||
|
|
defined MVP, planned any additional work, defined time off or limited time, well defined in case of emergency
|
||
|
|
(NOT "I will complete tasks earlier so I will have more time"))
|
||
|
|
- 1337: Very Good. Ex.: Included more than requirements (added mocks, diagrams, etc).
|
||
|
|
- 42: Competent. Ex.: Completed the minimum requirements (proposal's required questions).
|
||
|
|
- 0: Failed. Ex.: Either Below Average or Poor. Ex: Missed a few requirements (missed 1 or 2 required questions) or Didn't complete
|
||
|
|
requirements (incomplete, didn't follow template, etc).
|
||
|
|
|
||
|
|
## Key Aspects
|
||
|
|
- Idea - Does the idea solve real problems? Was the audience defined? Is it realistic, does it bring potential security
|
||
|
|
issues? As a potential user, would you use the proposed? Can problems be easier solved by existing technologies?
|
||
|
|
- Understood Project? - Did the student research other projects doing similar things? Did the student show the full
|
||
|
|
scope of the project (backend, frontend, defined APIs, database, structure models, ML models, mockups, user journey,
|
||
|
|
user stories, etc.)?
|
||
|
|
- Project Planning - Did the student understand the whole complexity of the project, show smaller tasks and estimated?
|
||
|
|
Does the student have a version when things go wrong, as planned, and better than expected? Did the student balance
|
||
|
|
whole parts of the project (frontend and backend developing simultaneously) to have a better chance to achieve working
|
||
|
|
functionality?
|
||
|
|
- Engagement - Engaged on IRC, engaged on NotABug, listened to proposal feedback and updated their proposal,
|
||
|
|
helped others, closed issues, etc.
|
||
|
|
|
||
|
|
## Criteria
|
||
|
|
Once proposals have been finalised, student proposals will be graded based on the following criteria:
|
||
|
|
|
||
|
|
### Project
|
||
|
|
- Does it solve the problem we need solving? Does applicant clearly identify the problem?
|
||
|
|
- Does it offer a sensible solution?
|
||
|
|
- Does it offer supporting evidence for technologies chosen, e.g. bootstrap. Sometimes a compare/contrast of different
|
||
|
|
technologies considered can be helpful.
|
||
|
|
- Nice bonus features in addition to the main project = good, ONLY unrelated 'bonus' features = bad.
|
||
|
|
|
||
|
|
### Plan
|
||
|
|
- Does the proposal have a realistic timeline?
|
||
|
|
- Are deliverables correct and timely?
|
||
|
|
- Does the student have enough time in the week to carry their plan?
|
||
|
|
- Bonus for "what if things go wrong planning", e.g. bonus features towards the end of the plan that can be removed
|
||
|
|
if/when the bugs strike.
|
||
|
|
|
||
|
|
### Team working skills
|
||
|
|
- Can the student carry out tasks on their own over a three month period?
|
||
|
|
- Clear evidence of communication skills
|
||
|
|
- Lower points for gross over-communication ("what should I name this variable?"), better if they quietly and
|
||
|
|
competently get the job done but interact at appropriate times, e.g. GNU social bugs, sensible progress reports.
|
||
|
|
- Is the student capable of following existing guidelines and instructions where appropriate?
|
||
|
|
|
||
|
|
## Extras
|
||
|
|
|
||
|
|
### Experience
|
||
|
|
The experience criterion isn't specifically part of the grading rubric, but it's important for us to see some of the
|
||
|
|
following in the application:
|
||
|
|
|
||
|
|
- Does the student have reasonable evidence they've competently done something relevant to this before? e.g.: one or more of
|
||
|
|
- a {NotABug, CodeBerg, GitGud, GitLab, GitHub,...} profile,
|
||
|
|
- merge requests on GNU social's repo,
|
||
|
|
- published software,
|
||
|
|
- code from a higher education institution assignment?
|
||
|
|
- Note: we don't require MRs to GNU social's repository. It's handy as a source of evidence, but any of the others
|
||
|
|
should do just fine.
|
||
|
|
- Absolutely no work available - not even a published app, some work experience, or code from a class assignment, is a
|
||
|
|
red flag.
|
||
|
|
|
||
|
|
### How the ranking process works
|
||
|
|
All students with a finalised proposal will have their proposals reviewed by one or more mentors in the organisation,
|
||
|
|
and ranked out of 4 based on the criteria above. This score will also be averaged to provide a mean result. These
|
||
|
|
scores are not the final acceptance criteria - so a 1337 won't automatically win over an 42 - but they do help provide
|
||
|
|
general guidelines for the mentors who are choosing from a large body of qualified students.
|
||
|
|
|
||
|
|
### Accepted students
|
||
|
|
Students will be notified of their acceptance by Google when all accepted students are announced, and will _not_ be
|
||
|
|
notified of their internal grades. Please note that we usually have more highly qualified applicants than slots
|
||
|
|
available for the organisation, so sometimes proposals that are genuinely very good have to be rejected. We genuinely
|
||
|
|
wish we could take you all!
|
||
|
|
|
||
|
|
Students who successfully finish the summer of code and are interested in a "GNU social Summer of Code transcript" may
|
||
|
|
request one and that will come with a score and include an adapted proposal assessing.
|
||
|
|
|
||
|
|
|
||
|
|
---
|
||
|
|
These guidelines were adapted from [InterMine](http://intermine.org/internships/guidance/grading-criteria-2019/) and AnitaB.
|