As the project goes on, work that needs to be done is entered into the class issue-tracking system, either by managers (graduate students) or developers (undergraduate students). Each issue has a number of points associated with it. Students assign issues to themselves to indicate that they are working on them. After the issue is complete, the manager closes the issue, thereby indicating that the associated points have been earned.
The group grade is essentially the percentage of the total number of completed points, relative to the total number of points. For example, if there are 50 points for all issues, and 45 points for closed issues, the group grade is 45/50*100=90.
The individual grade is the percentage of points earned, relative to the average earnable points per person. For example, if there are 50 points and 10 people, the average earnable points is 5. If a student earns 4 points, their individual grade is 4/5*100=80.
The overall project grade for a student is 50% group, 50% individual. From the examples above, the student's project grade would be 90*50/100 + 80*50/100=85.
At any time, you can determine your project grade by using issue-tracker to generate a "Performance Score" report for the current milestone and the Developer group. The points will be reset after each milestone, so as to not unfailry punish people who do poorly on a previous milestone.
The earnable points are used to compute each developer's share of the work. So the target points per person is the earnable points divided by the number of developers. The individual grade is then the percentage of points earned by the developer, relative to the target points per person.
If a developer performs some work and feels that the difficulty or priority estimates were incorrect, the developer may ask the manager for the task to review these values, providing some justification for why they need to be changed.
The overall grade is 50% group grade, 50% individual grade. If a person does absolutely nothing for the project, the best grade they can hope for is a 50. (100% group grade, and 0% individual grade averages to 50%.) If a person gets a 100 individual grade for the project and no one else does anything, the best grade the person can hope for is slightly higher than a 50. (>0% group grade, and 100% individual grade averages to over 50%.)
One situation which may occur is that the outstanding issues may be 100% complete, but the software may still be unfinished. (This can happen if no one enters new issues to fix problems or implement missing functionality.) In this situation, the developers will receive the grade computed by issue tracker.
Another situation that may occur is that points are assigned unevenly to different types of tasks, or for the same type of task across different managers. Managers should work hard to ensure that easy work is worth less points than hard work, and should cross-check each other periodically to ensure consistency.
Management of issues is the manager's reponsibility. If tasks are missing from the system, developers cannot be expected to complete them. Managers are assigned grades at each milestone by the professor, based significantly on their management of the developers via the issue tracker.
Milestone grades for devleopers are determined by doing the above grading for the tasks created for the given milestone. The milestone grade can be computed by selecting the appropriate milestone from the report form in the issue tracker.
Issue tracker will limit you to two tasks at a time. If you want to join a task with other developers already working on it, make sure it's okay with them. If you see someone abusing the task list, please notify the task manager.
You should get an email notification if anyone modifies a task. You should talk to the person, and contact the task manager if that doesn't work.
Managers will have three options. If the task is incomplete due to gross negligence, the manager can reopen it, in which case the developers will lose the points until they complete it. If the developers do not wish to continue working on a task, the manager can leave the task closed but lower the number of points. If the task is done but could be done better, the manager can add a new task.
Early in the semester, you can be assured that there will be many more tasks added to the system. Late in the semester there may be no "good" tasks (or any at all!). However, there is always some way that the software can be improved. Just create a task for whatever you think needs to be done. For peace of mind, it's better to earn your points early.
Managers add tasks for work that needs to be done. If there's more work for the developer group, then you need to do more work yourself to maintain your grade.
You can tell the manager why you think the points should be adjusted. If you are unhappy with their decision, you can appeal to the professor. Decisions the professor makes are final. You'll also have a chance to evaluate all the managers at the end of the project.
Yes. Sorry, but the system is complicated enough already.
This is by design. Everyone must share in the success (or failure) of the project. If you want a better group grade, you will need to get the slackers more involved, or you will need to cooperate with others to "pick up the slack".
Managers always try to make the points consistently fair. If you do a task before the manager has had a chance to make the points appropriate, the manager can't do anything about that. If you are worried that this might happen, contact a manager to make sure that the points are correct before starting the work.
You really should create an issue for the work that you do, because it helps communication during development. If you fail to create the issue before starting the work, then someone else might do the work and get the points for it before you finish. And if you need the points, you won't get any credit for the work that you've done unless there's an issue for it.
If you don't need the points, you may be concerned that adding a task for some work that you want to do may increase the workload for the rest of the class. Just create your task, assign it to yourself, and set the modifier so that the overall point value is 0. If you ever need the points later, you can ask the manager to set the modifier back to 0.
Finally, managers should keep in mind that they will be evaluated on the final product. As a result, they should be proactive in making sure that the issue tracker list of issues truly reflects the work that needs to be done. Allowing developers to do work "outside the system" increases the chance that the work won't be properly tracked and completed.
Back to CSci 435/535 Homepage.
Last changed February 03 2006 09:57:19.
David Coppit,
coppit@cs.wm.edu
There have been 1221243 hits since Thu Jun 9 14:49:55 2005