4 Carnegie Unit
+ 18 Austria, Italy, and Spain ECTS
+ 16 Finland, The Netherlands, Portugal, and Russia ECTS
+ 15 Germany, Belgium, Romania, and Hungary ECTS
diff --git a/soc/2021/proposal_rating_guidelines.txt b/soc/2021/proposal_rating_guidelines.txt
new file mode 100644
index 0000000..ea0a0f4
--- /dev/null
+++ b/soc/2021/proposal_rating_guidelines.txt
@@ -0,0 +1,81 @@
+# 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.
diff --git a/soc/index.html b/soc/index.html
index 86d4b2d..880fed9 100644
--- a/soc/index.html
+++ b/soc/index.html
@@ -47,7 +47,7 @@
We suggest you to do a four-day work week with 6h of work/day + 3h to document, review/test and report the progress you've done (you usually won't need that much for this and we won't complain as long as you're doing well/being highly productive). As breaks are important, we recommend a 1h lunch break, 15min break after 4h of continuous work and a further 15mins break after 6h of work. These breaks won't be considered as part of your work time.
Note that 6h*4 = 24h, if you only do the 24h/week, you'll have to prove your worth. Otherwise, we might require that you either do a 5-day week or that you scale it up to 7.5h in your 4-day week.
In general, you will always have to work at least 120h/month, ideally 146h/month (or the productively equivalent). We do not accept that you transfer expected work time from a month to another. Nonetheless, an under-performing week will make us request more hours from you in the week after (up to the limit of 40h).
-
Click here to better understand how we distribute the load. Also note that every summer of code ends with a final tech report, here's an example of a frontend rework.
+
Click here to better understand how we distribute the load. Also note that every summer of code ends with a final tech report, here's an example of a frontend rework.