Open bennyty opened 8 years ago
(@bennyty and I discussed this today in my small group, here were some of my thoughts)
It's true we're trying to objectify something that is very subjective in nature. I'd love to hear new ideas as to how we can really do this without substantial burden on our already extremely hard-working faculty advisers.
Maybe its all in the wording. Instead of saying "you need 7+ contributions minimum each week to pass" it could read "if you do not reach an average of 7 meaningful contributions per week your case will be flagged for review." What I got out of the documentation the first time I read it was that the cold-hearted autograder would read and calculate scores and grades with no ability to understand context (ML? lol.)
I very much agree with Ben's sentiment and thoughts here. He's not a mentor, he's a student who interpreted these guidelines as many other students did.
A rethinking of this grading scheme is necessary.
If you have alternative suggestions, please feel free to send it - We can consider the best of a few suggestions.
On Wed, Sep 14, 2016 at 4:07 PM, Theo Browne notifications@github.com wrote:
I very much agree with Ben's sentiment and thoughts here. He's not a mentor, he's a student who interpreted these guidelines as many other students did.
A rethinking of this grading scheme is necessary.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rcos/intro/issues/14#issuecomment-247137251, or mute the thread https://github.com/notifications/unsubscribe-auth/AANYdLfSVkaw6-GBZjxDiyzoSrNChROJks5qqFQAgaJpZM4J8P8j .
Best Regards
I regoogle
M. S. Krishnamoorthy (mskmoorthy@gmail.com) 518-276-6911(o) 518-273-6624(h) http://www.cs.rpi.edu/~moorthy http://rcos.io
Some hypotheticals to consider:
What happens to existing projects where they do not follow the "standard" "open an issue, code up a feature/fix, open a PR, talk about it, merge it in" workflow. Won't they have significantly less "contributions?" They might then try to conform by opening a bunch of low-effort issues & commits.
Along the same lines, what if you are on a small project? Large projects tend to lead to more discussion; if each comment on a PR is one contribution then large projects will naturally have more discussion. If you are on a project by yourself do you just talk to yourself (or commit 2-3 times more often?)
What if your group likes to discuss ideas and features in a way that is not so public? Why force them to talk in an GH issue (or tediously transcribe their real conversations onto an issue.)
What if you PR is so good that it requires no discussion?
What about projects that require you to squash your commits before pushing them? You actually wrote 30 commits but you
rebase --squash
them before showing them publically.Of course some of this is very hypothetical but someone is going to experience all of these issues and we should try to iron the big ones out before they become a problem. How can we fix these? I know that this isn't your (the admin's) fault and that there is no perfect solution.
EDIT: I wanted to add a thank you to our faculty who I know spend a long time grading us and even longer stressing over the problems class such as RCOS brings. Thank you for your effort and the opportunities that it presents.