Hello! :) The CoC is a lie. From my point of view, some of the current intentions at least.
I'm hesitating a bit, that I'm so loud. I'm doing this to prevent problems at the community, trying to find bottlenecks and provide better solution for us. > The rest should be in the CoC text itself and how it empowers the resolution committee to make its decisions as well as any checks-and-balances on the com committee itself. Specifically, the CoC should not be used to discriminate against one's political views any more than on another's sexual orientations. And what you do on your private time is your own business. I want to contribute: to accept that, we have to define "private time" meaning in a such public place as the web. Is personal blog page posting a private time? Secondly, the idea about "non-discrimination" and being free from shared political or other values (at least minimal) could be easy perverted as restriction to even talk about the defined topics. It could be used against the community false-defining some sentenses as restricted. And we have real-life examples of this. So we probably need at least minimal shared values if we are proposing some CoC, not just undefined "free from discrimination". > We can also work with that person to find a compromise solution. I find it hard to believe we couldn't, if that person is willing to see the other side of the coin. And I speak from experience on that. I agree we should work together on shared values > 3) how do we prevent ill side-effects and abuse? One ill side-effect would be the turning away of important contributors who feel that the adoption of the CoC stands in the way of their participation. But please note that has not happened to any significant manner in any of the big Open Source Projects that have adopted CoCs. That includes the Linux kernel: despite what you may have heard in the media, the kernel maintainers and Linus himself subscribe to the new CoC and Linus has returned to development. Looks like it doesn't happened yet to open source projects, yes (feel free to correct me). Just want to add that proposed CoC raised the questions at least in case of the kernel project and we should carefully research negative impact too to prevent worst results > 2) why not let the code rule? [...] So clearly code is not enough. I agree. I guess the idea why some people focusing on the code it's because the code is better defined and verifiable at least. And some people are probably searching for metrics how to check CoC is positive for community development not negative. If we don't provide well-defined document, it's probably makes no sence to include undefined with visible dangerous problems. That's why some probably prefers KDE's version more. > 1) if it ain't broke, why fix it? [...] We don't want to lose them or their contributions. Think of the CoC as preventive maintenance: you don't do it because it's broken. You do it so it *won't* break in the first place. I probably agree. And want to add we should be very careful. > But the CoC was adopted, with no ill effects. I guess global situation changed since that. And what if we compare the number of public conflicts at the world and dates when undefined rules about that was accepted at big companies? And it's not about just example with Theodore Ts'o. Look at the cinema world. We should be careful not to create rules that could be just a backdoor for external companies to force thier expansion ideas not focused on helping at all. I agree we should think about others and help each other, and could try to build shared values document. The questions is about implementation. > So I want to say this first: Intel does support Open Source Projects adopting Code of Conduct as well as actions leading to increasing access and diversity of ideas, hopefully leading to improved code. We also particularly like the Contributor Covenant text. My idea was to show that "diversity of ideas" is just yet another idea. Not all the ideas is clear and positive by default. "What's you favourite idea? Mine is to be creative..." (from "Don’t Hug Me, I’m Scared") пт, 26 окт. 2018 г., 8:15 Thiago Macieira <thiago.macie...@intel.com>: > On Wednesday, 24 October 2018 00:17:09 PDT Ulf Hermann wrote: > > Hi, > > > > regarding our earlier discussions on a possible Code of Conduct, here as > > well as at the Contributors' Summit 2017, I've pushed a QUIP with the > > necessary rules and definitions: > > > > https://codereview.qt-project.org/243623 > > Hello Ulf and everyone else on this thread > > I've posted a few comments here and there relating to the process of > adopting > anything in our community, but I haven't yet voiced my opinion on this > subject. This email is it. > > Note that even though I am speaking for myself, I understand my opinion > reflects on my employer. So I want to say this first: Intel does support > Open > Source Projects adopting Code of Conduct as well as actions leading to > increasing access and diversity of ideas, hopefully leading to improved > code. > We also particularly like the Contributor Covenant text. > > I am also personally in favour of adopting a CoC and I support adopting > either > the Covenant text or KDE's. Both are fine to me. Another good one is > Mozilla's[1], which the SQLite developers have just adopted too. > > In fact, I was there 10 years ago when KDE decided to adopt something. > Back > then, I was also of the opinion that we shouldn't need anything. The KDE > community had always been a welcoming one: in my first Akademy, I was > greeted > by people I had only met online as an old friend. Moreover, the KDE > community > had always resisted any kind of formal structuring of anything, which led > to > the Technical Working Group being created and disbanding in 2006. Even > today, > the KDE e.V. takes great steps to make sure it is never seen as a ruling > body. > > But the CoC was adopted, with no ill effects. I do not have direct > knowledge > of where they had to intervene, if at all, but I'm told it has happened. > More > importantly, I have also grown as a person since then. In a particularly > telling moment, when a female colleague here in the office (located in a > very > affluent, liberal and progressive part of the US) once asked my opinion on > the > Python Donglegate incident and explained to me the reason why she > interpreted > it the way she did, I realised how my worldview was so very different from > hers. I've come to understand how little things that did not bother me > were > highly offensive to her. > > I've seen basically three questions asked by the skepticals to this > proposal: > > 1) if it ain't broke, why fix it? > > To put it simply: the CoC has as an objective make sure the community is > always welcoming and inclusive. People have a limit on how much hostility > (intended or not) they're going to put up with. If they reach that limit, > they're going to simply avoid it and that can be anywhere from avoiding > contributions to certain parts of the code to stopping contributing > altogether > (or worse). We don't want to lose them or their contributions. > > Think of the CoC as preventive maintenance: you don't do it because it's > broken. You do it so it *won't* break in the first place. > > 2) why not let the code rule? > > Code does not exist in isolation and the Qt Project is not a set of files > in > Git. The Qt Project is a community that maintains that code, so we need > rules > beyond code. We have contributors who don't contribute a lot of code, but > that > does not make them any less important members of the community. > > Besides, any commit comes with a commit message. Any review comes with > feedback and there are few that are simply "+2" with no text. We want good > code, improving Qt and for that we need to interact with one another. > Moreover, the major architectural issues are not discussed in code, but in > prose via email. > > Finally, being good at C++ is not an excuse for being a jackass. No one > should > get a pass because they're experts at something. We can't make the cold > calculus that "person X's productivity is worth 10 new contributors so we > will > allow X's behaviour to turn away 10 contributors". What happens on the > 11th? > And what if one of those turned out to be amazing after a few months? > > So clearly code is not enough. > > 3) how do we prevent ill side-effects and abuse? > > One ill side-effect would be the turning away of important contributors > who > feel that the adoption of the CoC stands in the way of their > participation. > But please note that has not happened to any significant manner in any of > the > big Open Source Projects that have adopted CoCs. That includes the Linux > kernel: despite what you may have heard in the media, the kernel > maintainers > and Linus himself subscribe to the new CoC and Linus has returned to > development. > > We can also work with that person to find a compromise solution. I find it > hard to believe we couldn't, if that person is willing to see the other > side > of the coin. And I speak from experience on that. > > The rest should be in the CoC text itself and how it empowers the > resolution > committee to make its decisions as well as any checks-and-balances on the > com > committee itself. Specifically, the CoC should not be used to > discriminate > against one's political views any more than on another's sexual > orientations. > And what you do on your private time is your own business. > > [1] https://www.mozilla.org/en-US/about/governance/policies/participation/ > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
