Editing Google Summer of Code/2009/OrgApplication

= Description = 
BZFlag is a free online multiplayer cross-platform open source 3D tank battle game that is maintained by an active community of individuals distributed all around the world.  It is one of the most successful and sustained cross-platform open source games ever with an active developer, administrative, and player community.  There have been more than a million downloads in the last five years alone and our user base presently consists of more than 200 players online at any time of day or night.  The project has actually become more popular over the years as we continue to improve and enhance the game.  BZFlag has been under active development since 1992.

Our organization is presently comprised of a rather disparate group of individuals that work on BZFlag because they love the game and the community that surrounds it.  There are presently 71 individuals entrusted with access to BZFlag core resources including 46 individuals that have committed source code modifications over the project's life span.  Our developer base presently consists of 9 documented core developers that have made extensive contributions to the game and remained active over many years, along with about a dozen apprentice-level developers that are coming up in the ranks, and about two dozen peripheral/casual developers, extension developers, and web integration programmers.  Additionally, there are several dozen trusted staffers, server operators, and graphic artists that assist in the day-to-day operations needed by the game for keeping servers up and running, providing server list services, designing artwork, providing network statistics, image hosting, web hosting, and much more.

All of our project developers almost exclusively collaborate on the #bzflag Freenode IRC channel, which is the central hub for most of our development discussions, decision planning meetings, game operations, and network infrastructure administration.  We operate via a benevolent dictatorship combined with a meritocracy that strives for consensus between the core developers and other involved community members.  Extensive discussions are held for any changes to BZFlag that affect the game's traditional spirit, mood of gameplay, tone of the user environment, and types of interactions possible in the game.  These discussions also include considerations whenever there are new features being added such as new flags, enhanced graphics, or changes to the gameplay.  We also serve as a support arm to our user community assisting them with anything from how to get started playing to providing assistance with setting up their own server or even helping them write their own new extensions to the game.

From IRC, we administer network operations for more than 19000 registered players and for the tens of thousands of unregistered players that engage in more than 10000 daily player sessions across more than 250 public servers.  As we are a globally distributed network-oriented game, we also maintain the public server listings, provide player tracking, network statistics, global authentication, user and group management, abuse and ban controls, player conflict resolution, competitive league management, and user community support.

= Why is your group applying to participate? What do you hope to gain by participating =

Our primary intention for participating in GSoC 2009 is to attract new developers.  We already have visibility, popularity, familiarity, and a very active community.  The strongest factor in our long-term development initiatives, however, is the number of active developers that we have at any given time.

GSoC has shown to provide an exceptional opportunity for us to entice new developers to our community and keep them working with us over the long term.  It's been a great program for attracting new talent, inspiring new development initiatives, and even for getting our existing developers more organized and collaborating more effectively.

We've enjoyed collaborating on experimental efforts that have had strong academic and research goals, while helping promote and improve BZFlag in the process.  BZFlag is used by several universities (e.g., Brigham-Young University) as an artificial intelligence framework and has also been the subject of several academic research projects related to network communications (ACM-published research papers).  Indiana University researchers worked with our staff in 2007 to use BZFlag as a platform for conducting a social network analysis.  We'd particularly like to improve these facilities to help encourage even wider use of BZFlag for academic and research purposes.

Task-wise, we hope to work with these new developers to implement several enhancements to BZFlag that we know will have a big impact on those that play the game.  Past participation in GSoC has stimulated our project development activities and forced us to become more organized, collaborative, and deliberate in our focus.  Our community members have great ideas for improving the game and we would like to encourage these developments.  GSoC provides a mutually beneficial means to that end, particularly for students that we can attract to our project as new developers that stay with the project.

= What criteria do you use to select the members of your group? Please be as specific as possible. =

All of the mentors listed are actively engaged in the BZFlag community as core developers, apprentice developers, web service developers, and network operators.  Mentors were selected from among our core community of project contributors that are actively engaged on a day-to-day basis .  All mentors needed to have gained enough rapport and trust with those already actively involved to the extent that they've been entrusted with source code access, decision-making authority, and that have sustained activity for months or years on end.  The mentors also needed to show competency in the BZFlag source code, our project directions, our operating philosophies, and a basic familiarity with our social dynamic.

