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.