[oi-dev] OpenIndiana Code of Conduct

Nikola M minikola at gmail.com
Thu Jul 21 06:27:38 UTC 2016


On 07/21/16 02:31 AM, Michael Kruger wrote:
>
>
> Just as the formulation of a mission statement, road map, and a core
> governance team help to show the community and world we aren't just
> aimlessly trudging on in some unknown direction, the CoC is simply
> another tool to provide structure and governance to the project. It's
> goal is to help unite the community under common goals, aspirations,
> and in this particular case, 'working conditions'.

Take a look at provided evolved text here:
http://wiki.openindiana.org/pages/viewpage.action?pageId=31391953
http://wiki.openindiana.org/pages/diffpagesbyversion.action?pageId=31391953&selectedPageVersions=5&selectedPageVersions=1

Openindiana Core Principles and Expectations - CPE (CoC) is not statue
nor it's role is to provide 'structure and governance'. Not everything
rotates over power. At the end of the day, people can be asked, and
politely, to think in a certain way, can not be forced into it.

Governance and power should not be the issue in a working community,
only dysfunctional elements need power and see power as important thing,
chasing new rules as a vessel to achieving power as a goal and not
something else.

It is symptomatic that injecting false and bad and broad rules into
community, and actually not talking about rules text themselves, nor
discussing them, can not be looked at as positive behavior, but as
intentionally dragging all things along, without actual interest on
benefits of them but power to begin with.

Rules in a community as stated should not rotate over excluding people,
but over better ways of including them, facilitating growth, not
destruction, and that is more important then policing any possibly 'bad'
one, with all problems related to actually enforcing power over people.
Proposed "not tolerated" part, being wide and easy to misuse, with
"cutting down" narrow-looking principle can't work in present state of OI.

Maybe most important things I would liek to point out are:
- Putting things on site without discussing it first is bad behavior
- Misusing public opinion without making sure it is not rigged (poll) is
a bad behaviour.
- Activating "Core principles and expectations"/"CoC" without previously
having governing body is not possible.
- Having governing body without firstly having named active community
members to elect it, is not possible.
Having poisonous rules is worst thing that could happen to one community.
It is better to avoid future problems then to make a new ones instead.


Why these parts are bad and unacceptable by themselves:

> What will not be tolerated:

Section name imposes that there are those who are asked to police others
and are in the position to segregate people into those those tolerated
or not. It is there as said to induce "fear and strength" into bystander
and not to provide positive look into community.


>     Open hostility, and or abusive language.

These terms are so broad that they are easily misused. Open hostility
can't be defined as and exact term (toward what, how to recognize it
opens pandora's box of misinterpretations.
"Abusive language" also means nothing at all, because any language
people use, if it is on topic and can explain what people want to say is
acceptble in widest terms. Not everyone express their thoughts in the
sam manner, maybe sometimes, someone swear or something, but not being
able to identify exactly what this sentence is about, does help not
seeng it is useless.

>     Repeated complaining (rehashing) of closed (decided) issues.

This again opens presumption that there is some "higher being" knowing
everything at any time and that "complaining" is a problem.
Subset of complaining is a bug reporting. Or subset of bug reporting is
complaining. If one enters same problem or a bug day after day, and
others enter the same problem it is only positive to hear complaining.

What are closed issues? In a working community there is no putting
things under carpet. Again, calling that omnipotent power who by itself
knows what issues should be closed and what issues should be not? Again
it imposes ruling one against everyone else who "decides" and carve
things into stone, when exact opposite is needed, to be flexible and
evolving.

>     Participants who disrupt the collaborative space, 

Again not defining anything, but entering more broad things like "you
have spit on the sidewalk, you are disrupting collaborative space" or
"you dont' wear pink unicorn t-shirt like everyone else, you disrupt
collaborative space", "you post too much messages/code/text/ideas, you
disrupt collaborative space" and so on..
Please DO disrupt collaborative space at all times, by being active and
sharing with people.

> or participate in a pattern of behavior which could be considered
> harassment.

