Google Summer of Code: Acceptance - Revision history

Zehra: Zehra moved page Google Summer of Code Acceptance to Google Summer of Code: Acceptance: let's standardize the pages a bit with '''Google Summer of Code:''' as prefix

2025-12-07T01:10:55Z

Zehra moved page Google Summer of Code Acceptance to Google Summer of Code: Acceptance: let's standardize the pages a bit with '''Google Summer of Code:''' as prefix

← Older revision		Revision as of 01:10, 7 December 2025
(No difference)

DTRemenak: /* Make a patch */ sure, we'll take more than one patch if you want, but quality > quantity

2009-04-02T05:45:20Z

Make a patch: sure, we'll take more than one patch if you want, but quality > quantity

← Older revision		Revision as of 05:45, 2 April 2009
Line 8:		Line 8:
	Don't fret. The patch can be almost anything just so long as it is can be applied to the BZFlag sources with very minimal hassle. It should be something actually useful. The patch should ''not'' just be whitespace, indent, or style changes as we automate those periodically. It ''should'' be a functional patch such as fixing a known bug (see our BUGS file or sf bug tracker) or implementing some very minor uncontroversial feature (see our TODO file). Bug fixes are generally the preferred scope but even something as trivial as fixing typos can make an acceptable patch. This is one of several opportunities to impress us, so feel free to be creative.		Don't fret. The patch can be almost anything just so long as it is can be applied to the BZFlag sources with very minimal hassle. It should be something actually useful. The patch should ''not'' just be whitespace, indent, or style changes as we automate those periodically. It ''should'' be a functional patch such as fixing a known bug (see our BUGS file or sf bug tracker) or implementing some very minor uncontroversial feature (see our TODO file). Bug fixes are generally the preferred scope but even something as trivial as fixing typos can make an acceptable patch. This is one of several opportunities to impress us, so feel free to be creative.

	Be sure to include a link to the Sourceforge patch tracker item in your application.		You are welcome to submit more than one patch if you like. We will review any you submit, but we only require and expect one; remember that quality is far more important than quantity in our reviews.

			Be sure to include either a link to the Sourceforge patch tracker item or your Sourceforge username in your application.

	=== Play BZFlag with the mentors ===		=== Play BZFlag with the mentors ===

Learner: separate application preparation and participation sections

2008-03-22T05:10:41Z

separate application preparation and participation sections

← Older revision		Revision as of 05:10, 22 March 2008
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 requirements outlined below.		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~~ ==		== Application requirements ==

			=== Make a patch ===
			We want to make sure that you have rudimentary skills in compiling code, reading other people's code, and can even simply get BZFlag to compile. Prepare and submit a patch to our [http://sourceforge.net/tracker/?group_id=3248&atid=303248 Sourceforge patches tracker].

			Don't fret. The patch can be almost anything just so long as it is can be applied to the BZFlag sources with very minimal hassle. It should be something actually useful. The patch should ''not'' just be whitespace, indent, or style changes as we automate those periodically. It ''should'' be a functional patch such as fixing a known bug (see our BUGS file or sf bug tracker) or implementing some very minor uncontroversial feature (see our TODO file). Bug fixes are generally the preferred scope but even something as trivial as fixing typos can make an acceptable patch. This is one of several opportunities to impress us, so feel free to be creative.

			Be sure to include a link to the Sourceforge patch tracker item in your application.

			=== Play BZFlag with the mentors ===
			We will schedule several open gaming gatherings during the application process and ask that serious applicants come play a round of BZFlag with us. You should compile your own client using the latest BZFlag trunk sources (which is incompatible with the latest public release) when you come to the gaming session. We will work out available times to play with you after you've submitted an application.

			You should ''play the game'' from a binary you've built yourself before beginning any work. You should do this ''at least once'' before the gathering 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 once the summer coding begins. 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''.

			We'll be glad to help you the first time if you run into trouble. Talk to the developers.

			=== Come talk to us ===
			You '''''really''''' should be talking to the BZFlag developers long before submitting your application. Discuss your ideas with us on the IRC channel. Communication is a huge part of our evaluation criteria.

			== Participation requirements ==

	=== Assign copyright and license under the LGPL ===		=== Assign copyright and license under the LGPL ===
	Per the GSoC [http://code.google.com/support/bin/answer.py?answer=60328&topic=10728 FAQ], BZFlag requires that any work performed and provided while participating in BZFlag development will be in accordance with BZFlag's existing [http://bzflag.cvs.sourceforge.net/checkout/bzflag/bzflag/COPYING license] ('''LGPL''') and that full nonexclusive copyright will be assigned to Tim Riker, the project ~~maintainer and~~ copyright holder.		Per the GSoC [http://code.google.com/support/bin/answer.py?answer=60328&topic=10728 FAQ], BZFlag requires that any work performed and provided while participating in BZFlag development will be in accordance with BZFlag's existing [http://bzflag.cvs.sourceforge.net/checkout/bzflag/bzflag/COPYING license] ('''LGPL''') and that full nonexclusive copyright will be assigned to Tim Riker, the project copyright holder.

	=== Provide weekly progress reports ===		=== Provide weekly progress reports ===
Line 12:		Line 31:
	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 in your first progress report,''' that is, at the beginning of code development (before, on or very soon after May 28).		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 in your first progress report,''' that is, at the beginning of code development (before, on or very soon after May 28).

	=== ~~Join our~~ IRC ~~channel~~ ===		=== Be available via IRC ===
	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 via IRC is '''required'~~''.~~		All students will be expected to '''join the #bzflag IRC channel''' on irc.freenode.net while they are working. Students are expected to '''be on''' the channel so they can be responsive and available 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 via IRC is '''required'''.

	~~=== Compile and Play BZFlag ===~~
	You should ''play 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~~ ===		=== Create a Sourceforge account ===
	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]. Whether students work on a branch or on the mainline will vary depending on the student and the project.		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]. Whether students work on a branch or on the mainline will vary depending on the student and the project.

	=== Evaluate your performance ===		=== Evaluate your performance ===
