diff --git a/soc/academics.html b/soc/2020/academics.html similarity index 98% rename from soc/academics.html rename to soc/2020/academics.html index 61b7e69..ba70031 100644 --- a/soc/academics.html +++ b/soc/2020/academics.html @@ -2,7 +2,7 @@ - Assessment | GNU social SoC + Assessment | GNU social Summer of Code 2020 @@ -14,13 +14,13 @@ -

GNU social Summer of Code

+

GNU social Summer of Code 2020

Organized by Diogo Cordeiro

Mentors: Diogo Cordeiro, Alexei Sorokin, Daniel Supernault, Joshua Judson Rosen and Phablulo Joel

diff --git a/soc/2020/index.html b/soc/2020/index.html index 611b2c1..b1cd06d 100644 --- a/soc/2020/index.html +++ b/soc/2020/index.html @@ -29,6 +29,7 @@
  • How was it?
  • Ideas of 2020
  • Programme 2020
    • +
  • Academics
  • V3 Frontend
  • V3 Backend
    • diff --git a/soc/proposal_rating_guidelines.txt b/soc/2020/proposal_rating_guidelines.txt similarity index 100% rename from soc/proposal_rating_guidelines.txt rename to soc/2020/proposal_rating_guidelines.txt diff --git a/soc/2021/academics.html b/soc/2021/academics.html new file mode 100644 index 0000000..1a6198e --- /dev/null +++ b/soc/2021/academics.html @@ -0,0 +1,220 @@ + + + + + Assessment | GNU social Summer of Code 2021 + + + + + + + +
    +

    Grading System employed

    +

    Effective Grading

    +

    Either pass or fail.

    +

    Qualitative Grading

    + + + + + + + + + + + + + + + + + + + + + + + + + +
    GradeDefinition
    31337Outstanding
    1337Very Good
    42Competent
    0Failed
    +

    Method

    +

    Graded every month, the ceiled average is the final.

    +

    No Quantitative Grading system will be used.

    +

    The contributions will be evaluated according to the following directives:

    +
    +

    Autonomy with which the work was done

    +
    + +
    +

    Objectives satisfaction

    +
    + +
    +

    Intrinsic difficulty level of their work

    +
    + +

    Grade formula per month

    +
    +                                Autonomy level
+Satisfaction of objectives |    Low     Competent       Very Good       Outstanding
+                -----------+-------------------------------------------------------
+                Low        |    0       0               0               0
+                Competent  |    42      42              42              1337
+                Very Good  |    42      1337            1337            31337
+                Outstanding|    42      1337            1337            31337
+
+                        Grade from matrix above
+Difficulty level   |    0       42              1337    31337
+        -----------+-----------------------------------------
+        Low        |    0       0               42      1337
+        Competent  |    0       42              1337    1337
+        Very Good  |    0      1337             1337    1337
+        Outstanding|    0      1337             1337    31337
+
    +
    +

    Modules

    +

    N.B.: The following are the minimum averages in GNU social's Summer of Code, we will come up with a custom + "transcript" for any interested student.

    +

    Web Technologies

    +

    Amount of time allocated to each module unit

    + + + + + + + + + + + + + + + + + + + + + + + + + +
    DesignationTime (hours)
    Autonomous study80
    Mentorship20
    Project work46
    Total146
    +

    Assessment Components

    + + + + + + + + + + + + + + + + + +
    DesignationWeight (%)
    Proposal80
    Proof of Competence20
    +

    Proposed Credits

    +

    1 Carnegie Unit
    + 5 ECTS

    +

    Proposal Rating Guidelines

    +

    +

    Internship | Training

    +

    Amount of time allocated to each module unit

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    DesignationTime (hours)
    Internship276.5
    Autonomous Study93.5
    Final Report24
    Mentorship44
    Total438
    +

    Assessment Components

    + + + + + + + + + + + + + +
    DesignationWeight (%)
    Practical or project work100
    +

    Proposed Credits

    +

    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/index.php b/soc/2021/index.php index e2f984f..5e30ee0 100644 --- a/soc/2021/index.php +++ b/soc/2021/index.php @@ -28,6 +28,7 @@
  • Ideas
  • Apply
  • Study Resources
    • +
  • Academics
    • 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.