Several of our apprentice developers were specifically chosen due to the unique perspective that they bring to the development processes.  Those individuals help bridge the player-developer gap as those new developers tend to come straight out of the player community and/or are heavily involved and familiar with the needs of our users.  They form a critical part of our technical support infrastructure.

Cumulatively, the #bzflag IRC channel provides even more insight, interaction, and mentoring support as our community spans several domains of software development expertise including game development, computer-aided design, computer-aided machining, software testing, web development, computer graphics development, systems and kernel development, and general application development.  As our channel is constantly (24/7) engaged in user and developer support to a global community, the channel will be our predominant means of interaction for all mentors and students.  Each individual listed can also dedicate a minimum of 10 hours a week on average with an understanding that there are additional demands on their time at the start, midterm, and final evaluation periods of the program.

= Has your group participated previously? If so, please summarize your involvement and any past successes and failures. =

Yes, we participated for the first time in 2007 and again in 2008.  We quickly found that being involved in GSoC requires considerable time and resources necessitating massive amounts of coordination, communication, and progress tracking.  Our developers spent many hours mentoring students, reviewing their code, and discussing implementation details.

We found that being involved in GSoC encouraged our community to become more organized and accountable than usual.  It also instigated other developer activity and interest throughout our community, particularly amongst players that were eagerly interested in trying out the new facilities being developed by the students.

The experience taught our mentors a great deal in terms of managing different personalities, expectations we had of their abilities to work with minimal process overhead, and how to respond quickly and effectively to inadequate levels of effort.  In our view, we did very well in managing our students but will need to dedicate even more time and attention to the students if we are allowed to participate again.  We intend to focus more on integrating the students quickly, engaging them more in the design and testing process throughout development, and making sure they follow our development criteria from start to finish so that we can help establish them as long-term developers in our community.

= What is your plan for dealing with disappearing contributors? = 

If a student's interest or availability to participate in the summer project seems to be diverging or otherwise waning, efforts will be made to motivate the student through discussions and hands-on interactive development intended to stimulate their progress.  Being a 3D graphics-oriented game, we have the benefit of most tasks actually resulting in something "fun" that rather easily captures and maintains interest.  However, should the student's focus still remain diminished or should the student unexpectedly disappear without notice, the administrator will relay this status with Google after repeated attempts to contact the student fail.

Also, as a learned measure from last year, the students are going to be required to make very frequent commits.  If they're not committing, then they are not working.  At least they won't be working effectively.  Having them commit frequently gives us a very good estimate of their activity level as well as where they are in the development process.  We strongly adhere to "commit early, commit often".

If the student is not around or is not working as much as they need to be, we will have discussions with them, see what's going on, and do so proactively.  We learned from one of our students last year when they were in serious danger of failing that a simple change in their accountability can have a massive impact on their motivation.  We will strive to recognize our students' personalities quickly, so that we can impose as much or as little process overhead as it required for them to be effective developers.  Additional process requirements (such as daily or weekly reports and commit quotas) may then be imposed for students that consistently fall behind schedule.

Similarly, by interacting with the students on a daily basis and preferably by having them be joined to our IRC channel while they are working on BZFlag, it allows mentors to keep a careful eye on all student progress and readily discuss issues with them.  As is done for any developer, having them be readily available for interactive discussion on IRC frequently helps avoid misunderstandings, disagreements, and frustrations and at worst makes any issues apparent as soon as possible.  The IRC channel is the hub of our primary development activity providing source commit announcements, developer access, user insight, interactive discussions, and near immediate response to questions and comments.

Other than that, the formula for dealing with disappearing students really just boils down to communication.  It's a very organic process and we don't believe that there is one answer for all students.  The measures described above help us focus on having the most effective communication that works with our development team but will necessarily be tailored to each student individually.  Issues that we cannot resolve will be brought forward to Google for guidance, as was done last year.

= What is your plan for dealing with disappearing members? = 

BZFlag contains an active community that is constantly engaged in providing assistance for any level of questions whether they are introductory user support questions or technical source code development questions.  The predominance of BZFlag's active software development interactions are discussed *entirely* on the #bzflag Freenode IRC channel.  We require that developers participate and interact on the IRC channel with other developers to their fullest capacity, and preferably without them relying on any single individual so that they may receive assistance and perspective from a variety of developers (it's not like all our developers always agree and, ultimately, our meritocracy prevails over decisions and directions).