Line 33:		Line 49:
	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. Plan your development approach accordingly. You should generally not "stub" code functionality (though 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.		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. Plan your development approach accordingly. You should generally not "stub" code functionality (though 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 Participation Checklist ==

	* Read and agree to the above requirements		* Read and agree to the above requirements
Line 40:		Line 56:
	* Be familiar with the basics of Subversion (aka SVN).		* Be familiar with the basics of Subversion (aka SVN).
	* Compile and run BZFlag from source		* Compile and run BZFlag from source
			* Prepare a patch
	** [http://my.bzflag.org/w/BZFlag_SVN Checkout sources] from SVN		** [http://my.bzflag.org/w/BZFlag_SVN Checkout sources] from SVN
	** Familiarize yourself with the basic [http://my.bzflag.org/w/BZFlag_Source source layout]		** Familiarize yourself with the basic [http://my.bzflag.org/w/BZFlag_Source source layout]
Line 51:		Line 68:
	** http://sf.net/projects/bzflag		** http://sf.net/projects/bzflag
	* Create a list of 3 to 10 milestones		* Create a list of 3 to 10 milestones
	* ~~Publish~~ your milestones		* Document your milestones
			* Submit your application
			** Include a link to your patch
			** Include your IRC handle

DTRemenak: /* List your milestones */ more like zeroth, i.e. before coding begins

2007-05-22T05:49:47Z

List your milestones: more like zeroth, i.e. before coding begins

← Older revision		Revision as of 05:49, 22 May 2007
Line 10:		Line 10:

	=== List your milestones ===		=== 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 in your first progress report'''.		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 in your first progress report,''' that is, at the beginning of code development (before, on or very soon after May 28).

	=== Join our IRC channel ===		=== Join our IRC channel ===

DTRemenak: /* Assign copyright and license under the LGPL */ copyright assignment is nonexclusive, e.g. contributor may relicense/reuse independently

2007-04-07T18:07:13Z

Assign copyright and license under the LGPL: copyright assignment is nonexclusive, e.g. contributor may relicense/reuse independently

← Older revision		Revision as of 18:07, 7 April 2007
Line 4:		Line 4:

	=== Assign copyright and license under the LGPL ===		=== Assign copyright and license under the LGPL ===
	Per the GSoC [http://code.google.com/support/bin/answer.py?answer=60328&topic=10728 FAQ], BZFlag requires that any work performed and provided while participating in BZFlag development will be in accordance with BZFlag's existing [http://bzflag.cvs.sourceforge.net/checkout/bzflag/bzflag/COPYING license] ('''LGPL''') and that copyright will be assigned to Tim Riker, the project maintainer and copyright holder.		Per the GSoC [http://code.google.com/support/bin/answer.py?answer=60328&topic=10728 FAQ], BZFlag requires that any work performed and provided while participating in BZFlag development will be in accordance with BZFlag's existing [http://bzflag.cvs.sourceforge.net/checkout/bzflag/bzflag/COPYING license] ('''LGPL''') and that full nonexclusive copyright will be assigned to Tim Riker, the project maintainer and copyright holder.

	=== Provide weekly progress reports ===		=== Provide weekly progress reports ===

Learner: /* Join our IRC channel */

2007-04-05T21:12:54Z

Join our IRC channel

← Older revision		Revision as of 21:12, 5 April 2007
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). Interaction via IRC is '''required'''.		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 via IRC is '''required'''.

	=== Compile and Play BZFlag ===		=== Compile and Play BZFlag ===

Learner: formatting cleanup, emphasis

2007-04-05T17:31:34Z

formatting cleanup, emphasis

Learner: evaluate your performance

2007-04-05T15:54:43Z

evaluate your performance

← Older revision		Revision as of 15:54, 5 April 2007
Line 21:		Line 21:
	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].		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].

			=== Evaluate your performance ===
			Particularly for projects that interact with the client or server run-loop or affect networking (but also for others), '''quantitatively evaluate your performance''' and the impact your modifications will make. Don't prematurely optimize and don't over-architect, but also don't make guesses or assumptions either. Use a performance profiler, test your code, add temporary debug timers, have a peer review your approach, etc. Modifications to the game client and network code that detrimentally impact performance in non-optional ways will likely be rejected outright.

	=== Write maintainable code ===		=== 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 [http://bzflag.cvs.sourceforge.net/checkout/bzflag/bzflag/DEVINFO existing] developer guidelines and code conventions.		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.

Learner: write portable code

2007-04-05T15:46:27Z

write portable code

← Older revision		Revision as of 15:46, 5 April 2007
Line 23:		Line 23:
	=== Write maintainable code ===		=== 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 [http://bzflag.cvs.sourceforge.net/checkout/bzflag/bzflag/DEVINFO existing] developer guidelines and code conventions.		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 portable code ===
			BZFlag has an extensive heritage of being as portable as reasonably possible with effort continually being taken to make sure the entire codebase works on a vareity of compilation and run-time environments. While each developer's perception of what is ''reasonable'' certainly fluctuates over the years and from developer to developer, the general intention is that code written for BZFlag should function the same on most moderately popular operating system environments as much as possible including Linux, Mac OS X, and Windows as well as other platforms. It is each developer's responsibility to either make sure their code isn't platform-specific or that equivalent functionality is provided on other maintained platforms. You are expected to interact with other developers when portability issues are raised to resolve any problems. Portability of any dependencies being used must similarly be taken into account and relates to the aforementioned maintainability requirement.

	=== Write complete code ===		=== Write complete code ===

Learner: svn basics, maintainable and complete code

2007-04-03T18:18:30Z

svn basics, maintainable and complete code

← Older revision		Revision as of 18:18, 3 April 2007
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

← Older revision		Revision as of 17:31, 5 April 2007
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 requirements outlined below.		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 ==

	=== Assign copyright and license under the LGPL ===		=== Assign copyright and license under the LGPL ===
	Per the GSoC [http://code.google.com/support/bin/answer.py?answer=60328&topic=10728 FAQ], BZFlag requires that any work performed and provided while participating in BZFlag development will be in accordance with BZFlag's existing [http://bzflag.cvs.sourceforge.net/checkout/bzflag/bzflag/COPYING license] and that copyright will be assigned to the project maintainer and copyright holder~~, Tim Riker~~.		Per the GSoC [http://code.google.com/support/bin/answer.py?answer=60328&topic=10728 FAQ], BZFlag requires that any work performed and provided while participating in BZFlag development will be in accordance with BZFlag's existing [http://bzflag.cvs.sourceforge.net/checkout/bzflag/bzflag/COPYING license] ('''LGPL''') and that copyright will be assigned to Tim Riker, the project maintainer and copyright holder.

	=== Provide weekly progress reports ===		=== 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.		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 similar details on your activities. You will be expected to complete a report every week, at least once a week. More information on the exact method for providing these reports will be provided after the projects commence.

	=== List your milestones ===		=== 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.		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 in your first progress report'''.

	=== 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). Interaction is '''required'''.		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 via IRC 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 ''play 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 ===		=== 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].		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]. Whether students work on a branch or on the mainline will vary depending on the student and the project.

	=== Evaluate your performance ===		=== Evaluate your performance ===
Line 25:		Line 25:

	=== Write maintainable code ===		=== 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 [http://bzflag.cvs.sourceforge.net/checkout/bzflag/bzflag/DEVINFO existing] developer guidelines and ~~code~~ conventions.		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 comprehensive and comprehensible? Well-documented? Organized? You are required to follow BZFlag's [http://bzflag.cvs.sourceforge.net/checkout/bzflag/bzflag/DEVINFO existing] developer guidelines, existing code style, and established conventions.

	=== Write portable code ===		=== Write portable code ===
	BZFlag has an extensive heritage of being as portable as reasonably possible with effort continually being taken to make sure the entire codebase works on a vareity of compilation and run-time environments. While each developer's perception of what is ''reasonable'' certainly fluctuates over the years and from developer to developer, the general intention is that code written for BZFlag should function the same on most moderately popular operating system environments as much as possible including Linux, Mac OS X, and Windows as well as other platforms. It is each developer's responsibility to either make sure their code isn't platform-specific or that equivalent functionality is provided on other maintained platforms. You are expected to interact with other developers when portability issues are raised to resolve any problems. Portability of any dependencies being used must similarly be taken into account and relates to the aforementioned maintainability requirement.		BZFlag has an extensive heritage of being as portable as reasonably possible with effort continually being taken to make sure the entire codebase works on a vareity of compilation and run-time environments. While each developer's perception of what is ''reasonable'' certainly fluctuates over the years and from developer to developer, the general intention is that code written for BZFlag should function the '''same''' on most moderately popular operating system environments as much as possible including Linux, Mac OS X, and Windows as well as other platforms. It is each developer's responsibility to either make sure their code isn't platform-specific or that equivalent functionality is provided on other maintained platforms. You are expected to interact with other developers when portability issues are raised to resolve any problems. Portability of any dependencies being used must similarly be taken into account and relates to the aforementioned maintainability requirement.

	=== Write complete code ===		=== 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.		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. Plan your development approach accordingly. You should generally not "stub" code functionality (though 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 ==