[NSWI004] Regarding Project Activity Points

Tomáš Kubíček tomas.kubicek69 at gmail.com
Wed Oct 21 00:10:24 CEST 2020


I would add one more thing to those points. Point per 100 lines of code
will in my opinion encourage us to write ugly looking code, because why
would we write something compact and easy to understand when we will get
penalized for that.

On Tue, 20 Oct 2020 at 23:28, Petr Tlapa <tlapik123 at gmail.com> wrote:

> I agree, I think these points you mentioned are quite solid and a
> really good ground for some kind of discussion.
>
> út 20. 10. 2020 v 23:02 odesílatel Tomáš Kubíček <
> tomas.kubicek69 at gmail.com> napsal:
>
>> I have similar doubts about this system and would appreciate discussion
>> about this topic.
>>
>> On Tue, 20 Oct 2020 at 22:26, Ondřej Roztočil <roztocil at outlook.com>
>> wrote:
>>
>>> Hi,
>>>
>>> the mailing list seems to be quiet lately. I would like to use this
>>> opportunity to post some questions and unsolicited critical thoughts about
>>> the concept of 'Project Activity Points' (see 00-common.md in grading repo)
>>> which is going to be relevant for students soon. I understand that the
>>> teachers have thought about this more than I have, so they probably had
>>> their reasons for setting the rules like this. However, I expect more
>>> students to have similar doubts and it might be useful to have some
>>> discussion to dispel these doubts.
>>>
>>> I will try to be brief:
>>>
>>> 1) Using number of days on which students make a commit as a metric for
>>> points seems rather unfriendly towards their schedules. If a student
>>> communicates and plans with their team well, I don't see why they should be
>>> penalized for only having time to work on the assignments once a week,
>>> rather than twice a week, for example. This can of course be "gamed", but
>>> that seems silly and promotes bad Git practices.
>>>
>>> 2) Number of submitted lines of code is also a questionable metric.
>>> Generally, the shorter the code is (while retaining readability, etc.) the
>>> better. Or do you expect that everyone will need to write 2000+ LOCs
>>> anyway? Further, how does it work with Git history and what code is
>>> actually taken into question? Should teammates refrain from refactoring
>>> each other's code or they risk taking away their points?
>>>
>>> 3) Finally, more theoretical point. Maybe I am missing why there are
>>> teams for this course in the first place, but it seems to me that these
>>> 'Activity' 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?
>>>
>>> Sorry for not structuring this better and sorry to my teammates if I
>>> tanked our chances for passing the course.
>>>
>>> Best regards
>>>
>>> Ondřej
>>> _______________________________________________
>>> NSWI004 mailing list
>>> NSWI004 at d3s.mff.cuni.cz
>>> https://d3s.mff.cuni.cz/mailman/listinfo/nswi004
>>>
>> _______________________________________________
>> NSWI004 mailing list
>> NSWI004 at d3s.mff.cuni.cz
>> https://d3s.mff.cuni.cz/mailman/listinfo/nswi004
>>
> _______________________________________________
> NSWI004 mailing list
> NSWI004 at d3s.mff.cuni.cz
> https://d3s.mff.cuni.cz/mailman/listinfo/nswi004
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/nswi004/attachments/20201021/30bcdadf/attachment.htm>


More information about the NSWI004 mailing list