Hello everyone!
This year Embox participated as a mentoring organization in the GSoC program . In this article I would like to talk about this, in our opinion, a very interesting experience.
I will say a few words about the GSoC program itself. Google Summer of Code is Google's global program aimed at engaging students in the open source world. As a result, students have improved code quality, technological literacy and skills in development processes. These qualities are improved due to the fact that students are involved in live industrial projects with sufficiently developed development processes. This should be the main motive for the participation of students in this program. The motivation of mentoring organizations is primarily the development and expansion of the project community.
A little about the formal rules. Only communities representing open source projects are allowed to the program. A project that has a repository, but only one developer will probably fail, because you need to devote time to students. An organization that wants to participate in the program must fill out a short questionnaire, declare at least two administrators and fill out a page with ideas proposed to students. The questionnaire includes a short description, contact details and a link to an idea page. Next comes the selection of organizations. When a project is accepted based on the selection results, the project card is published on the page of the mentoring organizations of the program, and the selection of students begins.
Selection of students is a very difficult stage for mentors. For the first time, Embox acted as a mentoring organization in the GSoC program. And we were somewhat unprepared for so many people who wanted to take part in the program. Formally, the selection of students takes place on the basis of essays (proposals), in which applicants talk about the tasks that they would like to complete by participating in the project and how they intend to do it. Of course, the essay contains data that is usually used in a resume, or it can be requested, but it is unlikely that this information is enough for understanding whether the student will be able to achieve the desired results. This is the main difficulty for mentors at this stage of the program.
In different projects, acquaintance and selection takes place in different ways. When discussing issues related to selection in the mailing list for GSoC mentors, someone recommended an interview on Skype, someone to complete test tasks, someone to see a detailed resume. At Embox, we decided to do the following. To participate in the program, it was necessary, firstly, to introduce yourself by writing a short letter to one of the project mentors. Secondly, complete at least one task from the list on github. And thirdly, write an official essay on the program website.
The first point did not cause any particular difficulties. Yes, there were some students who submitted their essays without even introducing themselves, but we simply did not consider them. I will explain the second point a little. Embox, like all fairly developed projects, has its own development processes, and usually students may simply lack the practice of participating in industrial and distributed projects. Moreover, Embox is an operating system. This is usually a new area in terms of practice for students. And before you start to improve the project at least something, you need to learn how to build, run, debug and make changes to the code, understand the processes adopted in the project, the same git workflow, and so on.
We did not want to do such things in the active phase of the program, and we tried to do it at the preliminary stage. We have created very simple Good First Issue tasks aimed at understanding the project processes, minimal knowledge of the C language, the ability to read documentation and search for information on the Internet. In fact, we were confident that after completing such tasks, the student will be able to make some changes in the code and prepare a Pull Request.
On this, the prerequisites for the official filing of the application were considered fulfilled. But students could continue to participate in the project by completing other tasks from the list on github and suggesting their improvements and changes. The only request we had was not to take the second Good First Issue. We wanted everyone to have an equal opportunity, and creating a lot of simple tasks turned out to be a daunting task. In all other respects, we tried to help all interested students, from the rules for setting up PR and working with git, and to explaining the architecture and features of the project.
Those students who continued to participate in the project whenever possible wrote very good essays. This is not surprising, because in this way they managed to dive deeper into the project, feel the task they would like to complete, and just gain experience.
Many of the essays of these students differed not only in the elaboration of the work plan, but also in the topics. We had a list of suggested topics posted on our ideas page, but we initially considered it only as a demonstration of possible directions. And we were very happy when they began to offer us their own themes.
It is important for us that the student can deal with a topic that is interesting to him. We see this as an additional motivation for students. But, of course, your own theme is not a prerequisite. We had very interesting topics, and many students, even immersed in the project, wanted to deal with a topic from the proposed list.
As a result of this period, more than 30 essays were submitted to the project. There were at least five very good students who not only met the minimum requirements, but also communicated with us about other tasks, tried to fulfill them, offered their own ideas, in general, showed interest in the project. But unfortunately, according to the results of the distribution, we got only two slots for students, we almost had to throw a coin. Fortunately, as we found out a little later, some of the good students went on to other projects.
We selected two students Erick Cafferata and Yuta Sakamoto... Both came up with their own ideas. Erick implement USB device mode for STM32. Yuta migrate Embox to MAiX-Bit board with RISC-V architecture. Interestingly, both of them had tasks from our list in their welcome email. But, as expected, after a deeper dive into the project, they formulated their ideas better.
The next stage in the official plan of the program was the stage of acquaintance, when students communicate more closely with the community and continue to study the project. Since both students were already involved in the project, it was more like a continuation of their acquaintance for them. Of course there was a difference. Since we already knew what topics the students had to implement, we offered them tasks close to the chosen areas.
As a result of this stage of the program, several preparatory tasks were completed, which, in my opinion, allowed students to move more successfully according to their plans in the future.
In the summer, the main stage of the program began - the development stage, as a result of which a new code should appear. This stage is divided into three parts, each for a month. After each part, certification is carried out. Students are expected to work evenly. And based on the results of each month, we must confirm that the students are on track.
In practice, we noticed different student activity. Sometimes it even seemed that the activity was lower than at the preliminary stage. It turned out that they had started a session or were overloaded with studies and could not devote enough time to participate in the program. But they worked very productively in other periods. It turned out that this was happening not only in our project. As a result of the summit of mentors, it was even proposed to simplify the rules and allow students and mentoring organizations to agree on the work schedule of students.
Communication is an important part of team development. Of course, Embox, like other open source projects, has its own communication mechanisms between developers. Embox has telegram chats ( English , Russian, news ) and mailing lists (English (embox-devel [at] googlegroups.com) and Russian (embox-ru [at] googlegroups.com)).
But, of course, some things that are discussed with students do not want to be made public. In addition, students are sometimes embarrassed to ask questions in the general chat. In addition, GSoC is an international program and for some there is a language barrier. One of our students wrote that it is difficult for him to communicate in English. As a result, to communicate with each of the students, we created private chats, in which there were two mentors: one main and one helping. The main communication on specific projects took place in these chats. Of course, communication common to the project took place in common places for the project ( telegram chator github ).
But, of course, the bulk of the program is focused on development. In the early stages, students had to follow third-party guidelines. A repository is cloned, a module is developed, a PR is offered, this PR is reviewed, approved and then merged into a project. That is, third-party developers use their own repository. In order to check the changes, you need to switch to this repository. This is fine when it comes to testing only, but when it comes to a piece of advice or a single task being developed by several people, it can add complexity. To avoid this, both students were added to the Embox team and thereby allowed them to create branches in the main repository. As a result, it turned out to be the right decision, because at the final stage of the program we worked quite closely with students,and it turned out that the students gained experience in team development.
Both students completed the program successfully. Erick demonstrated the correct display of STM32 connected to a computer using the lsusb utility. And Yuta demonstrated LED control using the Embox command utility . Of course, Erick also wanted to add the functionality of a device, and even developed ECM-ACM (virtual comport). And Yuta wanted to add support for the encryption module. But this was an underestimation of the complexity of the proposed work. I find the results obtained in three months in such a complex area as systems programming are impressive. And most importantly, the students got a great experience of teamwork, got to know the world of opensource better and significantly improved their technical skills.
PS Embox will take part in the online blitz session of the International Conference of Developers and Users of Linux Vacation / Eastern Europe Free Software - LVEE 2020 Online Edition (Lightning) on December 19 .