My GSOC workflow
I have talked about what my project is about, and some weeks have passed since the start of the coding period, however, now I realize I have yet to talk about what GSoC is and what is my daily routine as a participant. This post will have two main sections, one little introduction about GSoC (all the info about the program is available on its official site), and a second larger section on my daily work routine.
GSoC
Google Summer of Code is a global program organized by Google Open Source. Its goal is at the same time to support students by giving them the opportunity to work as programmers during their summer and to empower and increase the open source software community. It started in 2005 with 200 students, growing every year.
GSoC has two selection phases, one for free open source projects and another for students. Once the organizations have been selected, it is up to the organizations alone to choose which students are accepted. Google’s role is to assign the number of student slots per organization, not who fills them. I have not been able to find much information about the slot assignment process, but it looks like it depends on the number of proposals received and the total number of students each organization is able to mentor. Afterwards, during the summer, students code for their open source project.
Eventually, there is a final evaluation, were students must also write a summary of their work and links to the code produced.
My workflow
My work for DeepForest during GSoC covers a wide range of tasks that goes even further from all the tasks detailed in the proposal. Hence, organization and planning are vital in order to achieve my goals. Moreover, not only I have to plan all the different tasks and how to divide work but also when to do them.
For task management, GitHub itself already has plenty of features to help me organizing them. When I started coding, I would send a pull request to from my fork to DeepForest main repository. I also include a description of the PR goals and some examples in the first PR message. This methodology allows all DeepForest contributors to know what the PR is about, and to advise and review early on in the coding process. In addition, all continuous integration test are run for most of the commits, making sure I am not breaking any of the other functions in DeepForest. In some cases, I also used checklists (which can be directly embedded in PR messages) to keep track of all features and sub tasks pending in the PR. Eventually, if some related sub task goes beyond the PR, I would create an issue to keep track of these pending tasks.
Afterwards, when the PR reached its end point, before considering it ready for merging, I would also test the code in some relish examples, not only in the automated continuous integration tests. I already have a whole task in the proposal for testing on real examples, which is why these examples are quite simple and I label them as relish, not as real. In some weeks I do plan to get to the real case testing, Doing this I plan to achieve goal which is to prove that all the algorithms and code work in all real cases.
Comments
Post a Comment