1,079
edits
Difference between revisions of "Summer of Code/Application/2007"
Summer of Code/Application/2007 (view source)
Revision as of 17:06, 7 March 2007
, 17:06, 7 March 2007→How we will deal with participants 'missing in action'
| Line 67: | Line 67: | ||
For the mentors, the risk is relatively low; two are project leads and are virtually 24/7 reachable (in case of emergencies). We all have exchanged sufficient contact information (including cell phone numbers etc.) to be able to discover our whereabouts etc. Should something really bad happen (like somebodye ends up in hospital and hence can't work, a natural disaster, etc.), we will attempt to shift students to new mentors (among the existing mentors, or drawn from our backup pool of mentors). This will depend on the number of students we have to mentor. | For the mentors, the risk is relatively low; two are project leads and are virtually 24/7 reachable (in case of emergencies). We all have exchanged sufficient contact information (including cell phone numbers etc.) to be able to discover our whereabouts etc. Should something really bad happen (like somebodye ends up in hospital and hence can't work, a natural disaster, etc.), we will attempt to shift students to new mentors (among the existing mentors, or drawn from our backup pool of mentors). This will depend on the number of students we have to mentor. | ||
As for the students, for starters we plan to exchange as much communication data as possible (cell phone numbers, postal addresses etc.). Through a friendly atmosphere we hope to minimize the risk of any student being "afraid" to report problems they might have etc.. On the other hand, we will make it clear that we expect dedicated work of the students and that unannounced/unjustified disappearances will draw consequences, like negative reports or even the failure of the whole project. | As for the students, for starters we plan to exchange as much communication data as possible (cell phone numbers, postal addresses etc.). Through a friendly atmosphere we hope to minimize the risk of any student being "afraid" to report problems they might have etc.. On the other hand, we will make it clear that we expect dedicated work of the students and that unannounced/unjustified disappearances will draw consequences, like negative reports or even the failure of the whole project. Still, establishing a positive and friendly connection between student and mentor will be the cornerstone of our efforts in this regard. If the students trusts the mentor and tells him about his fear, uncertainities and problems early on, they can try to find a solution together, possibly with the help of the rest of the team. | ||
A common cause (we believe, based on our own experiences as students *g*) is a lack of structure in the assigned work, resp. an inability of the student to make real progress. To avoid this, we will request that students come up with a (realistic) project plan / schedule. The mentors will watch the progress with the students and discuss it with them regularly (at least weekly). We hope to detect potential problems early this way, thus being able to help the students get around them, to the benefit of all. If | A common cause (we believe, based on our own experiences as students *g*) is a lack of structure in the assigned work, resp. an inability of the student to make real progress. To avoid this, we will request that students come up with a (realistic) project plan / schedule. The mentors will watch the progress with the students and discuss it with them regularly (at least weekly). We hope to detect potential problems early on this way, thus being able to help the students get around them, to the benefit of all. | ||
If all fails, though, and a student really vanishes completly, we will have to deal with the consequences, just like with regular projects in a company. Projects *can* fail, after all, no matter how hard you try to avoid it. | |||
=== Integrating students with the community === | === Integrating students with the community === | ||