Editing Summer of Code/Expectations

From BRL-CAD

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 1: Line 1:
Covered below in detail are the expectations for Summer of Code students that are accepted to participate.  In addition to the [[Summer_of_Code/Acceptance|acceptance criteria]] that all students are required to abide by, there are participation and behavior expectations.
+
Covered below in detail are the expectations for Google Summer of Code (GSoC) students that are accepted to participate.  In addition to the [[Google_Summer_of_Code/Acceptance|acceptance criteria]] that all students are required to abide by, there are participation and behavior expectations.
  
The program timeframe is ''very'' short.  There's not much time to get up to speed, so there is a need to be clear of what is expected.  Also, many students haven't done a lot of real-world development work previously.  On top of that, most mentors and students are in different locations so coordinated interaction can be difficult at times.  Because of this, it's vitally important to the success of each student's project for all expectations to be specified and understood before students begin coding for the summer.  This should be the first step in a long series of frequent communication between student and their mentor(s).
+
The GSoC timeframe is very short.  There's not much time to get up to speed, so there is a need to be clear of what is expected.  Also, many students haven't done a lot of real-world development work previously.  On top of that, most mentors and students are in different locations so coordinated interaction can be difficult at times.  Because of this, it's vitally important to the success of each student's GSoC project for all expectations to be specified and understood before students begin coding for the summer.  This should be the first step in a long series of frequent communication between student and their mentor(s).
  
 
This document walks through various expectations for students and mentors, as well as addressing various ways to communicate effectively.
 
This document walks through various expectations for students and mentors, as well as addressing various ways to communicate effectively.
Line 8: Line 8:
 
= The Point =
 
= The Point =
  
One of the primary purposes of the program is to introduce students to real-world open source development where there are social, collaboration, and other pragmatic concerns in addition to technical implementation issues.  It is our goal to integrate all participants as full-fledged new developers on the project not just for the duration of summer but thereafter too.  The projects are a very important part of the program, but they're certainly not the most important part.  The point is to have new developers join in development.
+
One of the primary purposes of the program is to introduce students to real-world open source development where there are social, collaboration, and other pragmatic concerns in addition to technical implementation issues.  It is our goal to integrate all participants as full-fledged new developers on the project not just for the duration of summer but thereafter too.  The projects are a very important part of GSoC, but they're certainly not the most important part.  The point is to have new developers join in the project's development.
  
= Full-time effort =
+
= 40 hour work week =
  
Unless otherwise discussed, students are expected to work about 40 hours a week on their project. This is essentially a full-time job.  If students can't work this much or if there are periods of time when a student will be away on vacation, then that needs to be discussed beforehand with the mentors or project administrator.  The mentors shouldn't have to hunt you down to keep tabs on your activity either (see Version control below).
+
Unless otherwise discussed, students are expected to work about 40 hours a week on their GSoC project. This is essentially a full-time job.  If students can't work this much or if there are periods of time when a student will be away on vacation, then that needs to be discussed beforehand with the mentors or project administrator.  The mentors shouldn't have to hunt you down to keep tabs on your activity either (see Version control below).  
  
 
= Self-motivation and steady schedule =
 
= Self-motivation and steady schedule =
Line 22: Line 22:
 
= Commit access =
 
= Commit access =
  
