Difference between revisions of "Summer of Code/Acceptance"

From BRL-CAD
(Join our IRC channel and mailing list)
(Make a patch)
(16 intermediate revisions by 4 users not shown)
Line 1: Line 1:
This page is intended to lay out the basic "'''rules and requirements'''" that the BRL-CAD project is going to require of all [[Google Summer of Code]] participants whose project proposals are accepted.  Unless otherwise arranged with the BRL-CAD GSoC project 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 our organization requires of all Summer of Code (whether [[Google Summer of Code|GSoC]] or [[ESA Summer of Code in Space|SOCIS]]) participants whose project proposals are accepted.  Unless otherwise arranged with the organization administrator (contact 'brlcad' via IRC on irc.freenode.net), it will be expected that all students will comply with the requirements outlined below.
  
= Application Requirements =
+
=Application Recommendations=
  
 
== Make a patch ==
 
== Make a patch ==
  
Strictly speaking, this is an '''''optional''''' step to the application process.  It will, however, greatly increase you chances of being selected all else being equal if you provide a patch, however trivial, with your application.
+
While this is '''''optional''''', it greatly increase your chances of being selected.  Basically, a patch is some change to the software (submitted wither as a patch file or a pull request).  If working with us is your top priority, a patch will help us see how well you are at dealing with other people's code. Don't worry, though. It doesn't need to be more than a few lines.  It can be a bug fix or implement some minor feature. It's more important that it applies without hassle and provides some improvement. This is one of several opportunities to impress, so be creative.  Link to any patches in your application.
 
 
We want to make sure that you have rudimentary skills in compiling code, reading other people's code, and can even simply get BRL-CAD to compile. Prepare and submit a patch to our [http://sourceforge.net/tracker/?func=add&group_id=105292&atid=640804 Sourceforge patches tracker].
 
 
 
Don't worry. The patch can be just about anything and doesn't need to be more than a couple lines.  Making any trivial patch will be good enough so long as it is can be applied to the BRL-CAD sources with very minimal hassle.
 
 
 
