178
edits
Difference between revisions of "Summer of Code/Application/2007"
Jump to navigation
Jump to search
m
Summer of Code/Application/2007 (view source)
Revision as of 18:07, 7 March 2007
, 18:07, 7 March 2007typos
m (typos) |
|||
| Line 1: | Line 1: | ||
== Introduction & overview == | == Introduction & overview == | ||
This is the application of the [http://www.scummvm.org ScummVM] project for the [http://code.google.com/soc Google Summer of Code]. Let's start with a quick | This is the application of the [http://www.scummvm.org ScummVM] project for the [http://code.google.com/soc Google Summer of Code]. Let's start with a quick overview of the facts before turning to the more elaborate parts of this document | ||
{| cellpadding="3" | {| cellpadding="3" | ||
| Line 41: | Line 41: | ||
The structure of the team reflects this structure, in so far as developers can be roughly grouped into the following categories (with some people being in more than one, or being multiple times in a single category): | The structure of the team reflects this structure, in so far as developers can be roughly grouped into the following categories (with some people being in more than one, or being multiple times in a single category): | ||
* Porters -- responsible for a specific port | * Porters -- responsible for a specific port | ||
* Engine authors -- responsible for a specific game engine (includes being | * Engine authors -- responsible for a specific game engine (includes being responsible for handling users bug reports, i.e. support) | ||
* Infrastructure development -- e.g. people working on MIDI code, on the built-in custom GUI, etc. | * Infrastructure development -- e.g. people working on MIDI code, on the built-in custom GUI, etc. | ||
* Packagers -- not all ports require dedicated backends (e.g. we have on built around the SDL library, which itself is highly portable), but they still require somebody to test and compile them, which is where porters come in | * Packagers -- not all ports require dedicated backends (e.g. we have on built around the SDL library, which itself is highly portable), but they still require somebody to test and compile them, which is where porters come in | ||
| Line 63: | Line 63: | ||
We hope that nobody will disappear, but we plan to take a proactive approach, i.e. we will try to minimize the risk of a loss of communication; but if it happens, we are prepared to deal with it, too. | We hope that nobody will disappear, but we plan to take a proactive approach, i.e. we will try to minimize the risk of a loss of communication; but if it happens, we are prepared to deal with it, too. | ||
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 | 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 somebody ending up in hospital and hence unable to 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. 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, | 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, uncertainties and problems early on, they can try to find a solution together, possibly with the help of the rest of the team. Also, integrating the students into our community should reduce the likelihood of disappearances further (see also the next section). | ||
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. | 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 | If all fails, though, and a student really vanishes completely, 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 == | ||
Our community uses forums, IRC, Wiki and our mailing list for a vivid exchange of thoughts all the time. We will urge the students to participate in all of them; | Our community uses forums, IRC, Wiki and our mailing list for a vivid exchange of thoughts all the time. We will urge the students to participate in all of them; especially on IRC can they directly talk to many nice and helpful team and community members. The mentors will introduce the students to the rest of the team (making sure everybody knows who the students are). There are people active in the IRC channel virtually 24/7, thanks to the international nature of the project. | ||
We also expect the students to talk to non-mentor team members on a regular basis about parts of ScummVM for which these team members are experts (at least if these parts happen to be relevant for the student's project). To achieve that, the mentors will specifically introduce them to each other, and will try to incite them to work together. | We also expect the students to talk to non-mentor team members on a regular basis about parts of ScummVM for which these team members are experts (at least if these parts happen to be relevant for the student's project). To achieve that, the mentors will specifically introduce them to each other, and will try to incite them to work together. | ||