Difference between revisions of "SoC Information for Google"

From The Battle for Wesnoth Wiki
(Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here.)
Line 250: Line 250:
5.1) Are you familiar with any of the following tools or languages?
5.1) Are you familiar with any of the following tools or languages?
* Sub­­version (used for all commits)
* Git (used for all commits)
* C++ (language used for all the normal source code)
* C++ (language used for all the normal source code)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)
* STL, Boost, Sdl (C++ libraries used by Wesnoth)

Revision as of 18:30, 20 April 2013

This page is related to Summer of Code 2013
See the list of Summer of Code 2013 Ideas


SoC Information for Google

This is the information that we submit to google as Application in Summer of Code (current status: 2013). The submitter automatically becomes primary Admin. Most entries are mandatory and have to be filled out before the application can be submitted.

Organization id


Organization Name

Battle for Wesnoth

Organization description

Battle for Wesnoth, or simply Wesnoth, is a free, turn-based strategy game with role-playing elements that was designed in June 2003 by David White (Sirp).

Although the core rules are fairly simple and meant to be easily learned[1], they provide interesting gameplay and rich tactical options. A major strength of the project is the Wesnoth Markup Language (WML) for writing scenarios. Programming skills are not required to compose with it, and a large WML-modding community has generated a great deal of user-maintained content. We polish the best of this content and lift it into our official release tree.

The first stable release (1.0) was on October 2, 2005, and the latest stable release (1.10.6) happened in March 2013. Version 1.10 was released in January 2012, while the current development branch is 1.11.2 that was released earlier this month. We're later in our development cycle, but there are some good projects out there that students can work on.

Wesnoth is one of the most successful open-source game projects in existence, with an exceptionally large developer base and user community:

  • According to Ohloh, a site that collects activity statistics on open-source projects, the Wesnoth development effort is in the top 2% of largest and most active projects
  • We support two multiplayer game servers (stable and development) with a usual minimum load of more than a hundred players
  • More than two thousand downloads a day
  • 6 million downloads via SourceForge; many more via various mirrors of Linux distributions
  • Best rated game at the Linux Game Tome[2]
  • Game of the year 2007, 2008, 2009, 2010, 2011 and 2013 at LinuxQuestions.org[3][4]
  • In general, Wesnoth tends to show up in the first or second position whenever anyone compiles a list of top open-source games

Wesnoth's most notable features include:

  • A mature project with continuing active development and frequent improvements after 10 years of development
  • High quality artwork: both original graphics and music
  • Well­-balanced by a tireless team of playtesters
  • Fun, unique gameplay
  • Even after nearly a decade of development and a very solid, fun product already created, there are still plenty of new developers; the frequency of commits to the repository is still increasing
  • Strong support of internationalization with many supported languages, thus experience in working with non-native English speakers. In fact, more than half of our developers are not native English speakers.

For our Ideas page, please have a look at [5]. There you can find all information required to get you started working on Wesnoth.

[1] <a href="http://www.wesnoth.org/wiki/WesnothPhilosophy">http://www.wesnoth.org/wiki/WesnothPhilosophy</a>
[2] <a href="http://www.happypenguin.org/list?sort=avg_rating">http://www.happypenguin.org/list?sort=avg_rating</a>
[3] <a href="http://www.linuxquestions.org/questions/linux-news-59/2009-linuxquestions.org-members-choice-award-winners-788028/">http://www.linuxquestions.org/questions/linux-news-59/2009-linuxquestions.org-members-choice-award-winners-788028/</a>
[4] <a href="http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-choice-awards-93/open-source-game-of-the-year-855937/">http://www.linuxquestions.org/questions/2010-linuxquestions-org-members-choice-awards-93/open-source-game-of-the-year-855937/</a>
[5] <a href="http://wiki.wesnoth.org/SummerOfCodeIdeas">http://wiki.wesnoth.org/SummerOfCodeIdeas</a>

Organization home page url


Main Organization License:

GNU General Public License version 2.0 (GPLv2) [Dropdown box answer!]


Veteran [Dropdown box answer!]

Backup Admin


If you chose "veteran" in the dropdown above, please summarize your involvement and the successes and challenges of your participation. Please also list your pass/fail rate for each year.

Since 2008 we have participated in 5 years of GSOC, with good results. With the exception of our first year, we pass approximately 75% of our students, and usually get some really interesting code from them.

2008 results: Wesnoth participated in GSoC 2008 with four students. Out of these, two were great successes (that is they became full-fledge developers before the actual start of GSoC), did huge improvement during GSoC (A new recruitment algorithm for the AI and the basic structure for a new map editor, the student finished this work after the summer), and are still active developers in the Wesnoth community, even after 5 years. Two others eventually failed, but we learned from them that while great students should be left on their own, average students should be monitored much more closely than we did. If things seems to start to go wrong, it's important to react very quick, to meet with other mentors and get things back on track early.

Timezone problems were also a serious barrier for student/mentor communication, and we will take that more into account when pairing mentors and students.

For our other students, multiple problems collectively led to failure:

  • We should enforce IRC communication, E-mail is a barrier. This applies both for students and mentors. Both should be on IRC several hours a day, with overlapping hours.
  • We should be more strict about mid-term evaluation. If the student is slightly lacking at mid-term we should give a clear message that he needs to get back on track.

