Closed ullrichd21 closed 2 years ago
I think it sounds good as is personally, but if it needs a bit more added to it perhaps you could add:
'Students will not disrespect peer contributions in work, code, speech, or otherwise. For instance, unfair or not relevant criticism, and modifying others code without permission are a few examples.'
I think it would be great if this point is expanded on how it's ok to review and provide constructive criticism on peers work and code without being disrespectful. Clarifying the distinction between the two can help team work and creating a quality product.
I think it sounds good as is personally, but if it needs a bit more added to it perhaps you could add:
'Students will not disrespect peer contributions in work, code, speech, or otherwise. For instance, unfair or not relevant criticism, and modifying others code without permission are a few examples.'
I support adding the point around modifying others' code as long as we clearly define what you mean by "others' code". When working on a project, code will always be changing and ownership over files/functions/code snippets is really not clear all the time. Some might argue that a team member doesn't really have ownership over that code once it's part of the whole project. It's rather owned by the team. Because of that, it's usually ok to make all sort of edits in a separate branch and reviewers are the ones who try to communicate and make decisions on what code should be added/replaced.
However, if by "modifying others' code" you're referring to intentionally changing code in a team branch that you're not involved in or are not expected by team members to make changes in, then I would agree that students should not do that.
I think it sounds good as is personally, but if it needs a bit more added to it perhaps you could add: 'Students will not disrespect peer contributions in work, code, speech, or otherwise. For instance, unfair or not relevant criticism, and modifying others code without permission are a few examples.'
I support adding the point around modifying others' code as long as we clearly define what you mean by "others' code". When working on a project, code will always be changing and ownership over files/functions/code snippets is really not clear all the time. Some might argue that a team member doesn't really have ownership over that code once it's part of the whole project. It's rather owned by the team. Because of that, it's usually ok to make all sort of edits in a separate branch and reviewers are the ones who try to communicate and make decisions on what code should be added/replaced.
However, if by "modifying others' code" you're referring to intentionally changing code in a team branch that you're not involved in or are not expected by team members to make changes in, then I would agree that students should not do that.
I agree with @noorbuchi 's assessment in terms of ownership. Maybe provide a distinction between what counts as team code and what counts as a singular student's code. For instance, "team code that can be modified" can be code that has already been merged into the main branch, and a "student's code that should not be modified" can be code that is actively being worked on in a separate branch from the main branch.
I think @gvanzin-allegheny, @noorbuchi, and @solisa986 have raised great points about the important issue of code ownership. However, it may help to contextualize the original question. Here is the introductory paragraph for the Participation section under which I made the comment:
Participation for students will be based on a multitude of factors. We all have bad days and we all have topics we know more or less about, but how many times a student speaks a day will not solely make up their participation. It is being prepared each day, having done the prerequisite work, coming to class with an open mind to learn, and making an effort to be apart of either small group or large group conversations that will reflect students participation.
It appears that this section focuses on class participation, rather than participation on assignments. So, if the point "Students will not disrespect peer contributions in work, code, speech, or otherwise." is expanded, then the new sentence(s) should be about class participation.
When I originally made the comment, I was thinking that it might be good to give some examples of "disrespect" in the context of class participation. For example, ignoring certain students in your group or belittling the ideas of others would be examples of disrespectful behavior. What does everyone think about adding these kinds of details to this "Unacceptable Conduct" section?
- Students will not disrespect peer contributions in work, code, speech, or otherwise.
Could this point be expanded into a couple of points that are more specific about what disrespect looks like?
Originally posted by @mariakimheinert in https://github.com/cmpsc-203-s22/code-of-conduct/pull/5#r817200520
Thoughts on this? Anyone have ideas on how to expand this and resolve this?
I personally think we talked a lot about being respectful so I feel it should be self explanatory? I don't want to expand and make this area too wordy?