Again, loose terms meaning nothing: "you posted same sentence twice. you
posted same sentence twice " - you have pattern behaviour, on the
cross/fire with him/her!
"Consider harassment" is again not only broad but also very bad to
include, because every single person can just make up "harrasment this
and harrasment that" and call it, and it can only present endless debate
or as seing in practice, it actually induces again "higher being from
above who know what" that would decide on everything instead of people,
because, you see, terms are vague and broad to facilitate it. Being
active or for or against something is not harrasment.. But then why make
a huge list of "not a harrasment" over long time in a painfull process?
Let ditch the unprecise word in the first place.

>     Filibustering – (replying with negative or opposing viewpoints to
> every post in a mailing list thread).

Another one that is not being able to be defined by any exact means. It
can cripple community of their active parts where just simply discussing
a lot, where it is only a _natural_ thing to support something or oppose
something else is seen as the problem.
It could be looked at like this: "There is the need for all rules of
mighty lord go smoothly" so making a vessel to just badly label everyone
else who oppose the "Mighty lord" "wisdom words".
Or saying "you oppose dogmas too much often" oh no faithfull one, you
must burn".. Does not sounds like a community..

> Reporting violations:
>     Violations of the CoC should only be reported to the maintainers
> via direct messages on IRC, twitter, or via E-mail and will be handled
> confidentially.
>         Neither reporters nor reported persons will, or should be,
> made public.

I strongly oppose of doing things privately and silently, without anyone
knowing. It sounds like legalizing conspiracies and working behind the
backs. Also it presents great position for false accusations all in the
intention of possibly putting harm without even need to know who's the
one segregating people etc.


All 7 broad things plus dissected here are actually poisonous to
Openindiana community.
And that is what exactly being most poisonous is: supporting poisonous
'rules' that would facilitate more poisonous  acting in the future, e.g.
destruction to Openindiana community before it has even started to grow.

At the end everything boils down to not having a vision of the future
and not thinking enough of consequences.


Those got replaced with:

> Discouraged behavior :
So saying, these are not written in the stone, don't fear just pay
attention.

>     No personal witch hunt, based on anything toward a person(s).

Rules are not against 'certain people', rules are not to be misused to
attack people (!)

>     Advocating unsubscribing, other person removal, restrictions,
> filtering or personal negative public announcements.

You should not do that, but recognizing no one can stop you to, it is
important to have it somewhere to be pointed to. Accepting people are
also changing themselves by themselves. Keep one's personal decision to
him/herself is a good manner. (Also recognizing that can't be avoided at
all times).

>     Not recognizing critique as the source of inspiration to make
> Openindiana better.

Maybe most important one - don't burn the messengers. Accept every input
as valuable contribution, even if it is missing the point, it is
valuable information of how people see things to make things more smooth
in the future. If it is repeated - it is better, it is seen as recurring
pattern to take into account, not to fight against it.


> Managing misuse escalation:
>
>     Point new and existing community members to Openindiana principles
> and expectations.
>     Inform and message community members to self-regulate it's own
> behavior.
>     If you feel needed, consult others about ways of accepting new and
> modifying existing behavior of community members.
>     If you find it important, contact IRC Channel operators, Mailing
> list administrator, Web site maintainer, Wiki editor and Project
> maintainer.

This is how things are get done by the community, in open , gradually,
fixing issues while walking incommunity, empowering everyone to act and
do things in managing.
Having very low actual percentage of (if any) issues ever reaching the
level where they need to be dealt with.
Also separating channels themselves with their own ways of doing things
with general 'rules'.
it is also regared to be dealt 'per project' and there could be large
number of projects themselves.

So in contrast of hard-line bumping hands on the desk, wasting energy,
there is kind act of recognizing benefits in anyone who is positive
toward project.

This all reminds me in difference between the sword in the river that is
so sharp that cuts every leaf in half that comes floating by the stream.
Instead, sword should be so sharp that no leaf is cut, but floating just
beside the sword.

So avoiding possible issues instead of continuously battling them or
making the new ones with no reason.
That is true saver of the energy and time - being more open and positive.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20160721/396588aa/attachment-0005.html>


More information about the oi-dev mailing list