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


Past successes

In 2020

V3 Frontend

Modular and meaningful Web UX for GNU social v3

Proposed by Eliseu Amaro and mentored by Joshua Judson Rosen, Phablulo Joel, Daniel Supernault and Diogo Cordeiro.

Technical Report

V3 Backend

Initial implementation of GNU social v3's backend.

Proposed by Hugo Sales and mentored by Diogo Cordeiro and Alexei Sorokin.

Technical Report

In 2019

Improvements on GNU social's network systems

Private Messaging, further development on ActivityPub, improved Remote Actions.

Proposed by Bruno Casteleiro and mentored by Diogo Cordeiro.

Technical Report

Optimizations on Load Balance System and Storage Usage

Image System, Embed Plugin, Queue System, Caching System.

Proposed by Miguel Dantas and mentored by Diogo Cordeiro.

Technical Report

In 2018

GS ActivityPub Plugin

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