Directors of Studies: Difference between revisions

From Computer Laboratory Group Design Projects
Jump to navigationJump to search
No edit summary
 
(One intermediate revision by the same user not shown)
Line 10: Line 10:
If a student does experience a problem with the group project, we strongly encourage them to inform us at the earliest opportunity in order to make alternative plans. If students are experiencing problems, but do not inform us, there is little we can do. Please do encourage them to let us know of any problems via the group-project email address. This address is received by the group project convenors, and by the staff of the student administration office.
If a student does experience a problem with the group project, we strongly encourage them to inform us at the earliest opportunity in order to make alternative plans. If students are experiencing problems, but do not inform us, there is little we can do. Please do encourage them to let us know of any problems via the group-project email address. This address is received by the group project convenors, and by the staff of the student administration office.


We also invite DoSes to contact us directly, if they are aware of any reason why a student might struggle with the project (for example, related to disability or illness, or a track record of problems in group work). We send a reminder to DoSes each year, before the teams are allocated, so that we can take individual issues into account when assigning students to teams. We are happy to receive any information from DoSes at this time, or at any other stage during the project.
We also invite DoSes to contact us in confidence, if they are aware of any reason why a student might struggle with the project (for example, related to disability or illness, or a track record of problems in group work). We send a reminder to DoSes each year, before the teams are allocated, so that we can take any issues into account. We are also happy to receive any information from DoSes at this time, or at any other stage during the project.


Our published intention is that we expect all students to gain all four ticks for the group projects. The most common cause of failure is serious illness or bereavement, and in these cases the DoS is usually well aware that the student is having trouble. Less commonly, students who were otherwise doing well in the Tripos have unexpectedly failed to earn group project ticks. Some potential failure modes that DoSes should be alert to include:
Our published intention is that we expect all students to gain all four ticks for the group projects. The most common cause of failure is serious illness or bereavement, and in these cases the DoS is usually well aware that the student is having trouble. Less commonly, students who were otherwise doing well in the Tripos have unexpectedly failed to earn group project ticks. Some potential failure modes that DoSes should be alert to include:
Line 20: Line 20:
3. A student does contribute to the code base, but only in the form of documentation, for example adding comments, writing README files, importing open source content, or making commit log entries that focus on descriptions of bugs and their possible causes rather than source code.
3. A student does contribute to the code base, but only in the form of documentation, for example adding comments, writing README files, importing open source content, or making commit log entries that focus on descriptions of bugs and their possible causes rather than source code.


4. A students delivers an initial version of the that was code assigned to them, but leaves it to other members of the team to resolve faults, rather than taking responsibility for design iteration, debugging and maintenance of their own work.
4. A student delivers an initial version of the code that was assigned to them, but leaves it to other members of the team to resolve faults, rather than taking responsibility for design iteration, debugging and maintenance of their own work.


Note that working in groups does involve substantial coordination and managerial overhead. We are aware that some members of each team will accept a disproportionate burden in such work, especially if elected as the official group contact or project manager. We do not penalise students for such work (on the contrary, the responsibilities they take often lead to the most valuable professional development and learning outcomes). However, we do require every student to make a substantive technical contribution to the project. The main reason for this is to ensure that students who are lacking in technical confidence do not "opt out" of the computer science aspects of the course by volunteering to take responsibility for documentation or management. We are very clear in our course briefings that every student must make a technical contribution in order to earn their ticks.
Note that working in groups does involve substantial coordination and managerial overhead. We are aware that some members of each team will accept a disproportionate burden in such work, especially if elected as the official group contact or project manager. We do not penalise students for such work (on the contrary, the responsibilities they take often lead to the most valuable professional development and learning outcomes). However, we do require every student to make a substantive technical contribution to the project. The main reason for this is to ensure that students who are lacking in technical confidence do not "opt out" of the computer science aspects of the course by volunteering to take responsibility for documentation or management. We are very clear in our course briefings that every student must make a technical contribution in order to earn their ticks.


