This wiki is archived and useful information is being migrated to the main bzflag.org website

Difference between revisions of "Google Summer of Code Acceptance"

From BZFlagWiki
Jump to: navigation, search
m (Protected "Google Summer of Code Acceptance": GSoC obligations page not intended for public editing as students are required to agree to the terms listed as defined by the GSoC administrator only [edit=autoconfirmed:move=autoconfirmed])
(svn basics, maintainable and complete code)
Line 1: Line 1:
This page is intended to lay out the basic "rules and requirements" that the BZFlag project is going to require of all [[Google Summer of Code]] students whose project proposals are accepted.  Unless otherwise arranged with the BZFlag GSoC administrator (contact brlcad via IRC on irc.freenode.net), it will be expected that all students comply with the following:
+
This page is intended to lay out the basic "rules and requirements" that the BZFlag project is going to require of all [[Google Summer of Code]] students whose project proposals are accepted.  Unless otherwise arranged with the BZFlag GSoC administrator (contact brlcad via IRC on irc.freenode.net), it will be expected that all students comply with the requirements outlined below.
  
 
== Requirements ==
 
== Requirements ==
Line 13: Line 13:
  
 
=== Join our IRC channel ===
 
=== Join our IRC channel ===
All students will be expected to join the #bzflag IRC channel on irc.freenode.net.  Students are expected to '''be on''' the channel while they are working and be responsive to the questions, inquiries, and suggestions of other BZFlag developers.  BZFlag development occurs entirely over IRC as it is the central gathering forum for core development activities, developer discussions, and more.  See [http://irchelp.org here] if you are new to IRC and need assistance finding a client (or just do a search).
+
All students will be expected to join the #bzflag IRC channel on irc.freenode.net.  Students are expected to '''be on''' the channel while they are working and be responsive to the questions, inquiries, and suggestions of other BZFlag developers.  BZFlag development occurs entirely over IRC as it is the central gathering forum for core development activities, developer discussions, and more.  See [http://irchelp.org here] if you are new to IRC and need assistance finding a client (or just do a search).  Interaction is '''required'''.
  
 
=== Compile and Play BZFlag ===
 
=== Compile and Play BZFlag ===
 