The patch ''should'' be something actually useful. The patch should not just be whitespace, indent, or style changes as those are automated periodically. It should be a functional patch such as fixing a known bug (see our [http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/BUGS BUGS] file or [http://sourceforge.net/tracker/?group_id=105292&atid=640802 sf bug tracker]) or implementing some very minor uncontroversial feature (see our [http://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/TODO TODO] file). Bug fixes are generally the preferred scope but even something as trivial as fixing typos or improving a usage statement for an existing command 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 will need a Sourceforge account in order to post the patch to the tracker.
 
  
 
== Come talk to us ==
 
== Come talk to us ==
You '''''really''''' should be talking to the BRL-CAD developers long before submitting your application. Discuss your ideas with us on the [http://irc.brlcad.org #brlcad IRC channel] or on the [https://lists.sourceforge.net/lists/listinfo/brlcad-devel brlcad-devel mailing list]. Communication is a huge part of our evaluation criteria.
+
You '''''really''''' should be talking to developers long before you submit an application. Discuss your ideas via IRC and e-mail (mailing list). Communication is a huge part of our evaluation criteria.
  
We're looking for long-term develepers so we need to be able to know that we can interact and communicate easily with you.
+
== Maintain a dev log ==
 +
It's strongly recommended that you maintain a public development log that is updated every day you work.  Most students don't have a habit of discussing their work adequately and this intrinsically documents progress.  Communication ftw. Dev logs are also a great way to let people in the community follow your project and provides a place to showcase cool highlights!
  
= Participation Requirements =
+
=Participation Requirements=
  
== Assign copyright and license under the LGPL ==
+
== License appropriately ==
In addition to abiding by all the BRL-CAD  [http://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/HACKING HACKING] rules, per the GSoC [http://code.google.com/support/bin/answer.py?answer=60328&topic=10728 FAQ] participation with BRL-CAD requires that any work performed and provided be in accordance with BRL-CAD's existing [http://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/COPYING license] ('''LGPL''') and that full nonexclusive copyright will be assigned.
+
Participation requires that any work performed will be provided in good faith and consistent with contributor requirements. Unless approved in advance in writing, all rights (copyright) will be '''assigned''' to the organization.  If your country does not allow assignment of copyright, non-exclusive rights to use the code in perpetuity will be required.  You will be credited for your work regardless.
  
== Provide weekly progress reports ==
+
== Report activity daily ==
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 activitiesYou 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.
+
In addition to your ongoing discussions, it is required to regularly ''submit a progress report'' of '''daily''' activity.  These reports usually won't need to be more than a sentence or two but they should provide clear concise information on what you did, things you discovered, tasks completed, difficulties encountered, milestones reached, days off, and other similar details.  If you did nothing, that's okay!  We want to know when you're concentrating on code, at the beach, and everything in between.
  
 
== 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,''' that is, at the beginning of code development.
+
Everyone is required to submit a '''minimum''' of three and a maximum of ten project ''milestones''.  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 progress.  These milestones should be '''published in your first progress report,''' that is, at the beginning of coding.
  
== Join our IRC channel and mailing list ==
+
== Be communicative ==
All students will be expected to be '''''on''''' the #brlcad IRC channel while they are working and actively engaged on the mailing list so they can be responsive and available for questions, comments, and suggestions from other BRL-CAD developers.
+
All students will be expected to be reachable via IRC and e-mail while they are working.  Participants must be responsive, actively engaged in discussions, and available for questions, comments, and suggestions from other developers.  See [http://irchelp.org here] if you are new to IRC and need help.
  
Much of BRL-CAD's open source development occurs over IRC as it is the central gathering forum for core development activities, developer discussions, commit notifications, and more.  That said, several mentors will be more readily reached via the mailing list too so the student will be expected to interact on both as needed.
+
=Coding Requirements=
  
See [http://irchelp.org here] if you are new to IRC and need assistance finding a client (or just do a search)If you've never subscribed to a mailing list before and actually need help, you might not want to apply.
+
== Compile and run ==
 +
Being able to compile and run on your own hardware is a very ''basic task'' that is considered essential. We're more than happy to help you get started the first time if you run into a problem, but you are expected to put forth duly diligent effortAdditionally, understanding the existing user community is '''very important''' for most developers to have at least a basic familiarity.  In the end, your changes will (hopefully) be pushed out to the community and you should be cognizant of what that will ''mean''.
  
== Compile and run BRL-CAD ==
+
== Be familiar with revision control ==
Being able to compile the sources on your own equipment is a very ''basic task'' that is generally considered beyond the scope of GSoC and, as such, will be an expected unassisted capacity of all studentsWe're more than happy to help you get started the first time if you run into a problem, but you are expected to put forth due diligence effort.
+
You will be expected to abide by the same coding requirements of other developersYou must know the basics for how to work with the project's revision control system including checking out/in changes, resolving conflicts, and creating patches.  Whether you work on a branch or on the mainline trunk will depend on the project.
  
Additionally, understanding the existing user community is '''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''.
+
== Evaluate performance ==
 
+
Performance is something we always strive to keep in mind. '''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 debug timers, and/or have a peer review your work.
== Be familiar with the basics of Subversion ==
 
BRL-CAD 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 BRL-CAD's sourceforge [http://sf.net/projects/brlcad/ account].  Whether students work on a branch or on the mainline will vary depending on the student and the project.
 
 
 
== Evaluate your performance ==
 
As performance is something we always strive to keep in mind, '''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 code that detrimentally impact performance 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 BRL-CAD 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 BRL-CAD's [http://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/HACKING existing] developer guidelines, existing code style, and established conventions.
+
This requirement cannot be stressed enough.  How maintainable is your end result.  This is not only maintainability from the stand-point of source code longevity, but involves other higher-level aspects.  Does your implementation use interfaces, languages, tools, or techniques that introduce some new development requirement?  If so, that choice needs to be discussed and '''justified''' or otherwise mitigated.  Any new external dependencies need to be approved by the core developers.  Is your code comprehensive and comprehensible?  Well-documented?  Organized?  You are required to follow existing dev guidelines, code style, and established conventions.
  
 
== Write portable code ==
 
== Write portable code ==
BRL-CAD 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 BRL-CAD 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.
+
We appreciate code being as portable as possible with effort continually taken to make sure code works on a variety of 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 should function the '''same''' on most moderately popular operating system environments.  It is each dev's responsibility to either make sure their code isn't platform-specific or that equivalent functionality is implemented for other maintained platforms.  You are expected to interact with other devs when portability issues are raised and to promptly 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.  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 Participation Checklist =
+
[[Category: Summer of Code]]
 
 
* Read and agree to the above requirements
 
* Join the #brlcad IRC channel and introduce yourself
 
* Join the brlcad-devel mailing list and introduce yourself
 
* Familiarize yourself with Subversion
 
* Compile and run BRL-CAD from source
 
* Create a Sourceforge account
 
* Post a patch
 
* Familiarize yourself with BRL-CAD's on-line websites, documentation, and services
 
** http://brlcad.org
 
** http://brlcad.org/wiki
 
** http://brlcad.org/gallery
 
** http://brlcad.org/d/documentation
 
** http://sf.net/projects/brlcad
 
* Create a list of 3 to 10 milestones
 
* Document your milestones
 
* Submit your application
 
** Include a link to your patch
 
** Include your IRC nickname
 
* Familiarize yourself with BRL-CAD
 
* Get to work!
 

Revision as of 15:49, 12 March 2014

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

Application Recommendations

Make a patch

While this is optional, it greatly increase your chances of being selected. Basically, a patch is some change to the software (submitted wither as a patch file or a pull request). If working with us is your top priority, a patch will help us see how well you are at dealing with other people's code. Don't worry, though. It doesn't need to be more than a few lines. It can be a bug fix or implement some minor feature. It's more important that it applies without hassle and provides some improvement. This is one of several opportunities to impress, so be creative. Link to any patches in your application.

Come talk to us

You really should be talking to developers long before you submit an application. Discuss your ideas via IRC and e-mail (mailing list). Communication is a huge part of our evaluation criteria.

Maintain a dev log

It's strongly recommended that you maintain a public development log that is updated every day you work. Most students don't have a habit of discussing their work adequately and this intrinsically documents progress. Communication ftw. Dev logs are also a great way to let people in the community follow your project and provides a place to showcase cool highlights!

Participation Requirements

License appropriately

Participation requires that any work performed will be provided in good faith and consistent with contributor requirements. Unless approved in advance in writing, all rights (copyright) will be assigned to the organization. If your country does not allow assignment of copyright, non-exclusive rights to use the code in perpetuity will be required. You will be credited for your work regardless.

Report activity daily

In addition to your ongoing discussions, it is required to regularly submit a progress report of daily activity. These reports usually won't need to be more than a sentence or two but they should provide clear concise information on what you did, things you discovered, tasks completed, difficulties encountered, milestones reached, days off, and other similar details. If you did nothing, that's okay! We want to know when you're concentrating on code, at the beach, and everything in between.

List your milestones

Everyone is required to submit a minimum of three and a maximum of ten project milestones. 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 progress. These milestones should be published in your first progress report, that is, at the beginning of coding.

Be communicative

All students will be expected to be reachable via IRC and e-mail while they are working. Participants must be responsive, actively engaged in discussions, and available for questions, comments, and suggestions from other developers. See here if you are new to IRC and need help.

Coding Requirements

Compile and run

Being able to compile and run on your own hardware is a very basic task that is considered essential. We're more than happy to help you get started the first time if you run into a problem, but you are expected to put forth duly diligent effort. Additionally, understanding the existing user community is very important for most developers to have at least a basic familiarity. In the end, your changes will (hopefully) be pushed out to the community and you should be cognizant of what that will mean.

Be familiar with revision control

You will be expected to abide by the same coding requirements of other developers. You must know the basics for how to work with the project's revision control system including checking out/in changes, resolving conflicts, and creating patches. Whether you work on a branch or on the mainline trunk will depend on the project.

Evaluate performance

Performance is something we always strive to keep in mind. 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 debug timers, and/or have a peer review your work.

Write maintainable code

This requirement cannot be stressed enough. How maintainable is your end result. This is not only maintainability from the stand-point of source code longevity, but involves other higher-level aspects. Does your implementation use interfaces, languages, tools, or techniques that introduce some new development requirement? If so, that choice needs to be discussed and justified or otherwise mitigated. Any new external dependencies need to be approved by the core developers. Is your code comprehensive and comprehensible? Well-documented? Organized? You are required to follow existing dev guidelines, code style, and established conventions.

Write portable code

We appreciate code being as portable as possible with effort continually taken to make sure code works on a variety of 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 should function the same on most moderately popular operating system environments. It is each dev's responsibility to either make sure their code isn't platform-specific or that equivalent functionality is implemented for other maintained platforms. You are expected to interact with other devs when portability issues are raised and to promptly 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

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.