Google Summer of Code 2019


#1

Hi all,

Since we didn’t apply last year, I’d like to point out that applications open on 15th January and close on 6th February so there’s about a month to prepare.

Do we have someone to lead NixOS organization to apply?

Timeline: https://developers.google.com/open-source/gsoc/timeline
Ideas: https://github.com/nix-community/google-summer-of-code


#2

The absolutely most important thing for the application is to have a good clear ideas page. If there isn’t one then the application will be rejected.

Ideas are adding by making pull requests to a github repo.

For example, here is the one for Haskell: https://summer.haskell.org/

I am willing to help with the NixOS application but dont’t think that I am qualified enough to take the lead completely.


#3

Hey @mpickering

agreed - do you have some concrete suggestions at https://github.com/nix-community/google-summer-of-code besides getting it up to date?

Any feedback like that helps a lot, thank you.


#4

Yes, a github page is not sufficient.

Here are the guidelines from google.

Notice again how they say the most important thing is the ideas page. It needs to look polished with realistic projects and signed-up mentors, preferably two per project.

The ideas page is the most important part of the organization application.

On the suggestions for the ideas page it is reiterated.

Note that the quality of the project descriptions on an organization’s “Ideas list” is the main criterion for the organization’s admittance into GSoC. It is worth spending some extra effort to ensure that the projects you propose are worthy of the GSoC banner.

So there ideally would be a subdomain on the main website which was dedicated to the whole program like gsoc.nixos.org which was populated with the ideas and details of the program.

Examples:


Now looking at last year’s idea list as someone is a regular user and contributor some of the ideas are definitely too vague.

  1. Descriptions too short, lacking detail. A good description is five-six sentences
  2. It is not clear how to contact the mentors on a specific project. Emails!
  3. Projects are lacking a difficulty assignment and in general seem quite hard.
  4. Only one mentor listed per project.
  5. Two of the projects is suggesting documentation which is not permitted under GSoC rules.
  6. A lot of the projects seem quite greenfield. It would be good to have some more concrete ideas which have a clear implementation strategy for less experienced developers.
  7. There are projects listed without mentors. Also a big no-no, only propose projects where people would be willing to mentor.
  8. Projects like “Performance improvements” are just nebulous and can be very frustrating as it’s not
    obvious how to make any progress – avoid.

My favourite general ideas from the list are:

  1. “Deterministic Builds”, seems like a project that could be well-scoped and well-defined but is still quite vague.
  2. “Graphical Installer” - Seems well-scoped
  3. “hnix” - High-impact and can also be well-scoped but will need an update.
  4. “Language Server” - this could be quite a good project based on hnix but it needs to be well-scoped.
  5. “Terraform providers in NixOps” - Quite well defined and doesn’t seem like it would have a terrible large scope.

I propose that we follow the model used by Haskell.org. A github repo holds the source for a statically generated site so users can make PRs adding projects which are then reviewed for quality before being merged and deployed. We should aim for 6-8 high-quality proposals with the aim for securing 3 student slots.



#5

So the very start seems to be to pick a static generator and write down the content for GSOC related to NixOS.

As someone who was part of GSOC for three years I agree. The ideas need to be reasonably scoped to be able to define success or failure and ideally be smallish. Some of the projects require too much information and relation with Nix ecosystem that it would be hard to catch-up in just a few months and get something done.

That seems reasonable to me. I’d be more than happy if someone wants to take the role of coordinator and offer help with such tasks from my side.

hnix and a few others seems quite haskell related, would it make sense to assign those ideas per language or per project?


#6

If we wanted to apply, we’d need to do so until 2019-02-06.


#7

Do you want to take lead? :slight_smile:

I’m too bust this year as well it seems to take a strong lead here, hopefully someone else can take this forward.

I’ve love to be a mentor though, if we manage to get an application through.


#8

I don’t want to take on an administrative role right now either.

For reference, here are the relevant snippets from the guide:

Organization Administrator

Org admins are the “cat herders” for GSoC open source projects. These people submit the organization’s application to participate in the program to Google, ensure that mentors fill out evaluations in a timely fashion, and generally organize their project’s participation in GSoC. The org admin acts as Google’s go-to person if any issues arise. There are also some trivial administrative tasks in GSoC’s online system that can only be completed by organization administrators. Some org admins also mentor students during GSoC, and that’s perfectly fine; it is just highly recommended that folks know they have enough time to execute both roles simultaneously.

Org admins are the final authority about matters such as which student projects will be accepted and who will mentor whom. On the social side, if a mentor and student have difficulties communicating or making progress, an org admin will often step in as a neutral party to help the two work together more effectively. Org admins also help track down disappearing participants, whether mentors or students.

Mentor

Mentors are people from the community who volunteer to work with a student. Mentors provide guidance such as pointers to useful documentation, code reviews, etc. In addition to providing students with feedback and pointers, a mentor acts as an ambassador to help student contributors integrate into their project’s community. Some organizations choose to assign more than one mentor to each of their students. Many members of the community provide guidance to their project’s GSoC students without mentoring in an “official” capacity, much as they would answer anyone’s questions on the project’s mailing list or IRC channel.