4 ms·

I could see this being both a blessing and a curse. On the one hand, it's easy to see how this is a powerful tool respectful developers can use to moderate the

I could see this being both a blessing and a curse. On the one hand, it's easy to see how this is a powerful tool respectful developers can use to moderate their community positively. But from the other, I've heard a few too many stories along the lines of "passionate contributor breaks into argument with passionate repo owner" and chaos ensues. I could see feature a way for people to step on toes and divide rather than encourage positive community.

geofft 11y ago
I think a better long-term solution for the problem you describe is community norms around shared maintenance, where a passionate repo owner can step back and ask other repo owners to moderate and cool down the discussion, or a passionate contributor can ask other people with authority in the project to step in and intervene, either just with words or with semi-binding decisions. This has a fairly long history in the F/OSS community, partly out of necessity before tools like GitHub existed. If your project is owned by some organization like Apache instead of by you personally, you still get to be a maintainer, but there are well-defined procedures for you not being the only maintainer. And one of the primary benefits of Linux distros is that it essentially forces a moderator (the distro packager) between users and the upstream maintainer, who can step in and choose to side with the user or the maintainer (or neither!) if there's a contentious discussion. Again, taking Linux distros as an example, all the major distros have some form of appellate group of developers -- Debian's technical committee, Fedora's steering committee, etc. -- who are encouraged to moderate important and difficult discussions, and empowered to overrule package maintainers if it ever becomes necessary. Preventing the repo owner from having the block tool wouldn't force them to come to an agreement with the contributor. They'd either keep yelling, use the (existing) close-and-lock-conversation button, ignore the contributor, or give up and get frustrated and burn out. I think it would be better to encourage social norms that allow handling these disagreements productively (and expecting that acrimonious disagreements will probably happen at some point,) than to expect to solve this by limiting technical tools. By the way, note that blocking users is a feature that already exists for individual accounts. Extending it to organizations makes it ever-so-slightly easier for those norms to grow, by removing essentially the only disadvantage of maintaining your project in an organization instead of in your personal account.
anon4 11y ago
Usually, the way, that civillised societies solve this problem, is with a judge and a jury of the accused's peers. In this case, community guidelines, appointed moderators, github employees as super-moderators in the case of user-moderator disputes, etc. What github are implementing now is monarchy - legislative and executive power in the hands of a couple of people (the repo owners) whose only qualifications are "we were first here".

geofft 11y ago

I think a better long-term solution for the problem you describe is community norms around shared maintenance, where a passionate repo owner can step back and ask other repo owners to moderate and cool down the discussion, or a passionate contributor can ask other people with authority in the project to step in and intervene, either just with words or with semi-binding decisions. This has a fairly long history in the F/OSS community, partly out of necessity before tools like GitHub existed. If your project is owned by some organization like Apache instead of by you personally, you still get to be a maintainer, but there are well-defined procedures for you not being the only maintainer. And one of the primary benefits of Linux distros is that it essentially forces a moderator (the distro packager) between users and the upstream maintainer, who can step in and choose to side with the user or the maintainer (or neither!) if there's a contentious discussion. Again, taking Linux distros as an example, all the major distros have some form of appellate group of developers -- Debian's technical committee, Fedora's steering committee, etc. -- who are encouraged to moderate important and difficult discussions, and empowered to overrule package maintainers if it ever becomes necessary. Preventing the repo owner from having the block tool wouldn't force them to come to an agreement with the contributor. They'd either keep yelling, use the (existing) close-and-lock-conversation button, ignore the contributor, or give up and get frustrated and burn out. I think it would be better to encourage social norms that allow handling these disagreements productively (and expecting that acrimonious disagreements will probably happen at some point,) than to expect to solve this by limiting technical tools. By the way, note that blocking users is a feature that already exists for individual accounts. Extending it to organizations makes it ever-so-slightly easier for those norms to grow, by removing essentially the only disadvantage of maintaining your project in an organization instead of in your personal account.

anon4 11y ago

Usually, the way, that civillised societies solve this problem, is with a judge and a jury of the accused's peers. In this case, community guidelines, appointed moderators, github employees as super-moderators in the case of user-moderator disputes, etc. What github are implementing now is monarchy - legislative and executive power in the hands of a couple of people (the repo owners) whose only qualifications are "we were first here".