Students are treated like any other contributor to the project.  That means that in order to get commit access, students need to be actively involved and making small succinct patches at first and engender trust with the existing developers.  Once the student shows technical competency, demonstrates respect for the [http://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/HACKING developer guidelines], and is known to work well with the other developers, commit access will be granted.  ''This should happen before coding begins.''
+
Students are treated like any other contributor to the project.  That means that in order to get commit access, students need to be actively involved and making small succinct patches at first and engender trust with the existing developers.  Once the student shows technical competency, demonstrates respect for the [http://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/HACKING developer guidelines], and is known to work well with the other developers, commit access will be granted.  ''This should happen before GSoC coding begins.''
  
 
= Integrated development =
 
= Integrated development =
  
This means that students should be working closely with the other developers.  Particularly for new projects, students are expected to keep up-to-date and deal with the on-going developments of others (both good and bad) just like any other developer on the project and is conscious of making changes that might break protocol or compatibility.  You're not an outsider.  You're joining a team.
+
This also means that students should be working with the other developers on the mainline code, not on a branch.  There are very few situations that warrant isolated branch development.  Particularly for GSoC projects, the desired intent is integrated development where the student intentionally has to deal with the on-going developments of others (both good and bad) just like any other developer and is conscious of making changes that break protocol or compatibility.
  
 
= Version control =
 
= Version control =
Line 66: Line 66:
  
 
:Each commit should at least compile for the person that makes the commit.  New developers that break the build are used for target practice.
 
:Each commit should at least compile for the person that makes the commit.  New developers that break the build are used for target practice.
 +
  
 
= Frequent communication with mentor =
 
= Frequent communication with mentor =
Line 79: Line 80:
 
* what's blocking you if you're stuck
 
* what's blocking you if you're stuck
  
The mentor is one of the most valuable resources to students.  The mentors are generally already solid contributors with a long track record of involvement with the project.  The mentor likely has worked on the project for long enough to know the history of decisions, how things are architected, the other people involved, the process for doing things, and all other cultural lore that will help the student be most successful.  
+
The mentor is one of the most valuable resources for GSoC projects.  The mentor is generally already a solid contributor with a long track record of involvement with the project.  The mentor likely has worked on the project for long enough to know the history of decisions, how things are architected, the other people involved, the process for doing things, and all other cultural lore that will help the student be most successful.  
  
Before coding begins, the mentor and student should iron out answers to the following questions:
+
Before the GSoC project has started, the mentor and student should iron out answers to the following questions:
  
 
# What is the communication schedule? Daily? Every two days? Mondays, Wednesdays, Fridays?
 
# What is the communication schedule? Daily? Every two days? Mondays, Wednesdays, Fridays?
Line 113: Line 114:
 
* Mailing list
 
* Mailing list
  
:Many of the mentors may not be available on IRC due to differences in time zones or familiarity with IRC as a communication medium.  Students should get to know their mentor and if mailing list discussions are preferred, the students should also be interactive and visible on the developer mailing list.
+
:Many of the mentors may not be available on IRC due to differences in time zones or familiarity with IRC as a communication medium.  Students should get to know their mentor and if mailing list discussions are preferred, the students should also be interactive and visible on the developer mailing list.
 +
 
  
 
= Resolving problems =
 
= Resolving problems =
  
Student can call upon any mentor or other developer, they don't have to limit their interactions to just their mentor.  They shouldn't limit their interactions to just one mentor.  Students having difficulties communicating with any mentor should contact the [[User:Sean|administrator]].
+
Student can call upon any mentor or other developer, they don't have to limit their interactions to just their mentor.  They shouldn't limit their interactions to just one mentor.  Students having difficulties communicating with any mentor should contact the GSoC administrator for the project.
  
 
If you're stuck, ask for help on IRC and/or on the mailing list.  If you are still stuck, read the source code.  If you're still stuck, ask for help again.  Better questions frequently yield better answers.
 
If you're stuck, ask for help on IRC and/or on the mailing list.  If you are still stuck, read the source code.  If you're still stuck, ask for help again.  Better questions frequently yield better answers.
Line 123: Line 125:
 
= Design documents =
 
= Design documents =
  
It's a good idea for the student to maintain design documents during the course of development. These design documents should cover:
+
It's a good idea for the student to maintain design documents during the course of the GSoC project. These design documents should cover:
  
 
# the project plan, with additional detail to flesh out the original program application
 
# the project plan, with additional detail to flesh out the original program application
Line 131: Line 133:
 
# any resources used or relevant specifications
 
# any resources used or relevant specifications
  
The student and mentor should work out what design document(s) should be maintained during the course of the summer.  '''The design documents should be added to the wiki.'''
+
The student and mentor should work out what design document(s) should be maintained during the course of the GSoC.  '''The design documents should be added to the wiki.'''
  
 
-- Thanks --
 
-- Thanks --
Line 137: Line 139:
 
Thank you to each student for doing your best to follow through with these expectations.  Students should consult with any mentor if there are any questions or concerns regarding these expectations.
 
Thank you to each student for doing your best to follow through with these expectations.  Students should consult with any mentor if there are any questions or concerns regarding these expectations.
  
Many thanks to the Python foundation for their initial write-up document on participant expectations: http://wiki.python.org/moin/SummerOfCode/Expectations
+
Many thanks to the Python foundation for their initial write-up document on GSoC participant expectations: http://wiki.python.org/moin/SummerOfCode/Expectations
[[category:Summer of Code]]
 

Please note that all contributions to BRL-CAD may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see BRL-CAD:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)