[Development] QUIP 12: Code of Conduct

[Alexey Andreyev]

I agree my example is extremely contrived right now,
I just tried to show the idea.

Thank you, Elvis, for your answers.

> getting your patches rejected is not harassment
I agree that getting some patches rejected without any additional info is
not a harassment by default

I'm saying something like "water wears away a stone".
What could you say about public conflicts at
Opal, Github, Django, Ruby, PHP, Nodejs, Drupal, Linux after accepting
similar CoC?

> The patches can be respectfully rejected with e.g. "this is not in
> line with the Qt vision", or "could you please revise this part
> first?".

It easily could be misused as blocking due to discrimination
with existing CoC
and the question of resources and time on both sides

> See the difference?

Yes, of course. But I'm not talking about where CoC could be helpful right
now,
I agree we need rules.
I'm trying to pay attention on the current implementation.

We (me too) spend literally 0 minutes to scientifically research
social state of the Qt community,
didn't research influence and the trends of the accepted CoC at other
projects.

Nobody held even one social survey
about the nubmer of the conflicts at Qt project before,
anything like that.
Nobody tried to predict the consequences after accepting current CoC.

We just trying to provide some rules and to treat something blindly
without even specifying the problem.

вс, 28 окт. 2018 г. в 17:35, Elvis Stansvik <elvstone at gmail.com>:

