Google Summer of Code Informations: Difference between revisions

Jump to navigation Jump to search

Google Summer of Code Informations (view source)

Revision as of 21:05, 1 March 2012

6,490 bytes removed ,  14 years ago
→‎SoC Information
VisualWikitext
No edit summary
Line 41: Line 41:
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev


=== Why is your organization applying to participate in GSoC 2010? What do you hope to gain by participating? ===
=== Why is your organization applying to participate in GSoC? What do you hope to gain by participating? ===
Dolibarr project has a lot of developers into europe and south america. We lack developers from other area (north america and asia). Participating to Google Summer of Code may be a good way to promote developers from such area. Also the project becomes a big success into OpenSource world and we need more developers to develop more "touched" features the core team has no time to work on.
Dolibarr project has a lot of developers into europe and south america. We lack developers from other area (north america and asia). Participating to Google Summer of Code may be a good way to promote developers from such area. Also the project becomes a big success into OpenSource world and we need more developers to develop more "touched" features the core team has no time to work on.
Also, we hope developers found with Google summer of code are interesting people so that they might be valuable for project.
Also, we hope developers found with Google summer of code are interesting people so that they might be valuable for project.
Line 55: Line 55:


=== What criteria did you use to select your mentors for this year's program? Please be as specific as possible.* ===
=== What criteria did you use to select your mentors for this year's program? Please be as specific as possible.* ===
As we apply for the first time, we don't want to take any risk. The mentors were chosen according to their amount and activity on project. This means
As we apply for the first time, we don't want to take any risk. The mentors were chosen according to their activity on project. This means
mentors are the major contributors of project.
mentors are the major contributors of project (Laurent Destailleur, Régis Houssin, Juanjo Menent, Cyrille De Lambert, Philippe Grand). All of them
works on project since now between 5 (minimum) and 10 years (maximum).
Also all the mentors had to be volunteers.


=== What is your plan for dealing with disappearing students?* ===
=== What is your plan for dealing with disappearing students?* ===
The first way, will be by selecting correctly the student: if we do not see any motivation among the candidate, we will probably not accept the idea at all.
The first thing will probably to avoid this by providing them a real interest to work for project (no hidden information, statistics, ...).
Then, we will try to exchange again and again to try to restore communication and convince him to go back on project.
Also we will try to avoid this by selecting correctly the student: if we do not see enough motivation among the candidate, we will probably not accept the couple student/idea at all.
Then, we will ask him to commit any code or documentation he produces at a regular frequency (to avoid loosing all the work) if disappearing is definitive. The mentor is already ready to try to use all works that is possible to restore.
And if it happens, we will try to exchange again and again to try to restore communication and convince him to go back on project.
Then, we will ask him to commit any code or documentation he produces at a regular frequency (to avoid loosing all the work) if disappearing is definitive. The mentor is already ready to try to use all works that is possible to restore. This is also a way for us to follow its work frequently and providing him frequent feedbacks/advices or directives, hoping this will show him he is not alone.


=== What is your plan for dealing with disappearing mentors?* ===
=== What is your plan for dealing with disappearing mentors?* ===
Line 67: Line 70:
The backup mentor will replace the mentor if the main mentor disappears.
The backup mentor will replace the mentor if the main mentor disappears.


=== What steps will you take to encourage students to interact with your project's community before, during and after the program? ===
We have a tutorial on our developer wiki site (wiki.dolibarr.org) to provide most possible information to help the student to understand how we works.
This should help him to find any contacts and way to contacts. Also we also describe how to use tools to take in touch with team. This does not encourage him but avoid him to be discouraged.
To encourage him, we have decided to define only major, influent and also very experienced developers. We will try to convince him, he has a lot of thing to learn by working with such mentors.
We will also select student to be sure he is opened to criticism and curious as this is the best way to find people that naturally ask help.




=== Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here ===
I'm afraid no.


 
=== Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here. ===
 
As we apply for the first time, we don't think this is a good thing for the moment, even if we are a large organization.
 
==== What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible: ====
Our first criterion was that all the people had to be volunteers. According to other open source projects and our experience from the last two years, being a SoC mentor takes a lot of time and the person has to be ready to spend quite some time with the student.
 
Boucman is one of the oldest active developers around. He has rewritten the whole animation engine and made it an easily pluggable system allowing artists to easily specify exactly how they want the units to appear. He also started many community oriented projects like the Art Contribution[1] section of the wiki (now deprecated) and the WML Reference Manual[2]. He is responsible for dispatching and sorting the patches at http://patches.wesnoth.org that has created the new developer process we currently use. Boucman was a mentor in 2008 and 2009.
 
Yurii Chernyi (Crab) has joined the team in 2009, taking part in Google Summer of Code 2009, and staying with the project as a developer after successful completion of GSoC. He's an expert on all aspects of current Wesnoth AI codebase (having fully reorganized it as part of GSoC 2009), and has fixed numerous bugs all over Wesnoth. He is experienced in teaching other people, in areas like programming languages and math.
 
