[NSWI004] Regarding Project Activity Points

[Ondřej Roztočil]

Dear Prof. Tůma,

thank you for taking the time to write your answer. Although you haven't addressed my other issues, it was interesting and useful for understanding your motivations. I guess the main difference between our perspectives is that you care lot more about making sure no one cheats than I do (probably understandably). My basic viewpoint is that: 1) vast majority of students are well-meaning and responsible, 2) they can be trusted with how they approach their learning and how they schedule their school work, 3) grading and overall course structure should be designed around them.

Also, I feel the need to state that I don't really care very much about this, personally, and I would appreciate if we could get rid of the mentality that one can only question something because they have some ulterior personal reasons. (I'm not saying this is your case, Mr. Tůma, just in general.)

Regarding your criticism at the end:

> 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.

I shouldn't have phrased my "theoretical" point as pompously as an issue of teaching lessons. However, teachers repeat morals about basic programming practices all the time, even though every student knows them - why shouldn't they care about their lessons in other areas. Leaving that aside, my idea is that a system that requires team work and at the same time only rewards individual coding doesn't seem great.

> yet you suggest that we might abuse our position and take a petty revenge on you

I assume that you are making fun of me in return, but in case you don't: my last remark was just an ironic quip (as I have an unfortunate urge to fill my emails with). I obviously hold you and your colleagues in high esteem.

Best regards
O.R.
________________________________
From: Petr Tuma <petr.tuma at d3s.mff.cuni.cz>
Sent: Wednesday, October 21, 2020 10:08 AM
To: Operating Systems Course <nswi004 at d3s.mff.cuni.cz>; Ondřej Roztočil <roztocil at outlook.com>
Subject: Re: [NSWI004] Regarding Project Activity Points

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/nswi004/attachments/20201021/57811f24/attachment.htm>