[NSWI004] Regarding Project Activity Points

[Petr Tuma]

Hello,

let me follow up on your closing thoughts, because I think they are the most perceptive ones here.

> ... these rules teach the wrong lesson about team development: that 
> writing code is the only valuable thing a person can do. Research, 
> design, all sorts of communication - to give few examples relevant 
> even for our limited project - are just as important as coding. Has a
> system without artificial metrics, where it is solely up to the teams
> to make sure everyone does a fair share of work, been tried in the
> past and it proved too problematic?

The ultimate objective of the course is to provide the best environment in which you can learn useful knowledge about operating systems. Essentially, we have three big components that combine towards that objective - (1) we provide you with study material that contains the basic information pertinent to the topic, (2) we provide you with opportunity to exercise your knowledge in reasonably realistic settings of the assignments, and (3) we deliberately maintain somewhat vague character of the tasks (both quizzes and assignments) to encourage independent thinking, exposing it in public discussions.

In our experience, this provides a good environment for efficient learning. You are given enough basic knowledge to cover the topic, and you are pushed to apply this knowledge in various contexts, which helps expose and correct misunderstandings that may otherwise remain after you absorb the study material (by the way, this is also why discussing non essential technical points during the online lectures is important - although they are typically quickly forgotten, everyone can check whether the advanced points fit into their understanding of the basics, and thus detect possible errors).

That said, we also know that this style does not fit all students (I guess no approach would really fit everyone). That is where things tend to break - while we would love it if everyone focused on understanding the operating systems and trusted us to recognize and appreciate that understanding (by awarding the course grade, which is the minor nuisance that casts a shadow on our otherwise wonderful friendship :-), there will be some students that, for various reasons, will aim their focus on getting the grade and put their understanding second.

Obviously, we try to encourage everyone to stay with understanding as the primary objective. But in some cases we will necessarily fail and the student will shift his or her primary objective from understanding to getting the grade. That change in perspective brings along change in the tactics used throughout the course - if, for example, your goal is understanding, you would want to write and debug the code until you are satisfied that everything works as you think it should - but if your goal is getting the grade, you only want to get the code to pass the tests regardless of whether you really like the way it is written, whether you really understand it, or even whether you really wrote it. Personally, I believe that shift of tactics is self defeating in the long term, but it is really a personal choice of each and every student and while we can encourage you to move in what we believe is the right direction, we do not control you.

Which gets me, in a rather roundabout way, to the activity points. Besides helping you learn, we have other duties, and one of those is maintaining fairness and consistency in grading. Whatever system we set up must not offer easy shortcuts that bypass learning - and team work where one of the team members fails to do their duties and the other two pick up the slack in one such case. You suggest that we should let the teams self manage - but that is problematic for many reasons (for example, two skilled team members may prefer to finish the assignment themselves and let the third tag along for free rather than go through the personal and administrative hassle of reporting the issue and waiting for a resolution, also, personal loyalties and social dynamics may easily get in the way of fairness). Which is why we prefer a simple metric - activity points in this case - that will highlight anomalies and we can then address the issues appropriately.

Yes, the points can be gamed. As stressed above, we would much rather you spend your effort on becoming an expert in operating systems (or at least a very well informed outsider :-) than on figuring out ways to trick the git statistics. It should be obvious there are better things to do in life than that ...

> Sorry for not structuring this better and sorry to my teammates if I
> tanked our chances for passing the course.

One point that comes to mind reading this is - consistency. You suggest we should simply trust the team members to do their fair share of work, yet at the same time you do not trust the very same team members to realize that there are other essential components to team work than just commits, and you are worried that our simple thresholds on repository activity will lead them astray. And, you would trust this university enough to enroll and dedicate several years of your life to learning whatever it has to teach, yet you suggest that we might abuse our position and take a petty revenge on you and your teammates when you discuss a particular grading component ? If you trust us with the big things, why not with the small ones ?

Cheer up (and code :-)

Petr