Do not allow editing other's comments, sounds really dangerous

[pvenkatakrishnan]

I am able to modify another persons comment since I have full permissions on the repo. I find this weird. Agreed a person with full ownership should be able to moderate caustic comments (delete/ freeze)… But not be able to modify it. Could you please fix this ? Thanks.

[oprogramador]

IMO the owner/owners of each repo should decide separately

But isn't that what owners are doing when they assign triage (or, previously, collaborator) rights to a user? Or are you saying there need to be yet more granular permissions than currently exist?

Maybe these permissions need to expand from orgs to plain repos.

I mean more flexible settings so the repo owner could forbid comment updating by other users even himself until he changes this setting.

[Levi-Lesches]

If edits are used responsible for correcting formatting, making info more accurate etc. then sure, maintainers should absolutely be able to do that. But in that case why shouldn't everyone else too? There's nothing special about maintainers in that context. Just like everyone else, maintainers can edit comments in both good and bad ways.

The owner of a repo usually better understands (or gets to decide) good practices for a project. Not always, but usually. And in any case, the repo owners/maintainers get to set the rules for their project, simply because it's their project.

Again, I don't disagree, but by stating "we need a way ..." there's a small but important jump in logic here. Like you said, hopefully it's not needed, but still.

Okay, how about "would be nice if we had"? This is, after all, the place for requesting features.

If a comment has been edited, the UI already clearly shows that without requiring extra clicks.

Sure, but 1) it's small, and 2) there's no difference between a small edit shortly after and an edit that misrepresents the commenter (a malicious edit). If possible, a way to flag an edit as "this betrays the original meaning" would be nice. To clarify, not all edits need a flashy UI element -- just those deemed malicious.

They can already undo the edit, but that does not get them "the final say" because anyone else could edit their edit, and then it can descend into editor wars like on Wikipedia. It sounds like you are suggesting some kind of locking mechanism, but some careful thought would be required before implementing that, e.g. who can lock, and under what conditions?

Simple, the original editor can lock it, always. I see no circumstance where anyone should be allowed to forcefully overwrite another's comment without their consent. If the comment really needs to be modified for moderation purposes, it can be removed.

I prefer the reputation tracking approach I previously mentioned since it is a much more accurate method of assessing the quality of contributions from all participants, and it's already proven to work on StackOverflow.

True, but in StackOverflow there is no "ownership" -- all information in the questions and answers is public. On GitHub, the repo belongs to an individual or organization, and they can delegate certain moderation powers to trusted individuals. If I have low "reputation", does that mean others can change a project I upload to GitHub? It's not about trustworthiness, it's about ownership.

[TPS]

I mean more flexible settings so the repo owner could forbid comment updating by other users even himself until he changes this setting.

I just can't imagine most, if any, repo owners intentionally hamstringing themselves this way, much less anyone else they'd want to delegate such permissions.

[aspiers]

@Levi Lesches commented on June 22, 2021 12:21 AM:

If edits are used responsible for correcting formatting, making info more accurate etc. then sure, maintainers should absolutely be able to do that. But in that case why shouldn't everyone else too? There's nothing special about maintainers in that context. Just like everyone else, maintainers can edit comments in both good and bad ways.

The owner of a repo usually better understands (or gets to decide) good practices for a project. Not always, but usually. And in any case, the repo owners/maintainers get to set the rules for their project, simply because it's their project.

I agree with the sentiment, but what those rules occasionally happen to be "I'm the maintainer so I can edit your comment in any way I want even if you feel the edit wilfully misrepresents you"?

Again, I don't disagree, but by stating "we need a way ..." there's a small but important jump in logic here. Like you said, hopefully it's not needed, but still.

Okay, how about "would be nice if we had"? This is, after all, the place for requesting features.

No, it wasn't a quibble about wording; it doesn't matter whether it's worded as "we need a way ..." or "would be nice if we had". It would be helpful if you first justify exactly why we need X, or why it would be nice if we had X, by giving real-world examples of where the lack of ability to do that caused problems. Otherwise there's a danger of worrying about perceived issues which aren't actually issues.

If a comment has been edited, the UI already clearly shows that without requiring extra clicks.

Sure, but 1) it's small, and 2) there's no difference between a small edit shortly after and an edit that misrepresents the commenter (a malicious edit). If possible, a way to flag an edit as "this betrays the original meaning" would be nice. To clarify, not all edits need a flashy UI element -- just those deemed malicious.

Yes, this sounds like it would probably be a nice feature.

They can already undo the edit, but that does not get them "the final say" because anyone else could edit their edit, and then it can descend into editor wars like on Wikipedia. It sounds like you are suggesting some kind of locking mechanism, but some careful thought would be required before implementing that, e.g. who can lock, and under what conditions?

Simple, the original editor can lock it, always. I see no circumstance where anyone should be allowed to forcefully overwrite another's comment without their consent. If the comment really needs to be modified for moderation purposes, it can be removed.

Yes, that might work nicely.

I prefer the reputation tracking approach I previously mentioned since it is a much more accurate method of assessing the quality of contributions from all participants, and it's already proven to work on StackOverflow.

True, but in StackOverflow there is no "ownership" -- all information in the questions and answers is public.

Public does not imply lack of ownership. Every question and every answer clearly has an original author, whose reputation is increased when that item is upvoted, and decreased when it's downvoted. One could debate the semantics of "ownership", but the facts are that for both StackOverflow questions/answers and GitHub issues/PRs/comments, a) the original author is clearly visible and b) other people are allowed to edit what they wrote. So there is clear overlap between the two scenarios. The difference is that GitHub has no mechanism to assess the likelihood of edits being good ones, whereas StackOverflow does through its reputation system.

On GitHub, the repo belongs to an individual or organization, and they can delegate certain moderation powers to trusted individuals. If I have low "reputation", does that mean others can change a project I upload to GitHub? It's not about trustworthiness, it's about ownership.

What exactly do you mean by "change a project" here? Are you still talking about comment editing, or do you also mean other things like changing code, closing issues/PRs etc.? Obviously there's a huge difference, and I don't see the relevance of the latter to this issue, so I'm not sure what your point is here.

[Levi-Lesches]

I agree with the sentiment, but what those rules occasionally happen to be "I'm the maintainer so I can edit your comment in any way I want even if you feel the edit wilfully misrepresents you"?

It would be helpful if you first justify exactly why we need X, or why it would be nice if we had X, by giving real-world examples of where the lack of ability to do that caused problems.

This is the answer -- the reason we need some option to flag an edit as misleading is because the maintainer might "edit the comment in any way they want even if the edit willfully misrepresents the author."

Public does not imply lack of ownership... a) the original author is clearly visible and b) other people are allowed to edit what they wrote.

This is what I meant by "no ownership" -- no one can say "this is mine stop touching it". Especially on SO, almost every question I see says "edited by X", usually the community. That's allowed because the information belongs to everyone: the answers are for archive purposes just as much as they are for the asker. In GitHub, discussions are more person-to-person communication, so the idea of being able to edit those doesn't fit the same way. The only edits I see as good are just formatting edits that make the question more readable to those willing to answer, but again, the original commenter should be able to have the final say.

What exactly do you mean by "change a project" here? Are you still talking about comment editing, or do you also mean other things like changing code, closing issues/PRs etc.?

I meant everything, although you're right that comment editing is more relevant here. Again, comments (whether in issues, discussions, PRs, or commits) belong to people and represent that person's ideas and views. It would be completely wrong if others could edit that simply because they participate on GitHub more. Remember that a lot of repos are personal projects -- no external individual should ever have any control over a personal project; it simply doesn't belong to them.