Ticks are assessed at the end of the course, after final presentation and submission of personal reports. If there is any sign that a student may not have made a contribution to justify award of the ticks, we will contact the DoS directly at that stage, in order to check whether the student has some personal problem that we were not previously aware of. If the student's personal report was incomplete, or possibly evasive in relation to their technical contributions, we may invite the student to provide a more detailed report of their personal contribution and interaction with the group. A DoS might usefully advise the student with regard to the preparation of this more detailed report.
Ticks are assessed at the end of the course, after final presentation and submission of personal reports. If there is any sign that a student may not have made a contribution to justify award of the ticks, we will contact the DoS directly at that stage, in order to check whether the student has some personal problem that we were not previously aware of. If the student's personal report was incomplete, or possibly evasive in relation to their technical contributions, we may invite the student to provide a more detailed report of their personal contribution and interaction with the group. A DoS might usefully advise the student with regard to the preparation of this more detailed report.

Latest revision as of 17:19, 26 March 2017

The Director of Studies in Computer Science at each Cambridge college is recorded here: http://www.cl.cam.ac.uk/teaching/dos-list/

Advice for Directors of Studies

We recommend that during Lent term, Directors of Studies regularly discuss with Part 1B students the contributions that each student is making to the work of their project teams. Occasionally, we find that a student has not made any contribution to the project, but has not informed either their DoS or the group project convenors of the problem that led to this. If we do not learn of this situation until after the end of the project, this places us in the unfortunate situation that the student may not have earned his or her individual ticks, but since the project has ended, there is no opportunity to rectify the situation and earn the ticks.

Students are able to make a request that they be excused from some aspect of the project. We ask that this request be communicated to us in the form of a letter from the student's personal Tutor. These requests may result from illness, from family circumstances, from sporting commitments or other causes. If the policy at your College means that this standard approach is not appropriate, we may be able to accommodate local practices. Otherwise, we assume that the student will keep you informed, rather than relying on us to deliver individual status reports to college DoSes.

If a student does experience a problem with the group project, we strongly encourage them to inform us at the earliest opportunity in order to make alternative plans. If students are experiencing problems, but do not inform us, there is little we can do. Please do encourage them to let us know of any problems via the group-project email address. This address is received by the group project convenors, and by the staff of the student administration office.

We also invite DoSes to contact us in confidence, if they are aware of any reason why a student might struggle with the project (for example, related to disability or illness, or a track record of problems in group work). We send a reminder to DoSes each year, before the teams are allocated, so that we can take any issues into account. We are also happy to receive any information from DoSes at this time, or at any other stage during the project.

Our published intention is that we expect all students to gain all four ticks for the group projects. The most common cause of failure is serious illness or bereavement, and in these cases the DoS is usually well aware that the student is having trouble. Less commonly, students who were otherwise doing well in the Tripos have unexpectedly failed to earn group project ticks. Some potential failure modes that DoSes should be alert to include:

1. A student spends a lot of time proposing, researching or "evaluating" possible technical approaches, or else criticising the technical approaches taken by other members of the team, but does not implement any actual code themselves.

2. A student does not communicate with the rest of the group, instead choosing to work by themselves, often with the result that they deliver code different from what was required (perhaps because they did not participate in discussions that would have alerted them to changing requirements).

3. A student does contribute to the code base, but only in the form of documentation, for example adding comments, writing README files, importing open source content, or making commit log entries that focus on descriptions of bugs and their possible causes rather than source code.

4. A student delivers an initial version of the code that was assigned to them, but leaves it to other members of the team to resolve faults, rather than taking responsibility for design iteration, debugging and maintenance of their own work.

Note that working in groups does involve substantial coordination and managerial overhead. We are aware that some members of each team will accept a disproportionate burden in such work, especially if elected as the official group contact or project manager. We do not penalise students for such work (on the contrary, the responsibilities they take often lead to the most valuable professional development and learning outcomes). However, we do require every student to make a substantive technical contribution to the project. The main reason for this is to ensure that students who are lacking in technical confidence do not "opt out" of the computer science aspects of the course by volunteering to take responsibility for documentation or management. We are very clear in our course briefings that every student must make a technical contribution in order to earn their ticks.

Ticks are assessed at the end of the course, after final presentation and submission of personal reports. If there is any sign that a student may not have made a contribution to justify award of the ticks, we will contact the DoS directly at that stage, in order to check whether the student has some personal problem that we were not previously aware of. If the student's personal report was incomplete, or possibly evasive in relation to their technical contributions, we may invite the student to provide a more detailed report of their personal contribution and interaction with the group. A DoS might usefully advise the student with regard to the preparation of this more detailed report.