gnusocial.rocks/soc/2020/proposal_rating_guidelines.txt

# 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.