One of the main reasons for requiring developers to be on the IRC channel is to help mitigate issues whereby a student might encounter difficulties interacting with any particular individual.  It also exposes them to all developers so that they can become more quickly in-tune with which developers are presently active and the politics of our development practices.

The students will be encouraged to interact on the IRC channel at all times to provide a continued on-going dialog with the other BZFlag developers as well so that everyone is informed of progress and development directions.  If a given mentor is not responding to the student, whether intentional or incapable, or if a mentor is unreachable for more than a couple days, one of several backup mentors are available to step in.

Should some situation arise that prevents a mentor from being able to participate, several backup mentors are available that can be assigned to the student on the spot and immediately pick up where other mentors leave off.  Several of our mentors and administrators also know each other in person and have physical access to one another, so we can go smack them if they're not participating effectively or should they try to disappear online.  That said, all mentors are selected based on their activity this year to help minimize any issues.

This year, we have also set up a mentor's blog to help our mentors make announcements more effectively and to provide suggestions for other GSoC projects.  This blog has already shown to be rather effective in making GSoC-specific announcements and for coordinating information amongst the mentors.  Once the students get started with their projects, we also plan to use the blog as a centralized information resource for developers to see the latest commits from the students and the status of their project progress.

= What steps will you take to encourage contributors to interact with your community before, during, and after the program? =

Being a game, i.e. an entertainment application, we have a somewhat unique benefit of actually being enjoyable before, during, and after the student's participation in the program and are even often "addictive".  Most people enjoy playing BZFlag and often after they play the game for a little while, they can "get hooked" on the game.  "Quick to learn, difficult to master" is our motto and this holds true both in the game and for development.  Once new developers see the impact they're having on such a large user community, they quickly become addicted to the development aspects and making things more enjoyable for our players.  We encourage our developers to play so that they understand the needs of the game and the needs of the existing player community in addition to becoming familiar with how various portions of the source code relate to behaviors in the game.

For student applicants we have a specific checklist of tasks to help them prepare to engage in routine development.  These steps include introducing themselves to our IRC channel, having a SourceForge account, becoming familiar with Subversion if they are not already, checking out the BZFlag sources, compiling their own version of BZFlag, playing the game with that version, registering with our global account services, becoming familiar with our websites and on-line services, and publishing their list of goals milestones for the community to see. 

As our IRC infrastructure and developer operations are already well established, we can (and frequently do) readily point new developer interests to our documentation and engage them in discussion.  We have lots of existing documentation, web infrastructure, and network resources available to quickly get new developers familiar and interested in development directions.  Thanks to our previous involvement with GSoC, we have an established mindset of successful interaction criteria that gets students quickly involved in our user community so that they feel like part of the family.

One of the interactions that worked very well in 2007 was having the students directly interact with the users, letting them represent their efforts, and having their efforts be strongly supported and promoted by the other developers.  We intend to take additional steps this year to continuously integrate the students' code throughout the program and work on introducing our player community to the features being developed even more early on.  The goal will be to instill a sense of belonging and a sense of appreciation for the hard work they put into their code.

= What will you do to ensure that your accepted contributors stick with the project after the program concludes? =

It is our responsibility to not neglect or abandon the students.  We have to give them the time and attention that they deserve, and we need to share with the students the respect and appreciation we have of their efforts so that they remain interested and involved.  BZFlag is fortunate to have not had any significant issues with attrition; many of our developers tend to remain involved with the project for a long time.  There is natural turn-over as interests shift and general fluctuations from year to year, but we sustain a relatively stable development rate and that is in no small part due to our interactive and friendly development environment.

New developers are often enticed to stick around and contribute simply because we actively promote their changes to the user community when releases are made, and the user community responds vocally to just about every single modification that gets made to the game no matter how small.  For the topics that we are soliciting ideas, the efforts of the student have the ability to make a major impact on the game that will be exceedingly visible, and will encourage continued development not only by the student but other developers as well.  We will necessarily encourage students to remain involved with the project by welcoming them to our development team, integrating them as quickly as possible, giving them development responsibilities, and showing them the rewards and impact of their efforts.

It's our job to encourage their passion for BZFlag development long after GSoC concludes.