Mordante is one of the most active developers on our IRC channel. Not only has he done preliminary studies and coding in multiple areas that are candidates for Summer of Code ideas, he also is one of the coders with the best overview of the Wesnoth code. A large part of his work involves refactoring and polishing existing code. Next to that he's very active with fixing bugs which leads him to all areas in the code base. He is currently completing a rewrite of the Wesnoth GUI library, making all windows configurable through WML. This should make it easier to use Wesnoth on different resolutions, from small handheld devices to large 30 inch screens. Mordante was a mentor in 2008 and 2009.
 
All other developers listed in the ideas page are the leading capacities we do have for the respecting areas. Have a look at our list of "people who to contact" [3] for an easy reference. In general all our developers will mentor all students. That is, questions should just be asked in our IRC channel, where basically every developer who has an idea can and will directly answer.
 
When choosing the mentors, we have kept in mind that most developers can answer most technical questions, and we have chosen people that are well known for interacting with new-comers/external developers and can provide general guidance and design advice, more than people with specific technical knowledge.
 
[1] http://wiki.wesnoth.org/UnsortedContrib
 
[2] http://wiki.wesnoth.org/ReferenceWML
 
[3] http://wiki.wesnoth.org/SoC_People_to_bug_on_IRC
 
==== What is your plan for dealing with disappearing students? ====
The first thing to do is to avoid this situation altogether.
 
Wesnoth is a game, and as such has lots of developers that are not coders. In particular, artists are well known in the Wesnoth community for being very sensitive about criticism and our community is used to people being sensitive to critics.
 
We will try to choose students that accept criticism and are able to filter constructive criticism from useless one. The Wesnoth developer community is used to judging people according to these criteria and the special title we are going to give to applicants will allow us to easily spot any such problems and discuss them before they grow out of control.
 
If a student disappears, their mentor will be in charge of recontacting the student to see what is going wrong (available time, tension with other developers, with members of the community etc...). Depending on the actual problem, the mentor and the student will have to agree on possible ways to defuse the problem.
 
If a student disappears completely and there is no way to get back to them, there is little the project can do except salvaging whatever can be salvaged from the code (the students will have SVN write access, so most of the work will be committed either to trunk or to a specific branch) and find a core developer to take on the job. This will probably be slower and less effective for the project, but it's the best we can do.
 
==== What is your plan for dealing with disappearing mentors? ====
All our mentors are long time developers that volunteered for the job, so we don't expect that to happen. We observed in 2008 the amount of time required to mentor, and our mentors accepted the job knowing the amount of work it involved. Most of them were mentors last year too.
 
However, should it happen, we would continue to mentor as a developer community the student until we find a new "official" mentor to take on the job.
 
==== What steps will you take to encourage students to interact with your project's community before, during and after the program? ====
Wesnoth has a particularly healthy community, both for developers and for players.
 
Our general policy regarding new coders has always been "two (non trival) patches... you're in". With other words, anybody that is able to get two non-trivial patches applied is offered commit privileges.
We have a developer responsible for applying patches and guiding new developers into our community. This is a well known and effective process we plan to apply to students, directing them to our EasyCoding pages [1] (these projects are usually a couple of hours long and hve been chosen to provide easy access to the respective area of code).
 
Usually, patches go back and forth a couple of times, to make sure that all secondary things are in place (indenting, coding style, modified buildfiles etc.) The idea is that coder education should take place before the coder gets commit rights, but that getting new coder in is one of the most important things to keep our project alive.
 
If the student is proactive and ready to join IRC, all the developers are usually very welcoming, and good at directing newcomers to quickly give useful results.
 
In 2008 and 2009 all students that were accepted (and a couple more) managed to have commit access before the start of the coding phase. We consider that this policy was successful and we plan to keep it this year.
 
We also plan to give a special forum title to any students. This will allow all forum members to tell them apart from normal users and give them read/write access to the developer only forums. This will also allow us to quickly spot any problem they might have interacting with the player community. We have a very mature developer community, but our player community is made of all sort of people of all age and education, and it can sometimes be rough.
 
 
[1] http://wiki.wesnoth.org/EasyCoding
 
==== What will you do to ensure that your accepted students stick with the project after GSoC concludes? ====
Since our community has a history of having developers join easily and quickly, we expect the student to be a full-fledged developer quite fast (probably a little after the end of the bonding period).
 
Thus there will be no "end of GSoC" transition. At the end of the Summer of code we expect the student to be responsible for the part he developed, and to continue taking care of it, just as other developers are responsible for their part. In general we show students that we appreciate their work by directly having most of the work happen directly in trunk. So their work is included in each development release right from the start. No need for any merging of external branches or the likes. Their work is handled like the work of any other developer we have.
 
In 2008 both students that succeeded stayed and are still active developers. Three of the students from 2009 are still active developers, one even applying to be mentor this year.
 
 
==== Is there anything else you would like to tell the Google Summer of Code program administration team? : ====
There is nothing more to say.
 
===== Add a Comment (optional): =====
(empty)
 
==== Backup Admin (Link ID): ====
(empty)
 
==== Admin Agreement: ====
(some terms of service by Google that have to be agreed upon)
Retrieved from "https://wiki.dolibarr.org/index.php/Special:MobileDiff/24968"

Navigation menu