2009 results: In 2009 we mentored 6 students as part of Summer of Code. Out of these 5 projects were a success. From those 5 developers 3 are still part of our core development group and still maintain and improve the work they submitted as part of Summer of Code. One of the students even became the "head" of our AI development department and mentored a student this year. For a summary of the 2009 results have a look at [1].

2010 results: In 2010 we mentored 4 students as part of Summer of Code, all the projects were a success. from those 4 developers, 1 is still part of our code development team and maintains the work he has done as part of Summer of Code.

2011 results: In 2011 we mentored 5 students, with four of those successfully completed their projects. Some continued the work polishing their projects a little further even after GSoC, one continues to actively polish his work and just released a new version of his WML Editor.

2012 results in 2012 we mentored five students with four of them completing their project successfully. Most were from a set list of ideas provided by the project, which were aimed at fixing or updating parts of the code that never seemed to get fixed.

[1] http://forums.wesnoth.org/viewtopic.php?f=5&t=26955

2008: 2/4 2009: 5/6 2010: 4/4 2011: 4/5 2012: 4/5

If you chose "new" in the dropdown above, have you applied in the past? If so, for what year(s)?

[left empty]

Why is your organization applying to participate in Google Summer of Code 2013? What do you hope to gain by participating?

Most of our developers have particular areas of interest in which they work. Though they are efficient in their areas, there are other, presently uncovered, areas of the code with a need for improvements but a high barrier to entry for casual contributors. By bringing new people in and allowing them to be actively responsible for an area of code, we hope to kickstart work in these areas and others that are lagging behind. Our previous SoC experience shows that a motivated, full-time, student can be brought up to date in any area fairly quickly. Our previous experiences has shown us that SoC developers tend to stay after the end of the Summer of Code and become valuable members of our community. Finally, we feel that it is part of our mandate is to provide a platform for motivated contributors to develop their skills in a positive learning environment.

Overall GSOC has been a win for all parties and we want it to continue in the future.

What is the URL for your Ideas list?


What is the main development mailing list for your organization?


What is the main IRC channel for your organization?

#wesnoth-dev on irc.freenode.net

What criteria did you use to select your mentors for this year's program? 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.

Iurii 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 was a GSoC mentor 2010 and 2011. In 2011 he was a GCI mentor and administrator. 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 has been a GSoC mentor for Wesnoth since 2008.

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" [1] 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.

[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. The key is identifying candidates with the right mix of skills and temperament. 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 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 are in charge of reconnecting 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 resolve 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 repository 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 during the last years the amount of time required to mentor, and our mentors accepted the job knowing the amount of work it involved. All of this years mentors mentored last year as well, most have contributed since 2008, or been organizational admins.

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 and during 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). This year, we also have added some simple coding tasks directly related to our GSoC ideas to be able to test students more specifically on their future project

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 previous years, 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.

Last, our experience from previous years is that students that participate in the community during the evaluation period will stay active in the community after that period. In previous years this has been a discriminating criterias for students of similar level, and overall we never had problems of students working "behind a black wall." Our selection process tend to favor students who participate, and participation hasn't been a problem so far.

[1] http://wiki.wesnoth.org/EasyCoding

What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes?

The steps meant to involve the students in the community are the same steps we use to make it easy and rewarding to stay with the community even after Summer of Code is over. We really try to make students feel part of the community, particularly as equal developers, rather than just students working a summer job. This, we think, make them feel empowered, and want to remain an important part of the community.

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


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.

[left empty]

Application template

This template is no longer asked for during the initial application. Listing it here so that we can still reference it later on.

Does your organization have an application template you would like to see students use?

Students wishing to participate in GSoC should copy the questions below to a new page and fill it with the answers.

Please note that we generally plan to meet potential students through our IRC channel. So beside just answering these questions, potential candidates consider visiting us in IRC: #wesnoth-dev on irc.freenode.net. This is where most of our work takes place and participating in IRC is mandatory for GSoC students participating with Wesnoth. Our experience is that this is the easiest way to communicate and solve problems that come up.

1) Basics

1.1) Write a small introduction to yourself.

1.2) State your preferred email address.

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

1.4) Why do you want to participate in summer of code?

1.5) What are you studying, subject, level and school?

1.6) What country are you from, at what time are you most likely to be able to join IRC?

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

2) Experience

2.1) What programs/software have you worked on before?

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

2.5) Gaming experience - Are you a gamer?

2.5.1) What type of gamer are you?

2.5.2) What type of games?

2.5.3) What type of opponents do you prefer?

2.5.4) Are you more interested in story or gameplay?

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

We do not plan to favor Wesnoth players as such, but some particular projects require a good feeling for the game which is hard to get without having played intensively.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

3.2) What spoken languages are you fluent in?

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

3.4) Do you give constructive advice?

3.5) Do you receive advice well?

3.6) Are you good at sorting useful criticisms from useless ones?

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

4.2) If you have invented your own project, please describe the project and the scope.

4.3) Why did you choose this project?

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

4.5) Include as much technical detail about your implementation as you can

4.6) What do you expect to gain from this project?

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?

  • Git (used for all commits)
  • C++ (language used for all the normal source code)
  • STL, Boost, Sdl (C++ libraries used by Wesnoth)
  • Python (optional, mainly used for tools)
  • build environments (eg cmake/scons)
  • WML (the wesnoth specific scenario language)
  • Lua (used in combination with WML to create scenarios)

5.2) Which tools do you normally use for development? Why do you use them?

5.3) What programming languages are you fluent in?

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!

In general, students should be as verbose as possible in their answers and feel free to elaborate.