Tuesday, March 31, 2009

Assignment #7 - Austin Lin (akl29)

This semester I am working in a relatively large group on a semester long project for CS 5150 Software Engineering. Defined as defined as a “willingness to be vulnerable, based on positive expectations about the actions of others,“ (Bos, et al. 2002) trust between the 7 team members is very important and is a constant issue that we need to deal with. Because our grades all depend heavily on how much we contribute as well as the overall completion of the project, we need to be able to trust each other with assigned portions of the project, meeting deadlines, attending meetings. There is nobody going back to explicitly check on each person’s contributions so there is a certain level of trust in that everybody contributes high quality work. Completing consistently any of the above would be considered desirable behaviors. Thus completion of the project within deadlines and with quality work reflects cognitive trust. Emotional trust is seen in intergroup relations and the consequences of the course grading.

In an ideal reputation system, each person could receive essentially karma points for contributing over the course of the semester. Though it would be hard to implement and keep a tally of points, a user could gain points by consistently meeting deadlines and attending meetings. Producing good work that is rated by other users would give additional karma points. A reward system could be built in so people who have worked harder on certain areas can be assigned fewer tasks in the future; also people have direct feedback on how much they have given to the project so they know if they need to contribute more. This reputation system would work best in a situation where the ratings would be “portable” in multiple classes throughout a students college years. This would effectively create a “shadow of the future” and affect being chosen for future group projects.

The system could be manipulated in a few ways; first users who realize they have contributed more than average would become worse team members by contributing far less. A decay system could be implemented to keep very high ranked users from abandoning the project thinking that they have contributed enough. Also users who have low rankings due to poor quality work or insufficient ability would be assigned more responsibility, which may lead to a cycle of lowering ratings as well as trust. Collusion between members in which friends help each other can also lead to slightly inflated rankings.

3 comments:

  1. Nice post. The point that "grades all depend heavily on how much we contribute as well as the overall completion of the project" not only requires a lot of trust between members, but it goes back to Kraut's input-process-output model where member needs (particular satisfaction) needs to be high in the output. Since it is assumed that everyone in the group will want a high grade, each member will probably invest a lot of time into your project. I like the "karma points" even if it would be a little hard to manage.

    ReplyDelete
  2. I like your choice of topic, extensive group projects could definitely benefit from a reputation system. I usually find that those 1 page summaries you turn in at the end of a project are rarely ever useful. They're usually very subjective, and if group members didn't get along well they can end up giving each other very harsh, but not true reviews. Generally in my classes, professors rarely even give different grades based on these forms because of that reason, so maybe the karma points could help to solve the problems of lackluster group members.

    ReplyDelete
  3. Cool idea. I can definitely relate to this idea of trust in group projects. This semester I am in four group project based classes and trust is a very important element to the dynamics of the group. Although your system is really cool and could potentially work, I think that people might be more determined to contribute more in the beginning of the project when things are easier so that they don't have to contribute as much towards the end of the project when things get more difficult. Good post!

    ReplyDelete