You should have played the game from a binary you've built yourself before beginning any work.  You should do this ''at least once'' if not more if you are so inclined.  Being able to compile the sources on your own equipment is a very basic task that is beyond the scope of GSoC and will be an expected unassisted capacity of all students.  Additionally, understanding the existing player community, what they like and dislike, and seeing how they interact is all very important for most developers to have at least a '''basic''' familiarity with.  In the end, your changes will (hopefully) be pushed out to the community and you be cognizant of what that will mean.
 
You should have played the game from a binary you've built yourself before beginning any work.  You should do this ''at least once'' if not more if you are so inclined.  Being able to compile the sources on your own equipment is a very basic task that is beyond the scope of GSoC and will be an expected unassisted capacity of all students.  Additionally, understanding the existing player community, what they like and dislike, and seeing how they interact is all very important for most developers to have at least a '''basic''' familiarity with.  In the end, your changes will (hopefully) be pushed out to the community and you be cognizant of what that will mean.
 +
 +
=== Be familiar with the basics of Subversion ===
 +
BZFlag sources live in a Subversion repository on Sourceforge.  You will need a Sourceforge account and will be expected to abide by the same coding requirements of the other existing developers.  You will similarly be expected to know the basics of how to work with SVN and check in changes, resolve conflicts, and apply patches as needed.  SVN has a nearly identical interface to CVS -- if you're familiar with CVS, then you should be fine.  If you don't have a Sourceforge account, be sure to get one and familiarize yourself with BZFlag's sourceforge [http://sf.net/projects/bzflag/ account].
  
 
=== Write maintainable code ===
 
=== Write maintainable code ===
This cannot be stressed enough.
+
This requirement cannot be stressed enough.  One of the primary evaluation criteria for all students is how maintainable is the end result.  This is not only maintainability from the stand-point of source code longevity as it stands written, but also involves other higher-level maintainability and integration aspects.  Does your implementation use interfaces, languages, tools, or techniques that introduce some new requirement to widespread BZFlag development?  If so, that choice needs to be discussed and justified or otherwise mitigated as a concern.  Any usage of external dependencies needs to be consensus approved by the core developers.  Is your code comprensive and comprehensible?  Well-documented?  Organized?  You should be following BZFlag's [http://bzflag.cvs.sourceforge.net/*checkout*/bzflag/bzflag/DEVINFO existing] developer guidelines and code conventions.
  
 +
=== Write complete code ===
 +
Perhaps treat each week like it is your last.  You should be able to hand over functional code over just about any time during development (within a day or so) to another developer.  Focus on completing tasks, completing code features, and working on keeping your code functional at '''all''' stages of development.  That way, no matter how far you get on your milestones or deliverable(s), other developers will be able to review, test, and readily integrate your code.  You should generally not "stub" code functionality (comments are good), but instead focus on coding "deep" instead of "wide".  It's generally preferred to have 2 features that work fully, than 5 features that half-work or even 20 features that are all 90% complete.
  
 
== Pre-Flight Checklist ==
 
== Pre-Flight Checklist ==
Line 33: Line 38:
 
** Compile
 
** Compile
 
** Play
 
** Play
 +
* Familiarize yourself with BZFlag's on-line websites and services
 +
** http://bzflag.org
 +
** http://my.bzflag.org
 +
** http://my.bzflag.org/bb/
 +
** http://my.bzflag.org/w/
 +
** http://sf.net/projects/bzflag
 
* Create a list of 3 to 10 milestones
 
* Create a list of 3 to 10 milestones
 
* Publish your milestones
 
* Publish your milestones

Revision as of 18:18, 3 April 2007

This page is intended to lay out the basic "rules and requirements" that the BZFlag project is going to require of all Google Summer of Code students whose project proposals are accepted. Unless otherwise arranged with the BZFlag GSoC administrator (contact brlcad via IRC on irc.freenode.net), it will be expected that all students comply with the requirements outlined below.

Requirements

Assign copyright and license under the LGPL

Per the GSoC FAQ, BZFlag requires that any work performed and provided while participating in BZFlag development will be in accordance with BZFlag's existing license and that copyright will be assigned to the project maintainer and copyright holder, Tim Riker.

Provide weekly progress reports

In addition to any communications you hold with a given mentor, the administrator, or any of the developers, it will be expected of all students that they will submit a brief progress report on a weekly basis. These reports won't need to be more than a few sentences (or at most a couple of paragraphs, whatever is appropriate) but the reports should give an indication of your overall progress, things you discover, tasks completed, difficulties encountered, milestones reached, and other details on your activities. There are twelve weeks of code, you will be expected to complete twelve reports. More information on the exact method for providing these reports will be provided after the projects commence.

List your milestones

All projects will be required to submit a minimum of three and a maximum of ten milestones for your project. These are not deliverables but, rather, are overall tasks that should be completed throughout the duration of your work. These should be necessary implementation steps and not include any research or familiarity phases. In the end, there is code that must be produced, and your milestones should be a (very) rough breakdown for estimating your actual implementation progress. These milestones should be published as your first progress report.

Join our IRC channel

All students will be expected to join the #bzflag IRC channel on irc.freenode.net. Students are expected to be on the channel while they are working and be responsive to the questions, inquiries, and suggestions of other BZFlag developers. BZFlag development occurs entirely over IRC as it is the central gathering forum for core development activities, developer discussions, and more. See here if you are new to IRC and need assistance finding a client (or just do a search). Interaction is required.

Compile and Play BZFlag

You should have played the game from a binary you've built yourself before beginning any work. You should do this at least once if not more if you are so inclined. Being able to compile the sources on your own equipment is a very basic task that is beyond the scope of GSoC and will be an expected unassisted capacity of all students. Additionally, understanding the existing player community, what they like and dislike, and seeing how they interact is all very important for most developers to have at least a basic familiarity with. In the end, your changes will (hopefully) be pushed out to the community and you be cognizant of what that will mean.

Be familiar with the basics of Subversion

BZFlag sources live in a Subversion repository on Sourceforge. You will need a Sourceforge account and will be expected to abide by the same coding requirements of the other existing developers. You will similarly be expected to know the basics of how to work with SVN and check in changes, resolve conflicts, and apply patches as needed. SVN has a nearly identical interface to CVS -- if you're familiar with CVS, then you should be fine. If you don't have a Sourceforge account, be sure to get one and familiarize yourself with BZFlag's sourceforge account.

Write maintainable code

This requirement cannot be stressed enough. One of the primary evaluation criteria for all students is how maintainable is the end result. This is not only maintainability from the stand-point of source code longevity as it stands written, but also involves other higher-level maintainability and integration aspects. Does your implementation use interfaces, languages, tools, or techniques that introduce some new requirement to widespread BZFlag development? If so, that choice needs to be discussed and justified or otherwise mitigated as a concern. Any usage of external dependencies needs to be consensus approved by the core developers. Is your code comprensive and comprehensible? Well-documented? Organized? You should be following BZFlag's existing developer guidelines and code conventions.

Write complete code

Perhaps treat each week like it is your last. You should be able to hand over functional code over just about any time during development (within a day or so) to another developer. Focus on completing tasks, completing code features, and working on keeping your code functional at all stages of development. That way, no matter how far you get on your milestones or deliverable(s), other developers will be able to review, test, and readily integrate your code. You should generally not "stub" code functionality (comments are good), but instead focus on coding "deep" instead of "wide". It's generally preferred to have 2 features that work fully, than 5 features that half-work or even 20 features that are all 90% complete.

Pre-Flight Checklist