Should Django do Google Code-in?

Similar to Summer of Code, but for 13-17 year olds, there’s a Google Code-in project.

We can apply, having done Summer of Code.

Should we?

  1. Do we have mentoring capacity? This is a biggie. There’s no point signing up if we’re not going to be able to support applicants.
  2. Would the Forum here be the best place to handle mentorship?
  3. So, do you think you could give some time here. i.e. be present and active on this forum to help?

Then:

  • What tasks can we come up with?

One that I think is a great candidate is to go over the ecosystem, adding testing against supported versions, dropping older ones, and helping update any blockers. (Normally these aren’t hard™ — certainly with a mentor on hand. Often a PR updating travis configs is the first step…

But other ideas would be good.

If there’s a strong, positive response here I will apply. (I’ll notify django-dev and the DSF list about this post.) But I don’t want to sign us up without that.

Thanks all!

1 Like

I think I’ll be able to give a hand, but I still have finals on December 14-21 so I won’t be very active until then. For mentorship, I think this forum should be more user-friendly for the participants compared to the mailing list or IRC.

Tasks… I’ve been wondering for a long time about what kind of tasks Django can provide for GCI and still haven’t come up with many ideas. Maybe improving django-docker-box can be broken down into multiple tasks. Tackling an easy picking ticket may also count as one task. Documentation tasks are also acceptable on a reasonable amount. We can also probably add something like “Setting up a new Django project” as a warm-up task if desired.

I can give a hand too.

About the tasks, I think we should find how many (“easy” := solvable by a pre-university student) tickets can be found in the 5 CGI categories.

It’s a seven week program, so I don’t know how many tickets will be expected to be closed by each participant. If 3 “easy” tickets are considered per each (two weeks per ticket + 1 week JIC / round-up), then the amount of “easy” tickets / 3 would be the amount of participants that the project can handle.

Once the tickets have been selected, see how many people is willing to guide, then open the applications for as many students as mentors are willing to guide (1 mentor - 1 student). If mentors < “easy” tickets / 3, then the students will be able to choose from a wider pool of tickets.

Diggin’ deeper into the matter, I found some misinferred things from the GCI announcement in my proposal.

First, Mentors are task-oriented rather than student-oriented, they supervise tasks independently of which student does it.

Tasks are expected to be completed in 3 to 5 hours, then thinking in a ticket to be done in 2 weeks is not in line with that.

Kept thinking about it and 2 areas came to my mind which can provide a lot of those tasks: testing coverage and documentation translations.

Currently Django’s testing coverage is around 80% in the master branch, there is a lot of room for improvement there.

We may encourage the students to find which areas of the code are untested and then decide whether they need to be tested or a “#noqa” label should be appended, or we just create the tasks for them and then let them choose under the “First understand what is the code intention, where is to be called and which code expects its output, then recreate the path that is not being covered” advice.

Maybe we can provide both, because some areas can be hard to understand for them (i.e. models’ functions or the Selenium test case) while others would great if the dig in the code under a generic “Improve code coverage” task.

Documentation translation would also a very good impact - will ease the way to many people to Django - and can be easily achieved by non-native English students. Translating documentation makes the translator read thoroughly or exhaustively the documentation, and therefore gaining a deeper understanding of it while expanding the reach of the software to other people. It is highly likely that students from a non-English speaker country will understand English to a certain degree (otherwise I don’t think he or she would be able to participate), they can start from an automated translation, i.e. from Google Translate, and then polish it until is ““perfect”” under their native language. Each task could be a rst document in the documentation, and even get reviewed by another student besides the mentor - I’m unaware of how the Transiflex platform works.

I still can’t find a way to decide whether a code task is suitable for a pre-university student from 13 to 17 years. There is a lot of variance there, with 13 being at the beginning of high school and 17 at the end of it (there is a lot happening there in those years). I remember meeting a 15-years guy who at that time was able to code in Assembler, though he was troubled by his emptiness feeling, I think he could handle a Django ticket at that moment. I don’t think he was “the average student”, so maybe we shouldn’t focus on that, if someone wants to pick an “Easy picking” ticket because she or he feels capable, then let them go for it and support them - just make them available for choice.

1 Like

OK, thanks both.

So I was thinking we needed a bit more of a response to be able to go for this.
Maybe we could drum up interest but I think we’d be pushing up hill at this point.

For this year at least, I think we should say that folks (including us) should focus our efforts on making this new forum a success. If we can get it super active I feel like there’d be a place we could point student expecting that there’d be enough support.

(Plus there’s the issue of Tasks… much like GSoC ideas, that needs more thought… — This is not the main issue for me though: with enough folks, I’m sure we’d come up with things easy enough.)

Let’s leave it for this year.
Thanks again.