The whole truth about Google Summer of Code - part 3
Part 1
Part 2
Part 4
1. How to live to midterm (mid-term evaluations deadline)?
In the middle of summer you will find a very important report in front of Google. If you pass it, you will get your money, if not - you will fly out. The report itself is simple - you fill out a questionnaire, and your mentor fills out a questionnaire. If your mentor is pleased with you, i.e. he filled out a questionnaire - then you get the cherished bucks, if not - then they say goodbye to you.
')
The main criterion for passing midterm is to provide the promised code in your Timeline. No code - no money. Officially, Google is not interested in what exactly and how you are doing - the main thing is that the community be happy. If the community is happy, then Google is happy too. So, to live up to the report, you need to make the community happy.
To make the community happy, report regularly (remember that very word “democracy”). If no one forbids you to report to the list - send reports there. If you are blogging, then send short reports to the newsletter with a link to the full in your blog. It is important that the community also sees that you are working, and not just your mentor. You can forget to visit your blog, but mail check everything.
Chat with other developers. Sometimes you can get the greatest help, not from your mentor, but from another member of the community. So one student had problems that he reported on the mailing list. His mentor replied that he was disappointed with the current results and did not know why the “hello world” code did not work. But the rest of the developers have put a lot of effort to deal with the problem and find a solution. The mentor at the end of the thread only allowed to follow their advice.
Commit only clean code. Mentors very rarely view each student committ. Usually, the fact of the presence of the code and reports is enough for them (although a friend of mine somehow got caught by a mentor who checked all commits - but we decided that this is a biorobot). But all this until a certain time. It happens that the mentor had a free day and he finally decided to test your code, and you zakommitili your night work just this morning (yes, the most fantastic code is written at night), which is just godlessly buggy. And now, instead of making the community happy with your results, you will doubt all your work. And if this happened before the notorious midterm, when the mentor is ready to give you marks, it is doubly not good. So create yourself a trash bin somewhere, and leave the brunch for the working code.
If you have any problems or you fall through your deadline, then you should report this as soon as possible , better to the newsletter, so that all developers can help you. Your mentor and the community do not expect that you will immediately begin to shine and drag from the very first days (no, they certainly hope, but they understand perfectly well that this does not happen).
If you wrote your timeline from a scam, then as soon as you are able to write a viable plan - do it and send a copy to the mentor. So it will be easier for him to control the development process. Most often, the mentor asks exactly this question: “what have you done according to your plan and what are you doing now?”
Do not engage in detailed study of small parts in the initial stages of development. All customers think the same - first everyone wants to see the skeleton, and only then - the meat. By midterm, you must provide a working prototype, and not a couple of functions that are polished to shine. Mark the holes with “todo” and continue to develop further.
2. How to survive the midterm?
Two weeks before the start of this event, ask your mentor if he is pleased with your work and what result he is waiting for to the midterm.
Even if you work very well and clearly follow your plan, this does not mean that your mentor does not have in his head his own idea of ​​intermediate results. Maybe he thinks that some part will work exactly, and you have planned to test it only after the report. The difference is like a week - but in one case there is a working code, in the other there isn’t. Telepathy is the worst method of communication. So it is better to clarify everything in advance. A week before the midterm, you should definitely know his answer.
If you have not described your project very much in the ezine, then it's time to do it now. It happens that there is nothing to describe in the course of development, especially if the project is a research project and you have been busy with only one task all month or have coded one small but very complex function. If earlier in your report you had nothing to brag about, now you can write down everything you did, add test results and a description of the next development steps. Remember - "democracy", "happy".
Do not commit the dirty code in front of the midterm in the hope of showing you how far you have come. In just one or two weeks, developers will begin to be interested in your results. And it will not be very good if your draft version puts the whole system tightly. For the same reason, do not neglect the tests - your code will not be watched, it will be tested.
3. Overclocking the project and reports.
Somewhere two or three weeks before midterm, the project will be overclocked. Those. with each commit, more and more code and functionality are added. But your creation is not yet able to pass normal tests, so that only you alone can see that there is no longer just a piece of clay on the table, but a jug looming.
Unfortunately, mentors are deprived of telepathy, so they don’t see your pitcher. They see only that the clay has increased, and significantly. At such moments they have a slight panic, from which they emerge in two ways - they analyze your code themselves or ask to write a mega report. Code analysis - the script is almost fantastic, so do not count. Most likely, you will have to write a mega report on which all your further work will depend - either the mentor will see your pitcher, or you will prove that he is there.
Dirty khaki 2.
Of course, reports make your community happy, but this is only at the initial stage. Then, everyone wants to see an excellent working code, and your task is to provide this code to them.
But if you are code-codes, and then you run tests and it turned out that you did something a little wrong there and a very large piece needs to be improved or revised. And just then your mentor wants to look at the code and test it. A good student will think that it is not unreasonable for a mentor to look at such things and begin to rewrite everything, while a smart one commits as he is.
First, somehow your code still works and the fact that it passes some tests pleased you a little. Also, these results can please your mentor, because he will see something working and believe that he is about to make it work. Secondly, your entire project consists of works (there was such a subject for the 4th year, but at that time we somehow did not like this philosophy). Some of them are critical and need to be carried out sequentially, and some can be shifted in time. When you find that something critical is needed to be redone, and the report is close, then leave the working code alone and focus on other work. So you will pass the report and free up your time to finalize an important piece after the report. Thirdly, if you don’t drag out and your code doesn’t work as it should (and maybe even worse), the mentor may not believe you at all. How could he know that you really work, and not lying to him? So kommit, but rationally.
Other students will work with you. Look out at their progress out of the corner of your eye and try not to be worse than them. Mentor will not make happy the fact that his student is the weakest link. And remember, not all students are equal. There are students who are already part of the community, and they can conduct research at least the entire program, if the community needs it. But this does not mean that you can.
If a student has a problem and you know how to solve it, because you have already encountered something similar, help him. First, you will help a person, and secondly you will get +1 to sociability.
If you are asked to send some tricky report, and you do not understand what they want from you - do at least something. Better you get a wall of text from the comments and then rewrite it ten times later than you will be silent for a long time.
Golden Rule.
Russian technical school loves telepathy. If in your university it is easier for you to google all night or create a topic on all the technical forums of the runet, than to approach the teacher and listen to what kind of an idiot you are, that you didn’t think of everything, then this will not happen. Ask your mentor if you need help. After all, they are responsible for those who have been tamed.
4. How to use a mentor?
As a reference to the source.
5. Conflicts.
The fact of conflict is recognized by all - and Google and the community. I think, because The summer of coding is not conducted in the first year, then the mechanism for analyzing situations has already been worked out.
If you have:
1. Working prototype
2. You made regular reports.
3. You started kommitit code in late May
4. Did you follow your plan
and your mentor is still not happy with you, then you should turn to the community. If your mentor is not happy with your development, it does not mean that other developers will not like your results either. It is likely that the number of people “for” will be more than “against”. If there is someone in your community who is responsible for the whole GSoC, then ask him for an explanation about your future. If the community is also deaf to you, then you can turn to Google. But how will Google behave if the community is unhappily, even if not through the student’s fault, only Google knows. Google itself says that it is ready to provide its engineer for the analysis of this situation. Those. according to your proclamation, timeline and code, it determines whether the community is right or you. And this decision is final.
Although I think this is a situation where you have a working code and you followed all the rules, and everyone is unhappy with you - rather fantastic than real.
If you follow the guidelines for working with Google students, then you should say goodbye to a student if:
1. There is no promised code to midterm
2. The student is not very sociable and it is difficult to work with him further.
3. There is no certainty that the student will complete the project.
4. The student does not meet the expectations of the community.
6. Failed projects.
A successful project consists of three balanced parameters: time, budget, and resources. Everything is clear with the budget and resources, the time remains, which the students do not fit. Most often, failed projects are:
a) Research, when you can not assess the complexity of the development from the very beginning.
How does everything start?
The biggest problem of research projects is that research can be carried out to infinity, and where the point at which you need to stop, you may never know. First, the student slowly and enthusiastically read various articles, books, delves into the source, but then comes the time of the code, and he continues to explore. The point of no return is one week before the start of coding - at this time it would be good to start writing “hello world” programs instead of reading. Students write to the newsletter wall of the text with links and doubts, but the mentors are already opaque hinting that it is time to choose at least something and start coding. A student reads and reads.
What to do?
Do not participate in research projects. But if you have already managed to, or have specifically called you, set yourself a hard deadline to finish reading and start coding on a schedule. Even if you have to make many changes later, it will be easier psychologically to do this already on the basis of your code, than to make a late start, and even mentors will be calmer.
b) Projects where design of a complex architecture or API is required at the early stages.
How does everything start?
Students make one version, then at some stage of development they realize that it must be abandoned. The code is completely rewritten, and so two or three times. There is nothing unusual here - the normal development process, not everyone can immediately find the perfect solution that will be expandable. Little experience.
What to do?
Start development as early as possible so that there is time for kickbacks. Well, try to think carefully about all your architectural solutions before you implement them. Be sure to consult with mentors in difficult situations, especially when the coding time began, but there is still no working version.
c) Projects in which the goal of development by the community itself is not clearly set. For example, if the idea of ​​your project was originally described in the style of “there is such an unknown garbage and we want the same, but we don’t know what it is,” then it is possible that at some stage of development you will find out that you are doing a bit what is expected of you.
How does everything start?
After overclocking the project, when the code has already started to pass the first tests, the student suddenly finds out that the results should be a little different. Then begins a detailed analysis of the project and propozla.
What to do?
Write detailed reports every week, preferably back in May, when you are just dealing with the task. Either you catch all the misunderstandings in the early stages of development, or you have to review the usefulness of your development for the community right before the midterm.
d) Unrealistic projects, i.e. projects that require time to implement more than three months or the requirements for the developer are too high (they write “we need a guru”, but students think it’s about them).
How does everything start?
The student starts coding according to the schedule and then discovers that he skips his deadline one by one. It seems that the code is being written, but the backlog is growing and growing because more and more new pitfalls are discovered that were not visible at the stage of composing the proposal.
What to do?
Do not take such projects. If the organization has managed and imputed, then try to agree on a realistic result by August. Otherwise, you just fly because did not meet the expectations of the community. You can contact a friend. I think the organization will not care if you work alone or someone helps you, the main thing is that the code be.
7. Will they kick me out?
But it depends on the experience of the community. The way previous students behaved postpones an indelible imprint on the mentors' minds. There are “young” communities that participate for the first or second time. They have not yet run up against lazy students, so they can believe in you to the end.
Force majeure
Often during the program unforeseen situations occur. You are sick or have family problems, or you have a major accident - no matter what, but you start to miss the deadlines. Of course, you can agree with the mentor about the postponement or some shifts, but all your agreements are canceled at the midterm. That is, the midterm code is either there or not. You are paid for the work done, and if the work is done much less than what was agreed, you will not be paid. Everything is simple and no offense: money in the morning - in the evening chairs, in the evening money - in the morning chairs.
Why organizations failing projects?
Yes, not for anything, but it happened. Or the community recently participates and still does not know how to work with students, does not know what they are capable of, or mentors judge by themselves - “I could do something like this in his years ...” (not the fact that he could, but expect something like that) . It may also turn out that the community did not have failed projects and it goes on increasing, i.e. increases complexity, and students drag. But this time - well, not dragged. Or some mentor had a crazy idea in her head, she was added to the list for the sake of diversity, and then a student was found. Of course, the organization is responsible for the list of ideas and, it seems, it guarantees that any idea can be implemented in three months, but you also have a head on your shoulders and it can think. Doubt - do not touch the project, there may be another student who just drags.
Part 2
Part 4
1. How to live to midterm (mid-term evaluations deadline)?
In the middle of summer you will find a very important report in front of Google. If you pass it, you will get your money, if not - you will fly out. The report itself is simple - you fill out a questionnaire, and your mentor fills out a questionnaire. If your mentor is pleased with you, i.e. he filled out a questionnaire - then you get the cherished bucks, if not - then they say goodbye to you.
')
The main criterion for passing midterm is to provide the promised code in your Timeline. No code - no money. Officially, Google is not interested in what exactly and how you are doing - the main thing is that the community be happy. If the community is happy, then Google is happy too. So, to live up to the report, you need to make the community happy.
To make the community happy, report regularly (remember that very word “democracy”). If no one forbids you to report to the list - send reports there. If you are blogging, then send short reports to the newsletter with a link to the full in your blog. It is important that the community also sees that you are working, and not just your mentor. You can forget to visit your blog, but mail check everything.
Chat with other developers. Sometimes you can get the greatest help, not from your mentor, but from another member of the community. So one student had problems that he reported on the mailing list. His mentor replied that he was disappointed with the current results and did not know why the “hello world” code did not work. But the rest of the developers have put a lot of effort to deal with the problem and find a solution. The mentor at the end of the thread only allowed to follow their advice.
Commit only clean code. Mentors very rarely view each student committ. Usually, the fact of the presence of the code and reports is enough for them (although a friend of mine somehow got caught by a mentor who checked all commits - but we decided that this is a biorobot). But all this until a certain time. It happens that the mentor had a free day and he finally decided to test your code, and you zakommitili your night work just this morning (yes, the most fantastic code is written at night), which is just godlessly buggy. And now, instead of making the community happy with your results, you will doubt all your work. And if this happened before the notorious midterm, when the mentor is ready to give you marks, it is doubly not good. So create yourself a trash bin somewhere, and leave the brunch for the working code.
If you have any problems or you fall through your deadline, then you should report this as soon as possible , better to the newsletter, so that all developers can help you. Your mentor and the community do not expect that you will immediately begin to shine and drag from the very first days (no, they certainly hope, but they understand perfectly well that this does not happen).
If you wrote your timeline from a scam, then as soon as you are able to write a viable plan - do it and send a copy to the mentor. So it will be easier for him to control the development process. Most often, the mentor asks exactly this question: “what have you done according to your plan and what are you doing now?”
Do not engage in detailed study of small parts in the initial stages of development. All customers think the same - first everyone wants to see the skeleton, and only then - the meat. By midterm, you must provide a working prototype, and not a couple of functions that are polished to shine. Mark the holes with “todo” and continue to develop further.
2. How to survive the midterm?
Two weeks before the start of this event, ask your mentor if he is pleased with your work and what result he is waiting for to the midterm.
Even if you work very well and clearly follow your plan, this does not mean that your mentor does not have in his head his own idea of ​​intermediate results. Maybe he thinks that some part will work exactly, and you have planned to test it only after the report. The difference is like a week - but in one case there is a working code, in the other there isn’t. Telepathy is the worst method of communication. So it is better to clarify everything in advance. A week before the midterm, you should definitely know his answer.
If you have not described your project very much in the ezine, then it's time to do it now. It happens that there is nothing to describe in the course of development, especially if the project is a research project and you have been busy with only one task all month or have coded one small but very complex function. If earlier in your report you had nothing to brag about, now you can write down everything you did, add test results and a description of the next development steps. Remember - "democracy", "happy".
Do not commit the dirty code in front of the midterm in the hope of showing you how far you have come. In just one or two weeks, developers will begin to be interested in your results. And it will not be very good if your draft version puts the whole system tightly. For the same reason, do not neglect the tests - your code will not be watched, it will be tested.
3. Overclocking the project and reports.
Somewhere two or three weeks before midterm, the project will be overclocked. Those. with each commit, more and more code and functionality are added. But your creation is not yet able to pass normal tests, so that only you alone can see that there is no longer just a piece of clay on the table, but a jug looming.
Unfortunately, mentors are deprived of telepathy, so they don’t see your pitcher. They see only that the clay has increased, and significantly. At such moments they have a slight panic, from which they emerge in two ways - they analyze your code themselves or ask to write a mega report. Code analysis - the script is almost fantastic, so do not count. Most likely, you will have to write a mega report on which all your further work will depend - either the mentor will see your pitcher, or you will prove that he is there.
Dirty khaki 2.
Of course, reports make your community happy, but this is only at the initial stage. Then, everyone wants to see an excellent working code, and your task is to provide this code to them.
But if you are code-codes, and then you run tests and it turned out that you did something a little wrong there and a very large piece needs to be improved or revised. And just then your mentor wants to look at the code and test it. A good student will think that it is not unreasonable for a mentor to look at such things and begin to rewrite everything, while a smart one commits as he is.
First, somehow your code still works and the fact that it passes some tests pleased you a little. Also, these results can please your mentor, because he will see something working and believe that he is about to make it work. Secondly, your entire project consists of works (there was such a subject for the 4th year, but at that time we somehow did not like this philosophy). Some of them are critical and need to be carried out sequentially, and some can be shifted in time. When you find that something critical is needed to be redone, and the report is close, then leave the working code alone and focus on other work. So you will pass the report and free up your time to finalize an important piece after the report. Thirdly, if you don’t drag out and your code doesn’t work as it should (and maybe even worse), the mentor may not believe you at all. How could he know that you really work, and not lying to him? So kommit, but rationally.
Other students will work with you. Look out at their progress out of the corner of your eye and try not to be worse than them. Mentor will not make happy the fact that his student is the weakest link. And remember, not all students are equal. There are students who are already part of the community, and they can conduct research at least the entire program, if the community needs it. But this does not mean that you can.
If a student has a problem and you know how to solve it, because you have already encountered something similar, help him. First, you will help a person, and secondly you will get +1 to sociability.
If you are asked to send some tricky report, and you do not understand what they want from you - do at least something. Better you get a wall of text from the comments and then rewrite it ten times later than you will be silent for a long time.
Golden Rule.
Russian technical school loves telepathy. If in your university it is easier for you to google all night or create a topic on all the technical forums of the runet, than to approach the teacher and listen to what kind of an idiot you are, that you didn’t think of everything, then this will not happen. Ask your mentor if you need help. After all, they are responsible for those who have been tamed.
4. How to use a mentor?
As a reference to the source.
5. Conflicts.
The fact of conflict is recognized by all - and Google and the community. I think, because The summer of coding is not conducted in the first year, then the mechanism for analyzing situations has already been worked out.
If you have:
1. Working prototype
2. You made regular reports.
3. You started kommitit code in late May
4. Did you follow your plan
and your mentor is still not happy with you, then you should turn to the community. If your mentor is not happy with your development, it does not mean that other developers will not like your results either. It is likely that the number of people “for” will be more than “against”. If there is someone in your community who is responsible for the whole GSoC, then ask him for an explanation about your future. If the community is also deaf to you, then you can turn to Google. But how will Google behave if the community is unhappily, even if not through the student’s fault, only Google knows. Google itself says that it is ready to provide its engineer for the analysis of this situation. Those. according to your proclamation, timeline and code, it determines whether the community is right or you. And this decision is final.
Although I think this is a situation where you have a working code and you followed all the rules, and everyone is unhappy with you - rather fantastic than real.
If you follow the guidelines for working with Google students, then you should say goodbye to a student if:
1. There is no promised code to midterm
2. The student is not very sociable and it is difficult to work with him further.
3. There is no certainty that the student will complete the project.
4. The student does not meet the expectations of the community.
6. Failed projects.
A successful project consists of three balanced parameters: time, budget, and resources. Everything is clear with the budget and resources, the time remains, which the students do not fit. Most often, failed projects are:
a) Research, when you can not assess the complexity of the development from the very beginning.
How does everything start?
The biggest problem of research projects is that research can be carried out to infinity, and where the point at which you need to stop, you may never know. First, the student slowly and enthusiastically read various articles, books, delves into the source, but then comes the time of the code, and he continues to explore. The point of no return is one week before the start of coding - at this time it would be good to start writing “hello world” programs instead of reading. Students write to the newsletter wall of the text with links and doubts, but the mentors are already opaque hinting that it is time to choose at least something and start coding. A student reads and reads.
What to do?
Do not participate in research projects. But if you have already managed to, or have specifically called you, set yourself a hard deadline to finish reading and start coding on a schedule. Even if you have to make many changes later, it will be easier psychologically to do this already on the basis of your code, than to make a late start, and even mentors will be calmer.
b) Projects where design of a complex architecture or API is required at the early stages.
How does everything start?
Students make one version, then at some stage of development they realize that it must be abandoned. The code is completely rewritten, and so two or three times. There is nothing unusual here - the normal development process, not everyone can immediately find the perfect solution that will be expandable. Little experience.
What to do?
Start development as early as possible so that there is time for kickbacks. Well, try to think carefully about all your architectural solutions before you implement them. Be sure to consult with mentors in difficult situations, especially when the coding time began, but there is still no working version.
c) Projects in which the goal of development by the community itself is not clearly set. For example, if the idea of ​​your project was originally described in the style of “there is such an unknown garbage and we want the same, but we don’t know what it is,” then it is possible that at some stage of development you will find out that you are doing a bit what is expected of you.
How does everything start?
After overclocking the project, when the code has already started to pass the first tests, the student suddenly finds out that the results should be a little different. Then begins a detailed analysis of the project and propozla.
What to do?
Write detailed reports every week, preferably back in May, when you are just dealing with the task. Either you catch all the misunderstandings in the early stages of development, or you have to review the usefulness of your development for the community right before the midterm.
d) Unrealistic projects, i.e. projects that require time to implement more than three months or the requirements for the developer are too high (they write “we need a guru”, but students think it’s about them).
How does everything start?
The student starts coding according to the schedule and then discovers that he skips his deadline one by one. It seems that the code is being written, but the backlog is growing and growing because more and more new pitfalls are discovered that were not visible at the stage of composing the proposal.
What to do?
Do not take such projects. If the organization has managed and imputed, then try to agree on a realistic result by August. Otherwise, you just fly because did not meet the expectations of the community. You can contact a friend. I think the organization will not care if you work alone or someone helps you, the main thing is that the code be.
7. Will they kick me out?
But it depends on the experience of the community. The way previous students behaved postpones an indelible imprint on the mentors' minds. There are “young” communities that participate for the first or second time. They have not yet run up against lazy students, so they can believe in you to the end.
Force majeure
Often during the program unforeseen situations occur. You are sick or have family problems, or you have a major accident - no matter what, but you start to miss the deadlines. Of course, you can agree with the mentor about the postponement or some shifts, but all your agreements are canceled at the midterm. That is, the midterm code is either there or not. You are paid for the work done, and if the work is done much less than what was agreed, you will not be paid. Everything is simple and no offense: money in the morning - in the evening chairs, in the evening money - in the morning chairs.
Why organizations failing projects?
Yes, not for anything, but it happened. Or the community recently participates and still does not know how to work with students, does not know what they are capable of, or mentors judge by themselves - “I could do something like this in his years ...” (not the fact that he could, but expect something like that) . It may also turn out that the community did not have failed projects and it goes on increasing, i.e. increases complexity, and students drag. But this time - well, not dragged. Or some mentor had a crazy idea in her head, she was added to the list for the sake of diversity, and then a student was found. Of course, the organization is responsible for the list of ideas and, it seems, it guarantees that any idea can be implemented in three months, but you also have a head on your shoulders and it can think. Doubt - do not touch the project, there may be another student who just drags.
Source: https://habr.com/ru/post/149794/
All Articles