[Scummvm-devel] GSoC in 2018?

Wed Jan 17 21:22:22 CET 2018

Hi all,

Here are some answers to some of the points raised:

Transparency:

As I understand it this is the same point that was already raised last year asking for more transparent communication. Last year, to answer this request, we decided to insist on the project-related communication between the student and mentors on IRC to be in the #scummvm channel so that it is visible to everybody. The goal was also to foster communication with the rest of the community and not just the mentors. While I feel this succeeded in part, I also think we should continue for this to happen. I know that last year some of the communication for the Supernova project was still done in a separate channel, and most of this could (and should) have happened in #scummvm.

Otherwise as already stated by Eugene we do require the student to post on his blog at least one ce a week, and we also ask the students to push often their commits to their public GitHub forks (or to the master repository once their work as been merged).

One major document that was not public however is the students application (although some students did make theirs public voluntarily during the application period). Assuming this is allowed (I don't have all the GSoC rules in mind) we could make the accepted applications public. But maybe what would be a better idea would be to ask the accepted students to post their goal, detailed schedule and milestones on their blog before the start of the coding period but after he had the time to review and improve those with his mentors during the community bounding period.

Tracking progress:

As mentioned by Eugene this is done through the blog, commits to the students fork and communication between mentors and students. There is not a formalised process in place, but during the 2016 GSoC Blorente used Trello to track his tasks and progress on the MacVenture project. I don't think we need to make this a requirement (although I would leave this decision to the mentors for each project), but we can encourage students to do this.

Tasks:

I would like to remind those not familiar with GSoC that out task page is for guidance to give ideas to students, but they are welcome to come up with their own tasks. For example we had a student who proposed working on unicode support two years ago as she was interested in providing a Chinese translation. That task was not one we proposed but we liked it, even though in the end the project was not accepted. In the end we choose between the projects that the students have submitted (and they want to work on) and we do not impose projects to students.

Also the student can work on a task with others, but I do believe that this needs to be well managed to avoid duplicated or useless work because the changes are incompatible with changes somebody else did at the same time. So I have no objections with having a AGS task, but I think that if we want to consider it we should discuss it with the developers already working on this and maybe see if they would be open in co-mentoring the task.

For the rest I will direct you to the reply already given by Eugene and Arnaud.

I think there is room for improvement in the way we work and Bastien gave some interesting ideas, some of which could maybe be experimented this year if we get accepted as an organisation. I am not sure asking for a pull request every two or three days is very practical though. Usually the task are connected and the work will all be done in the same branch. Also for a new engine we usually need more than just a skeleton before the first merge. We decided a few years back to merge the work from students sooner, but isn't the first week too soon? Or are you suggesting that the pull request should be accepted but closed without merging, and basically used as a review system?

Also I do have some concerns with the result of GSoC projects, not so much about the quality of the code (the mentors are there during GSoC to ensure the quality is good enough, and we can fail students during one of the evaluation phase if that is not the case), but about what happens to the code after GSoC. Usually at the end of the GSoC period the result from the GSoC is not quite ready for public consumption and needs to be polished (and sometimes completed first). Inviting the student to the team does not seem to solve this issue. I had an interesting discussion with other org during the mentor summit about this, and student disappearing, or at least reducing a lot their involvement, after GSoC is a common issue, and we have to understand that the students are starting a new semester, or are starting work, and are often very busy. I am not sure what we can do to push the code beyond the last hurdle and get it ready for release though. For other ors this burden seems to fall to team members. When we accept a task should we make sure we have somebody in the team (preferably one of the mentor) who is interested and committed on continuing to work on the project after the end of GSoC?

And to conclude I would like to indicate we now have pages on the wiki to track project ideas:
http://wiki.scummvm.org/index.php/Summer_of_Code/GSoC_Ideas_2018 <http://wiki.scummvm.org/index.php/Summer_of_Code/GSoC_Ideas_2018>

Thierry

> On 17 Jan 2018, at 18:08, Eugene Sandulenko <sev.mail at gmail.com> wrote:
> 
> OKAY. I'll do it.
> 
> On 17 January 2018 at 18:58, Colin Snover <scummvm-devel at zetafleet.com <mailto:scummvm-devel at zetafleet.com>> wrote:
> Unfortunately, I still do not see the answers to the specific questions I asked about the way ScummVM’s GSoC operates. Those questions are again:
> 
> * What is the way in which work units are allocated?
> 
> ..prepare a comprehensive and detailed plan for all 12 weeks of your project. Include risk mitigation (you might fall ill, a phase in your project be more complicated than anticipated, etc.) and any existing commitments such as exams, vacations etc.
> This plan will help you and us to decide at any time during the project how well you are progressing. It forces you to think about what you need to do beforehand, and provides a guideline for you while GSoC is progressing.
> 
> Create a timeline for the project
> Again, we don't expect you to have a full-on, hour-by-hour break down.
> We assume that the schedule can and will change as the project goes on.
> That said, we want to make sure everything can fit into the GSoC timeline and that you think about how long things will take.
>  
> * How and where is the work progress tracked?
> ... we ask you to keep a weblog (BLOG) with posts on a weekly or more frequent basis detailing your progress and experiences with your project/GSoC.
> This provides a valuable avenue for feedback and helps involvement of the wider community. It also helps you to sort your thoughts and determine your own progress. Note that the blogs will be aggregated onto ScummVM's Planet site <http://planet.scummvm.org/> so language and tone should be set accordingly.
> ... we expect you to commit early, commit often.
> We judge students' code based on what is checked in and take the view that 'if it's not checked in it does not exist' for the purposes of GSoC reviews. Don't be shy about this. You may feel your code is not 'good enough', but the best way to learn whether it actually is good or not, and also to get valuable hints on how to improve it, is to show it to us. Trust us, we will give you constructive feedback and won't bash you for what you produce.
> 
>  
> * What is the process for making adjustments to the scope of the work if it appears that the schedule is too aggressive and milestones are not being met?
> ... we require you to communicate with your mentor every second day. Failing to do so for more than three days without arrangement will cause you to be dropped from the program.
> Consider that GSoC is a full time obligation. If you don't show up on a regular job for three days in a row, without any prior notice or reporting in as ill, you also run a high risk of being fired. Now, this is not exactly a regular day job and you don't have to come into an office every day. But communication is absolutely essential to a successful GSoC project and experience has shown that students that do not check in with their mentors (and the wider community) tend to struggle and produce weaker outputs. In particular, if you feel you are behind your schedule or otherwise in troubles, talk to us as soon as possible. Do not hide from your mentor -- they are here to help you at all times. Finally, this obligation doesn't have to be a burden, but rather should be a fun opportunity to chat with a nice fellow coder about interesting topics.
> 
>  
> * Is there a set criteria for a task to be considered completed successfully?
> Using the skelton, create Milestones for the project. IE:
> The engine can read .scr files
> Create API for creating a hardware accelerated texture
> The engine can move the character
> This is makes sure we all understand the complexities of the project
> Create a timeline for the project
> Again, we don't expect you to have a full-on, hour-by-hour break down.
> We assume that the schedule can and will change as the project goes on.
> That said, we want to make sure everything can fit into the GSoC timeline and that you think about how long things will take.
> 
>  
> 
> Since I am still not seeing what you are seeing, could you please help me and cut and paste the specific text from the project rules which answers each of these questions in a response to this email?
> I did that, hope it is clearer now.
> 
> 
> Eugene
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.scummvm.org
> http://lists.scummvm.org/listinfo/scummvm-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20180117/676e8388/attachment-0001.html>