The whole truth about Google Summer of Code - part 4
Part 1
Part 2
Part 3
1. How to live to the Final Report deadline?
On the one hand, everything is simple here - just keep working. On the other hand, the period after midterm is no less complicated than before. Firstly, if you left some large holes at the initial stage, then it’s time to patch them up. If earlier some bugs were forgiven, now your mentor expects your code to work better and better every day.
')
Secondly, it is at this stage that design errors that you made at the very beginning can be detected. If earlier you did not see (or deliberately lowered) the possibilities of expanding the functional, then now the stage of “putting meat on the bone” has just arrived. And if these bones turn out to be incorrectly designed, then you will not be able to hang the meat. Well, if you have to tweak the architecture a bit, or do one or two crutches, but if the architecture was originally wrong, then either cut the functionality or redo everything. Those. There is a chance to fail on the final report.
What exactly to do depends on the case. In one, the loss of some functionality will be almost imperceptible; in the other, it will be easier to do refactoring; somewhere it will be possible to manage a nasty crutch. Another very important thing is how you designed - alone or with a mentor. If the wrong architecture is the fruit of joint work, then you will decide together what to do with it and, most likely, the community will decide itself what improvements you need to do in order not to fail the final report. But if you listened to the mentor and did everything in your own way, then this is your failure. Moreover, not only in design, but also in communication skills. In this case, it is unlikely that they will continue to work with you.
How to go on vacation?
Most students take a short break after midterm. Some during the reporting week. But everyone goes on vacation, even mentors.
Organizations usually ask students when they plan their holidays. If you are not asked and you are planning a vacation - then honestly admit it to them.
In order to properly go on vacation, try to complete some major task. First, it will be easier for you to rest. Secondly, during the holidays you can relax a little, so it will be a little easier to get involved in working with an already working code.
If during the coding period you wrote a diploma or passed the session, i.e. almost did not engage in their project - then this was your vacation. Vacations are not the time when you personally rest, but the time when you are not working on the project.
If for some reason you need to hide your holidays, then make sure that during this time you have to test or write documentation. It would be nice to do some work in advance and commit them during the holidays, as if you were not at work, but at work. There are moments of rise and fall in development, so a slight decrease in activity for a week will not arouse suspicion.
2. How to survive the final report?
When you are all well and you are ready to go to the finish line, you can expect small surprises. Your mentor may have 1001 code requests that you must all do. For your part, you kind of did everything well and are already ready for the final chord; on the part of your mentor - you can become elusive Joe immediately after receiving the money and figs what will you finish. Therefore, your community will try to get a code from you that would work without further development. And since they still have a developer who wrote this very code, they will try to complete the development before you get the money. This is what you will do for the last 2 weeks. That is why nothing can be planned for August - you never know in advance about the new requirements of your mentor, by the way, he, too, did not know about them yet, but now it dawned on him.
Pencils down.
In the Western world, pencils down means pencils down, i.e. You don’t commit anything after day X. The program has two deadlines - soft and final. After soft, you can still commit and write. To be honest, soft deadline organizations do not consider the end of work to be “slaves to work, the sun is still high”. Those. it is likely that after the soft deadline, your organization will put you another list of requirements. But the final deadline - is quite final. Officially, Google is not interested in the code you commit after day X. That is, give Google you only the code that you commit to the last deadline. And here begins a little zapadlo - what to do if your mentor deigned to test the code only on the evaluation period, and you need to fix something. Here you need to read the rules of Google. This question is often asked by students, and, it seems, you can commit after the deadline, but you should not include this code in the archive. You describe the “extra” code in the README file and drop a link to it. But I advise you to finish everything before the beginning of the evaluation period and kick the mentor, give him a link to the recommendations of Google.
You send your code only after you received a positive result in the evaluation period. To create an archive you will be given 2 or 3 weeks. The sooner you send the code, the sooner Google will send the second package.
Dirty Khaki 3.
In your reports from mid-July, stop writing that there are any serious problems. If your holes can be detected only with very tricky testing or with in-depth code analysis - keep silent about them, otherwise you will not meet the deadline. If you are still burned, pretend to be a felt boot and thank the mentor for the good testing. But if not, then continue to work on. There will be time - redo it, no - finish it after the final report.
Write optimistic reports. The text about how everything should be zashib should be more than descriptions of your bugs and problems.
3. Fresh blood.
Officially, the goal of the program is to bring fresh blood to the community. Those. your community will sleep and see that they have both their codes and their codes. In the questionnaires for proposal, you certainly write that you will code even after the end of the program, but in reality students rarely stay. And in vain. If you keep in touch with the community, your participation for the next year will be guaranteed. So, if you enjoyed it, stay with them and keep working.
4. What else will good Google send me?
T-shirt, A4 cardboard, that you have successfully completed your project, and everything seems to be. Large communities send additional gifts to their students - either after the midterm or at the end of the work. What exactly send the community - a big surprise, such a chip like that.
5. Myths.
We are all equal:
Mentality matters. All the same, a different culture and a different education system do their job. Western students are less complexed, they ask more questions and are not afraid to communicate.
More rules, more problems:
The more rules in an organization, the better. In my last organization there were a bunch of rules, ranging from the number of spaces in the code to the size of commits. Moreover, mentors began to check the design at the selection stage, when candidates posted patches. My opinion is that this is better than in the middle (or at the very end) of summer, to learn that you need to “tweak” a little style and redo something.
Failure projects occur only in adult life:
Even if you have successfully completed your project, then do not expect that it will fall into the release. Not all student practices are used later.
With one proposalom not pass:
Oddly enough, it was with one proposal that I was able to get through. But I had a different philosophy here - you can’t make a patch or code a part of your future project, which means you won’t be able to work in the program at all.
Combining work and GSoC is impossible:
My friend, who decided to recall youth in the last year of graduate school, managed to work a full day to successfully complete GSoC. He also went on vacation, changed jobs and moved to another city. I do not call to engage in such masochism, just everyone has their maximum limit.
Everyone knows that Indians are fools:
The scholarship that you can get by participating in the program is pretty good money in India. Naturally, students from this country show considerable zeal to get into the program. And to compete with them is very difficult. While the rest of the students are outraged by the rule of the patch or any other coding, the Indians are quiet commits. When they do not enter the program, they commit. And when a year later they again served on their head, they were taken.
Yes, their code is not always beautiful and optimal, but I can not say that my students' labs are similar to the work of professionals. And when there is no difference, why show off?
Main code:
Sometimes it seems to me that the main thing is to tryndet. The more you try with the community and tell how you courageously coded the function from 100 lines or how important your project is for the community, the more “happy” it is.
As one student asked the community whether it was enough for his work and whether he would pass the midterm. One of the mentors wrote that he was pleased with the work, because I read in the student blog what benefits the project will bring to the community. The truth then added that he did not look at the code.
Girls are easier:
I do not think so. While the whole team was doing a headstand to help another student start coding his research project, my mentor sent me alone to dig out the Linux sources. In fact, everyone is equal in the program, and the community helps those who need help more or whose project they need more. There is no discrimination: neither racial, nor sexual, nor language.
Getting into the program is difficult:
If you follow all the rules of the community from the very beginning and take the writing of the proposal seriously (post it early, work with the sources, communicate with the mentors), then it will be easy to get into the program.
Getting into the program is easy:
Competition in an unpopular community (i.e., you have never heard of it and they code in an unpopular language, for example C or C ++, or where specific knowledge of mathematics is needed) 3-4 people per place. The number of applications in a popular community is about 100, so you need to try very hard to get noticed and selected among 100 people.
My mentor knows everything:
Your mentor only knows the part of the project he was working on. Of course, he has much more experience than you do, but even he does not have telepathy skills. Those. when you tell him about your problem, then most likely he will understand nothing or ask to describe everything again, but in more detail.
The community knows what I'm doing:
If you worked only with learning tasks before the program and the teacher knew in advance where you were working, then this is not the case. Only you know what you are doing, how you are doing and what problems you may have.
If I have problems, then only a mentor should know about them:
Many students mistakenly distance themselves from the community. However, issues such as coding style, documentation, testing, issues related to the backup mentor, it is better to solve with the whole community, rather than with the mentor.
All organizations follow the same rules when selecting:
There are such rules, but no recommendations will force the community to abandon their own experience. If the organization had several failed projects, where the student had excellent propozal, but there was no code and there were successful projects with short proposals, but with code, then the next time the organization will choose students who are able to code, not tryn.
I am one warrior in the field:
Oddly enough, you are not the one who code in your community. While you code function A, which pulls not your function B, someone can rewrite this function. Do not forget about merging. Other developers can either fix bugs or create new ones.
The documentation is always written:
Not always. Sometimes all that mentors can tell you is “look at the code.” In your organization, the docks may not be at all or it may happen that you code according to a standard that is poorly described in free literature, and a book where everything is described well may not be enough for you.
2 * 2 = 4:
At the University, some things are explained to you as a given, without saying why, and whether it can be different. Simply, the majority of students will not fall into situations where advanced knowledge is required. In GSoC, you may be confronted with the fact that your idea of ​​“standards” does not correspond to reality.
It doesn't matter what you did all summer, the main thing is to drag in front of the report:
If you post your precious code, it does not mean that the mentor will immediately throw him to watch. Perhaps he simply will not have time for this. One student, right before the midterm, committed 2000 lines of code; in fact, this was his first commit. His mentor honestly said that he might not have time to look at everything and test it until the end of the midterm.
I only work with my mentor:
My mentor did the first testing only at the midterm (or maybe did not at all), before that he was just looking at the code. Before midterm, another mentor made tests, but he also found a couple of bugs in me.
My mentor is a bureaucrat, Requires regular reports:
Mentors keep track of students, and Google keeps track of the community. If the community actively communicates with students in the mailing list or in the chat, then next year it will receive more slots. So "these stupid reports" are partly Google requirements.
It is good when your project is associated with a diploma:
But this is not necessary. Firstly, this is an additional psychological burden - so most students hate their diploma to defend, and you will still have an obligation to implement something similar. Secondly, our scientific society is not morally ready for open source code. Although my university and I set up a free office everywhere, but it’s not going to do something for money. So, in your eyes you drastically dragged you, and in the eyes of the university you sold valuable scientific information to a foreign company, depriving the university of all rights to your development, i.e. steal intellectual property. So, either take the project away from your scientific work, or keep quiet about your exploits.
6. From life.
The organization in which I last participated is little known and is developing in the C language (which is currently unpopular among students). The competition for participation was 3-4 people per place and all candidates already had experience in this area. I had no such experience, but I have already solved a similar problem. To pass through the competition, I had to write part of the project already at the stage of propozala. Mentors asked me only 2 questions - the first one concerned the code itself, the second one of one of the implementation stages. There were no lively discussions before or after the posting. Moreover, such a propozal frightened other students from my project.
My classmate did the same. At propozal he provided 30% of the code of the entire project and implemented the most complex option. The project was successfully completed, but this performance misled the mentors about the students' abilities. The following year, they greatly increased the complexity of the tasks that not all students did well.
My mentor answered all my letters immediately. But when I asked to test my code, it disappeared for a week. Another student had his mentor test the code only in the middle of the midterm, although he answered all the letters on time.
One of the parts was a short description of the project. The same description becomes public after your acceptance into the program. Because I suggested the project code, but I didn’t have much time to write the text - I just copied the description of the idea from the community site.
Because Since the organization had very strict rules regarding the style of the code, I received the most serious comments because of missing spaces and magic numbers.
The amount of code produced by a student at GSoC is 2-5 thousand lines of code.
In my organization, one of the students made a very gross design error. He did not discuss this moment with the mentor, so everything was revealed right before the midterm. Because There was already a lot of code, and it was simply physically impossible to extend the functionality to the promised level, the mentor himself proposed to trim the requirements.
In one organization, students from Eastern Europe and Russia participated in the program. All students coded, once a week they wrote to mentors and did not chat. Kodili students well and in time, but they did not chat. Actually, it was this fact that strained all the mentors. A couple of times the students were forcefully dragged into the chat, but the dialogue did not move beyond the greetings. Projects have been successfully completed, and the organization has added to the rules of participation communication through the newsletter and refused to chat.
In the questionnaires for proposals, all students write that they will continue contributing after the end of the program, but very rarely anyone remains in the organization. At best, they return the next year as GSoC students.
All students promise to work 40 hours a week. In reality, working hours rarely exceed 20 hours.
All students are divided into two types - some like the rule of the patch, others - hate. All organizations are divided into two types - some want code as a reference, others want constructive dialogue.
7. What to read?
1. Google recommendations for students:
I can not say that I agree with everything - many aspects of the work depend on the community and the project. But read these recommendations should be necessary.
2. Google recommendations for mentors:
We read necessarily. It is very important to understand how your mentors and organizations look at you.
3. A very famous article of the Russian-speaking mentor from gimp:
Many recommendations, both to students and mentors. A real look from the inside.
4. Instructions for handling a mentor:
Written very politically correct. For a Russian-speaking student it will be a bit difficult to understand the meaning of these tips. But the tips are very good.
5. Revelations of Google on how slots are divided:
Most of the slots are received by organizations that continue to work with old GSoC members, are covered by other organizations and successfully complete projects. Indirectly, these criteria may affect whether you choose or not.
6Extract from the discussion on how to prevent the disappearance of students:
If you read very carefully, it becomes clear that the rules for selecting candidates and evaluating them will become more and more complicated each year. So, those who do not like the rule of the patch or who like to do everything on the last day should think about whether they can participate at all.
Part 2
Part 3
1. How to live to the Final Report deadline?
On the one hand, everything is simple here - just keep working. On the other hand, the period after midterm is no less complicated than before. Firstly, if you left some large holes at the initial stage, then it’s time to patch them up. If earlier some bugs were forgiven, now your mentor expects your code to work better and better every day.
')
Secondly, it is at this stage that design errors that you made at the very beginning can be detected. If earlier you did not see (or deliberately lowered) the possibilities of expanding the functional, then now the stage of “putting meat on the bone” has just arrived. And if these bones turn out to be incorrectly designed, then you will not be able to hang the meat. Well, if you have to tweak the architecture a bit, or do one or two crutches, but if the architecture was originally wrong, then either cut the functionality or redo everything. Those. There is a chance to fail on the final report.
What exactly to do depends on the case. In one, the loss of some functionality will be almost imperceptible; in the other, it will be easier to do refactoring; somewhere it will be possible to manage a nasty crutch. Another very important thing is how you designed - alone or with a mentor. If the wrong architecture is the fruit of joint work, then you will decide together what to do with it and, most likely, the community will decide itself what improvements you need to do in order not to fail the final report. But if you listened to the mentor and did everything in your own way, then this is your failure. Moreover, not only in design, but also in communication skills. In this case, it is unlikely that they will continue to work with you.
How to go on vacation?
Most students take a short break after midterm. Some during the reporting week. But everyone goes on vacation, even mentors.
Organizations usually ask students when they plan their holidays. If you are not asked and you are planning a vacation - then honestly admit it to them.
In order to properly go on vacation, try to complete some major task. First, it will be easier for you to rest. Secondly, during the holidays you can relax a little, so it will be a little easier to get involved in working with an already working code.
If during the coding period you wrote a diploma or passed the session, i.e. almost did not engage in their project - then this was your vacation. Vacations are not the time when you personally rest, but the time when you are not working on the project.
If for some reason you need to hide your holidays, then make sure that during this time you have to test or write documentation. It would be nice to do some work in advance and commit them during the holidays, as if you were not at work, but at work. There are moments of rise and fall in development, so a slight decrease in activity for a week will not arouse suspicion.
2. How to survive the final report?
When you are all well and you are ready to go to the finish line, you can expect small surprises. Your mentor may have 1001 code requests that you must all do. For your part, you kind of did everything well and are already ready for the final chord; on the part of your mentor - you can become elusive Joe immediately after receiving the money and figs what will you finish. Therefore, your community will try to get a code from you that would work without further development. And since they still have a developer who wrote this very code, they will try to complete the development before you get the money. This is what you will do for the last 2 weeks. That is why nothing can be planned for August - you never know in advance about the new requirements of your mentor, by the way, he, too, did not know about them yet, but now it dawned on him.
Pencils down.
In the Western world, pencils down means pencils down, i.e. You don’t commit anything after day X. The program has two deadlines - soft and final. After soft, you can still commit and write. To be honest, soft deadline organizations do not consider the end of work to be “slaves to work, the sun is still high”. Those. it is likely that after the soft deadline, your organization will put you another list of requirements. But the final deadline - is quite final. Officially, Google is not interested in the code you commit after day X. That is, give Google you only the code that you commit to the last deadline. And here begins a little zapadlo - what to do if your mentor deigned to test the code only on the evaluation period, and you need to fix something. Here you need to read the rules of Google. This question is often asked by students, and, it seems, you can commit after the deadline, but you should not include this code in the archive. You describe the “extra” code in the README file and drop a link to it. But I advise you to finish everything before the beginning of the evaluation period and kick the mentor, give him a link to the recommendations of Google.
You send your code only after you received a positive result in the evaluation period. To create an archive you will be given 2 or 3 weeks. The sooner you send the code, the sooner Google will send the second package.
Dirty Khaki 3.
In your reports from mid-July, stop writing that there are any serious problems. If your holes can be detected only with very tricky testing or with in-depth code analysis - keep silent about them, otherwise you will not meet the deadline. If you are still burned, pretend to be a felt boot and thank the mentor for the good testing. But if not, then continue to work on. There will be time - redo it, no - finish it after the final report.
Write optimistic reports. The text about how everything should be zashib should be more than descriptions of your bugs and problems.
3. Fresh blood.
Officially, the goal of the program is to bring fresh blood to the community. Those. your community will sleep and see that they have both their codes and their codes. In the questionnaires for proposal, you certainly write that you will code even after the end of the program, but in reality students rarely stay. And in vain. If you keep in touch with the community, your participation for the next year will be guaranteed. So, if you enjoyed it, stay with them and keep working.
4. What else will good Google send me?
T-shirt, A4 cardboard, that you have successfully completed your project, and everything seems to be. Large communities send additional gifts to their students - either after the midterm or at the end of the work. What exactly send the community - a big surprise, such a chip like that.
5. Myths.
We are all equal:
Mentality matters. All the same, a different culture and a different education system do their job. Western students are less complexed, they ask more questions and are not afraid to communicate.
More rules, more problems:
The more rules in an organization, the better. In my last organization there were a bunch of rules, ranging from the number of spaces in the code to the size of commits. Moreover, mentors began to check the design at the selection stage, when candidates posted patches. My opinion is that this is better than in the middle (or at the very end) of summer, to learn that you need to “tweak” a little style and redo something.
Failure projects occur only in adult life:
Even if you have successfully completed your project, then do not expect that it will fall into the release. Not all student practices are used later.
With one proposalom not pass:
Oddly enough, it was with one proposal that I was able to get through. But I had a different philosophy here - you can’t make a patch or code a part of your future project, which means you won’t be able to work in the program at all.
Combining work and GSoC is impossible:
My friend, who decided to recall youth in the last year of graduate school, managed to work a full day to successfully complete GSoC. He also went on vacation, changed jobs and moved to another city. I do not call to engage in such masochism, just everyone has their maximum limit.
Everyone knows that Indians are fools:
The scholarship that you can get by participating in the program is pretty good money in India. Naturally, students from this country show considerable zeal to get into the program. And to compete with them is very difficult. While the rest of the students are outraged by the rule of the patch or any other coding, the Indians are quiet commits. When they do not enter the program, they commit. And when a year later they again served on their head, they were taken.
Yes, their code is not always beautiful and optimal, but I can not say that my students' labs are similar to the work of professionals. And when there is no difference, why show off?
Main code:
Sometimes it seems to me that the main thing is to tryndet. The more you try with the community and tell how you courageously coded the function from 100 lines or how important your project is for the community, the more “happy” it is.
As one student asked the community whether it was enough for his work and whether he would pass the midterm. One of the mentors wrote that he was pleased with the work, because I read in the student blog what benefits the project will bring to the community. The truth then added that he did not look at the code.
Girls are easier:
I do not think so. While the whole team was doing a headstand to help another student start coding his research project, my mentor sent me alone to dig out the Linux sources. In fact, everyone is equal in the program, and the community helps those who need help more or whose project they need more. There is no discrimination: neither racial, nor sexual, nor language.
Getting into the program is difficult:
If you follow all the rules of the community from the very beginning and take the writing of the proposal seriously (post it early, work with the sources, communicate with the mentors), then it will be easy to get into the program.
Getting into the program is easy:
Competition in an unpopular community (i.e., you have never heard of it and they code in an unpopular language, for example C or C ++, or where specific knowledge of mathematics is needed) 3-4 people per place. The number of applications in a popular community is about 100, so you need to try very hard to get noticed and selected among 100 people.
My mentor knows everything:
Your mentor only knows the part of the project he was working on. Of course, he has much more experience than you do, but even he does not have telepathy skills. Those. when you tell him about your problem, then most likely he will understand nothing or ask to describe everything again, but in more detail.
The community knows what I'm doing:
If you worked only with learning tasks before the program and the teacher knew in advance where you were working, then this is not the case. Only you know what you are doing, how you are doing and what problems you may have.
If I have problems, then only a mentor should know about them:
Many students mistakenly distance themselves from the community. However, issues such as coding style, documentation, testing, issues related to the backup mentor, it is better to solve with the whole community, rather than with the mentor.
All organizations follow the same rules when selecting:
There are such rules, but no recommendations will force the community to abandon their own experience. If the organization had several failed projects, where the student had excellent propozal, but there was no code and there were successful projects with short proposals, but with code, then the next time the organization will choose students who are able to code, not tryn.
I am one warrior in the field:
Oddly enough, you are not the one who code in your community. While you code function A, which pulls not your function B, someone can rewrite this function. Do not forget about merging. Other developers can either fix bugs or create new ones.
The documentation is always written:
Not always. Sometimes all that mentors can tell you is “look at the code.” In your organization, the docks may not be at all or it may happen that you code according to a standard that is poorly described in free literature, and a book where everything is described well may not be enough for you.
2 * 2 = 4:
At the University, some things are explained to you as a given, without saying why, and whether it can be different. Simply, the majority of students will not fall into situations where advanced knowledge is required. In GSoC, you may be confronted with the fact that your idea of ​​“standards” does not correspond to reality.
It doesn't matter what you did all summer, the main thing is to drag in front of the report:
If you post your precious code, it does not mean that the mentor will immediately throw him to watch. Perhaps he simply will not have time for this. One student, right before the midterm, committed 2000 lines of code; in fact, this was his first commit. His mentor honestly said that he might not have time to look at everything and test it until the end of the midterm.
I only work with my mentor:
My mentor did the first testing only at the midterm (or maybe did not at all), before that he was just looking at the code. Before midterm, another mentor made tests, but he also found a couple of bugs in me.
My mentor is a bureaucrat, Requires regular reports:
Mentors keep track of students, and Google keeps track of the community. If the community actively communicates with students in the mailing list or in the chat, then next year it will receive more slots. So "these stupid reports" are partly Google requirements.
It is good when your project is associated with a diploma:
But this is not necessary. Firstly, this is an additional psychological burden - so most students hate their diploma to defend, and you will still have an obligation to implement something similar. Secondly, our scientific society is not morally ready for open source code. Although my university and I set up a free office everywhere, but it’s not going to do something for money. So, in your eyes you drastically dragged you, and in the eyes of the university you sold valuable scientific information to a foreign company, depriving the university of all rights to your development, i.e. steal intellectual property. So, either take the project away from your scientific work, or keep quiet about your exploits.
6. From life.
The organization in which I last participated is little known and is developing in the C language (which is currently unpopular among students). The competition for participation was 3-4 people per place and all candidates already had experience in this area. I had no such experience, but I have already solved a similar problem. To pass through the competition, I had to write part of the project already at the stage of propozala. Mentors asked me only 2 questions - the first one concerned the code itself, the second one of one of the implementation stages. There were no lively discussions before or after the posting. Moreover, such a propozal frightened other students from my project.
My classmate did the same. At propozal he provided 30% of the code of the entire project and implemented the most complex option. The project was successfully completed, but this performance misled the mentors about the students' abilities. The following year, they greatly increased the complexity of the tasks that not all students did well.
My mentor answered all my letters immediately. But when I asked to test my code, it disappeared for a week. Another student had his mentor test the code only in the middle of the midterm, although he answered all the letters on time.
One of the parts was a short description of the project. The same description becomes public after your acceptance into the program. Because I suggested the project code, but I didn’t have much time to write the text - I just copied the description of the idea from the community site.
Because Since the organization had very strict rules regarding the style of the code, I received the most serious comments because of missing spaces and magic numbers.
The amount of code produced by a student at GSoC is 2-5 thousand lines of code.
In my organization, one of the students made a very gross design error. He did not discuss this moment with the mentor, so everything was revealed right before the midterm. Because There was already a lot of code, and it was simply physically impossible to extend the functionality to the promised level, the mentor himself proposed to trim the requirements.
In one organization, students from Eastern Europe and Russia participated in the program. All students coded, once a week they wrote to mentors and did not chat. Kodili students well and in time, but they did not chat. Actually, it was this fact that strained all the mentors. A couple of times the students were forcefully dragged into the chat, but the dialogue did not move beyond the greetings. Projects have been successfully completed, and the organization has added to the rules of participation communication through the newsletter and refused to chat.
In the questionnaires for proposals, all students write that they will continue contributing after the end of the program, but very rarely anyone remains in the organization. At best, they return the next year as GSoC students.
All students promise to work 40 hours a week. In reality, working hours rarely exceed 20 hours.
All students are divided into two types - some like the rule of the patch, others - hate. All organizations are divided into two types - some want code as a reference, others want constructive dialogue.
7. What to read?
1. Google recommendations for students:
I can not say that I agree with everything - many aspects of the work depend on the community and the project. But read these recommendations should be necessary.
2. Google recommendations for mentors:
We read necessarily. It is very important to understand how your mentors and organizations look at you.
3. A very famous article of the Russian-speaking mentor from gimp:
Many recommendations, both to students and mentors. A real look from the inside.
4. Instructions for handling a mentor:
Written very politically correct. For a Russian-speaking student it will be a bit difficult to understand the meaning of these tips. But the tips are very good.
5. Revelations of Google on how slots are divided:
Most of the slots are received by organizations that continue to work with old GSoC members, are covered by other organizations and successfully complete projects. Indirectly, these criteria may affect whether you choose or not.
6Extract from the discussion on how to prevent the disappearance of students:
If you read very carefully, it becomes clear that the rules for selecting candidates and evaluating them will become more and more complicated each year. So, those who do not like the rule of the patch or who like to do everything on the last day should think about whether they can participate at all.
Source: https://habr.com/ru/post/149795/
All Articles