> Den sön 28 okt. 2018 kl 14:29 skrev Alexey Andreyev
> <yetanotherandreyev at gmail.com>:
> >
> > > [...]  or the shorter list in the KDE CoC, so we instinctively
> > > want to trim the fat - we want to optimize.
> >
> > I've provided both (CC and from KDE) not to show some version is better,
> > but to show both have same problems.
> >
> > For me it's not about optimization right now. Is it possible to follow
> provided versions?
> > And receive more positive for the commuity than negative.
> >
> > > the purpose of this enumeration is to list those very large
> > > groups of people in society who are currently experiencing harassment
> > > and mistreatment for who they are
> >
> > Is that obvious that provided document will help not made things worse
> for everyone?
> > Are we going to treat something at the commuity just blindly without
> diagnosis and research?
> >
> > >  We tell a large part of the population who are currently
> > > being oppressed/mistreated that, at least in our community, you can
> > > feel safe
> >
> > How are we going to provide safety?
> >
> > > The enumeration is not supposed to cover everything, but I
> > > think it fulfills a purpose by covering a lot.
> >
> > As far as I can see the reasoning is based on the hypothesis that any
> rules will not be able to aggravate the situation. It's not obvious.
> >
> > > I don't agree with some earlier poster who thought of the enumeration
> > > as setting some kind of bar, I don't think that is the purpose of it.
> >
> > > The concluding "[...] or any other characteristics that are
> > > not relevant to a person's ability to contribute to the Qt Project."
> > > is of course very important *as well*, to cover our bases.
> >
> > How the committee is going to determine that someone has violated these
> "guidelines not bars"?
> > What is the purpose of the guidelines without additional information how
> to protect them?
> >
> > > I can't really see how this list could be misused. If people have an
> > > issue with a particular item on the list, they should say so.
> >
> > For example, let's say some person (person or legal entity, organization
> or groups of organizations) have projects, competing with Qt somehow (or
> linux, or KDE).
> > That "person/groups" will get more profit if Qt community will became
> unhealthy or will cease to exist.
> > That person could sponsor, support or pay money somehow to other persons
> to support some vulnerable ideas.
> > Persons who accept that ideas and have interests, conflicting with the
> community, could say something like
> > "hey, we are actually feeling harassment, please accept our
> ideas/patches/anything too".
> > It is a space for accepting non-obvious security or architectural
> changes.
> >
> > In 50, 10 or 5 years :) if attackers will be lucky enough, Qt community
> could lost their image of as awesome commuity as it is right now.
>
> I honestly think this is an extremely contrived example, and I think
> you're worrying way too much, but OK let's play along.
>
> You're suggesting that someone would submit bad patches, hoping to get
> harassed and thereby somehow get the patches in, as some sort of
> compensation for the harassment, and would use this in order to
> sabotage the Qt project?
>
> Looking past the ridiculousness of that idea for the moment, getting
> your patches rejected is not harassment. Not under any definition of
> harassment that I know of, and certainly not according to the
> suggested CoC.
>
> The patches can be respectfully rejected with e.g. "this is not in
> line with the Qt vision", or "could you please revise this part
> first?".
>
> The patches can also be rejected with "please don't submit crap like
> this, you fat dyke".
>
> See the difference?
>
> The first is not a matter for the CoC. If the party would still file a
> complaint, it would be dealt with and the council would find that no
> harassment took place. The second would most certainly be cause for
> some kind of action (I guess to begin with, tell the offender to not
> do that again and point them to the CoC).
>
> Elvis
>
> >
> > ..???
> >
> > PROFIT! Young generation not interested, no support, commuity is dying,
> profit for competing projects.
> >
> >
> > It's just one example that could sound like a joke since I'm not a
> professional with this kind of tricky social questions,
> > but I hope I showed the danger as a caricature at least.
> >
> > I don't want my arguments be adressed to someone personally, and I'm not
> saying there's some conspiracy here.
> > I just want to help to save and develop the community for the future.
> >
> > I agree we need rules. My problem is not any rules are healthy.
> >
> > вс, 28 окт. 2018 г. в 14:37, Elvis Stansvik <elvstone at gmail.com>:
> >>
> >> Den sön 28 okt. 2018 kl 11:34 skrev Alexey Andreyev
> >> <yetanotherandreyev at gmail.com>:
> >> >
> >> > Hello, Tomasz! :)
> >> > Thank you for the question!
> >> >
> >> > Current draft based on CoC:
> >> >
> >> > > Our Pledge
> >> > > ==========
> >> > > In the interest of fostering an open and welcoming environment, we
> >> > > as contributors to and maintainers of the Qt Project pledge to make
> >> > > participation in our project and our community a harassment-free
> >> > > experience for everyone, regardless of age, body size, disability,
> >> > > ethnicity, sex characteristics, gender identity and expression,
> level
> >> > > of experience, education, socio-economic status, nationality,
> personal
> >> > > appearance, race, religion, or sexual identity and orientation,
> >> > > or any other characteristics that are not relevant to a person's
> >> > > ability to contribute to the Qt Project.
> >>
> >> A lot of people seem to have a problem with this long enumeration.
> >>
> >> I think this is because we're programmers, and we think of it as
> >> redundant given the concluding "[...] or any other characteristics
> >> that are not relevant to a person's ability to contribute to the Qt
> >> Project.", or the shorter list in the KDE CoC, so we instinctively
> >> want to trim the fat - we want to optimize.
> >>
> >> But, and this is of course just my personal opinion/interpretation, I
> >> think the purpose of this enumeration is to list those very large
> >> groups of people in society who are currently experiencing harassment
> >> and mistreatment for who they are. The pledge is supposed to be a set
> >> of guidelines for how the community operates, but *also* a message to
> >> potential contributors. Thought of that way, I think the enumeration
> >> makes sense: We tell a large part of the population who are currently
> >> being oppressed/mistreated that, at least in our community, you can
> >> feel safe. The enumeration is not supposed to cover everything, but I
> >> think it fulfills a purpose by covering a lot.
> >>
> >> I don't agree with some earlier poster who thought of the enumeration
> >> as setting some kind of bar, I don't think that is the purpose of it.
> >> It is meant as a message, and to drive that message home with the
> >> groups of people we want to reach, I think it makes sense to be
> >> explicit. The concluding "[...] or any other characteristics that are
> >> not relevant to a person's ability to contribute to the Qt Project."
> >> is of course very important *as well*, to cover our bases.
> >>
> >> If in 5, 10 or 50 years (I know, I'm a pessimist), there is no longer
> >> widespread discrimination and mistreatment of people for their race,
> >> religion or sexual identity/orientation, but some other groups are
> >> being mistreated (again, sorry for the pessimism), then I think it's
> >> perfectly fine to revise this list.
> >>
> >> I can't really see how this list could be misused. If people have an
> >> issue with a particular item on the list, they should say so.
> >>
> >> That's just my 2 cents on the enumeration, which seems to bug people,
> >> and I completely understand if others see it differently.
> >>
> >> Elvis
> >>
> >> >
> >> > and KDE version:
> >> >
> >> > > We do not tolerate personal attacks, racism, sexism or any other
> form of discrimination.
> >> >
> >> > Do we have any research about effects it leading?
> >> >
> >> > How many discrimination suspicions do we have right now?
> >> >
> >> > How could it be resolved successfully at digital community?
> >> >
> >> > How many misuse examples do we have at open projects since accepting
> similar rules?
> >> >
> >> > How CoC board are going to protect community from discrimination and
> harassment?
> >> >
> >> > Are CoC committee ready for "affirmative action"?
> >> >
> >> > I'm not against the rules as a concept, I agree we need it,
> >> > but I totally against perverted or undefined rules that could help to
> destroy the community.
> >> >
> >> > I could not accept argument like "let's accept just anything and see
> how it goes and fix something later".
> >> > "Don't code today what you can't debug tomorrow" :)
> >> >
> >> > I'm just saying we should think twice befoce accepting something.
> >> >
> >> > P.S.: I'm ready to change my mind if I've made a mistake, feel free
> to criticize, correct and ignore me :)
> >> >
> >> > вс, 28 окт. 2018 г. в 10:47, Tomasz Siekierda <sierdzio at gmail.com>:
> >> >>
> >> >> > The controversial discrimination protection sentences at least
> should be carefully discussed. It's not some thing that we could accept as
> easy as rewrite.
> >> >>
> >> >> Hi Alexey, I've just read the QUIP proposal and couldn't find any
> >> >> controversial sentences. Could you elaborate? Which points shall be
> >> >> discussed?
> >> >> On Sat, 27 Oct 2018 at 22:41, Konstantin Shegunov <
> kshegunov at gmail.com> wrote:
> >> >> >
> >> >> > On Sat, Oct 27, 2018 at 11:20 PM Thiago Macieira <
> thiago.macieira at intel.com> wrote:
> >> >> >>
> >> >> >> The answer to all of those questions needs to be "yes". Anything
> short of that
> >> >> >> means the CoC is powerless and just for show.
> >> >> >
> >> >> >
> >> >> > Which was my point exactly.
> >> >> >
> >> >> >>
> >> >> >> Whether there's a termination of employment or not is out of
> scope, since the
> >> >> >> CoC does not rule TQtC employment and what other work there is
> inside that
> >> >> >> company.
> >> >> >>
> >> >> >>
> >> >> >> Note also it applies to any company. If you're not welcome
> anymore in the
> >> >> >> community where your employer is asking you to do work, that is
> going to
> >> >> >> affect your employment.
> >> >> >
> >> >> >
> >> >> > I agree. However my argument was that the QtC being a major
> contributor to the codebase is going to have to abide by the ruling of the
> proposed committee, which is a significant commitment (and a major nitpick
> I admit).
> >> >> > _______________________________________________
> >> >> > Development mailing list
> >> >> > Development at qt-project.org
> >> >> > http://lists.qt-project.org/mailman/listinfo/development
> >> >> _______________________________________________
> >> >> Development mailing list
> >> >> Development at qt-project.org
> >> >> http://lists.qt-project.org/mailman/listinfo/development
> >> >
> >> > _______________________________________________
> >> > Development mailing list
> >> > Development at qt-project.org
> >> > http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20181028/46d62a5c/attachment.html>