Summer of Code
About GNU social
GNU social is the eldest free social networking platform for public and private communications used in federated social networks. It's
versatile, extensible and privacy focused. We've been modernizing the existing codebase, ensuring
inter-operationality as defined by the IndieWeb and we're developing a modern frontend. This makes GNU
social accessible: easy to install and use, and follows AnyBrowser and A11Y guidelines.
About Summer of Code
With respect to the time you will have to dedicate, as a student, GNU social's Summer of Code expects you to work an
average of 36.5h/week. You can organize that time as you please, but you must be sure to dedicate that
in your weekly work or to be overly productive.
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).
Mentors will have to ensure a minimum of 6h per week to help and guide the students.
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.
How to apply?
Close some open bugs. For that, learn the necessary to acquire a good insight on the codebase. That's how you will start to provide major valuable contributions.
We require some merge requests as that is the only way we have of knowing that you've actually tried to
understand the codebase and have the minimal necessary programming autonomy for the summer of code.
After you've done some code contributions, there's the proposal. That's how we make your application
"official". Please contact us on GS's Development
chat to get started with it.
Suggestion:
- Header:
- Name
- Email
- Other contact forms (IRC, XMPP)
- Timezone
- Project name
- *Proof of Competence link
- Summary
- Benefits
- Deliverables
- *State Of The Art
- *Relevant Research
- Plan
- Tentative Timeline
- Communication
- Qualification
- *References
* - if applicable
N.B.:
- Plan and Timeline may be together
- Deliverables may come up after timeline
- You're allowed to create subsections
and even sections
Understand that we need you to put some effort on the tentative timeline and relevant research. The point
being that if you are to work on a large component or in significant changes, you must show us that you
do understand and have gone through the planning work required to implement it properly.
Click here to understand how we'll rate your proposal.
For an example proposal, you can refer to GNU social v2
Network Services Improvements proposal (old format).
The tendency is that newer software will focus in the implementation of the ActivityPub Protocol (as it
is newer and considered to be simpler) instead of OStatus, given that, it is important for GNU social to
support it in order to stay updated and relevant in an even larger fediverse.
Proposed by Diogo Cordeiro and mentored by Daniel Supernault and Mikael
Nordfeldth.
Technical Report