Hi! > Why? Misconduct is simply the inversion of 'conduct', and a code of > conduct, necessarily, primarily deals with misconduct. Good conduct is > supposed to be what normally happens. It's the exceptions to that - > misconduct - that you need a code to manage.
I would disagree with that. If you look around at numerous examples of codes from other projects provided here on the list so far, most of them *are* much more than penal code. And that's not a coincidence - it works much better with people if you start with what we're trying to do and why, and then proceed to what, *in the light of the above*, we do not do and not allow to be done. It's not something we invented right now - a lot of people in many projects seem to agree this is the best way to do things. > What do you consider to constitute consensus? Absolute unanimity, or > large majority support? I'd like to repost this link: https://tools.ietf.org/html/rfc7282 While it does not exactly *answer* the question as such, I think it makes it easier to get thinking about it and illuminates some issues with what we do - e.g. 67% vote is hardly "consensus", and even 99% vote *sometimes* may not be the same as consensus. Again, it's not a solution, more food for thought. > I suppose it means people should just plan to properly hand things over > rather than quit, given how fairly inevitable someone else picks these > things up again, but nobody is acting in bad faith here. Yes, I think people should propose handover, especially for RFCs that clearly have more than one person supporting. I understand it is hard to do in the middle of rage-quitting or exhausted-quitting, but I think it is time to remind people of this option, maybe add to the RFC process. It can be as simple as "please take over this RFC otherwise I will withdraw it" instead of just withdrawing. > Seeing what has happened to countless people that have spoken up online > about harassment, and knowing that I contribute under my actual > real-life name, has made me self-censor to some extent. I decided not to Well, this is a problem. It is a very serious problem. People lost their jobs, careers, reputations and other things because of internet and meatspace trolls. However, as far as I can see, it is not the problem that *our* community has, and I think we can keep it this way. And that relates of course to trolls of all political persuasions, colors and shapes - of which, yes, there's no shortage of. Not providing food or shelter to them is one of the thing we hope to achieve at least in the spaces of this project. > revive the CoC RFC myself for a reason. Seeing certain participants in > the code of conduct discussion openly retweet messages by leaders of > organised harassment campaigns, campaigns targeting people like me, is > absolutely terrifying. I would caution though about making guilt by association. Re-tweeting something (often third-, fourth- and 9000th-hand) does not mean agreeing with all the author of the tweet has ever said or done. I don't want to go too deep into problems of Tweeter and such as a discussion medium (TLDR: it is unbelievably bad), but one of the things we don't want to get into is permanently labeling people because they once shared a link to something written by somebody who also wrote something bad on entirely different media, possibly years ago. I think the principle of "assuming good faith" (https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith) would be a good idea here. Note this is not a permanent label either, it is "assumption" for initial approach to the interaction. > We don't exist in a vacuum. I agree. And this is why we should be careful in what we accept as a commitment by the community - because it doesn't affect only us here that discuss it, and not only our motivations, interests and actions would be important. We know from our 20-year experience in PHP project that people would try to use what we create in ways we never thought of, some of them wonderful, some of them making us shudder. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
