[oi-dev] OpenIndiana Code of Conduct

Nikola M minikola at gmail.com
Sun Jul 24 09:09:24 UTC 2016


On 07/23/16 11:27 AM, Peter Tribble wrote:
>
>
> On Sat, Jul 23, 2016 at 6:30 AM, Nikola M <minikola at gmail.com
> <mailto:minikola at gmail.com>> wrote:
>
>     On 07/22/16 02:00 PM, Peter Tribble wrote:
>>     Overall, I'm happy with most of this. It's about the right
>>     length, as well.
>     What are you actually happy with?
>
>
> I'm happy with the original document that Adam posted, with the caveat
> that I
> think the reporting mechanism can and should be tightened.
>  
>
>     I can say I could be happy with the first affirmative part, that
>     is from the time of original posting changed, but not the second
>     part with restrictions and secrecy.
>
>     Have you seen working version at:
>     http://wiki.openindiana.org/pages/viewpage.action?pageId=31391953
>     because document is edited in open, not in closed and on Wiki
>     instead on the site.
>
>
> Indeed I have. Your modified version is flawed in the following ways:

I hope I explained in good words why changed version is much better, I
thank you for contribution and please add more if you want more things
to add etc.

>
> 1. The title has been changed. "Code of Conduct" is the normal term,
> use it if that's what is intended

Normal term is what we choose to use.
We have SMF, for example and that is "normal term" for us, so we have a
freedom to call it how ever we want. So there is no "normal" term at
all. is using Linux "normal", then what we are doing here then? We can
differ and will.
So we can choose whatever wanting, and I have put "Core Principles and
Expectations", because it more suits the need, beter explains use and
contents and yes, it is "different" from the rest of the world that is
"normal" and using Linux...
Of course if someone thinks web page link could be differently named or
also putting it by another, more known name, too, it can be done, but
no, we don't have to be "the same".
Oi already have myriad of differently named terms that use similar but
not the same thing as other systems.
We need to have a space to inovate including out own terminology and
meaning of it etc.

> 2. It conflates operational procedures and etiquette with conduct.
> (There may be
> a place for a "how we operate" document; this is not it.)

That is right. Good that you mention it.
Core Principles and Expectations (CPE) (or CoC) is there for community,
as general showing fo values that can be used to benefit community en
large, precisely avoiding unneeded restrictions, wording that could turn
people away or even managerial parts.

Actually when having good text there that makes managerial (operating)
document(s) much easier to organize and puts less work on shoulders of
operating people on all levels.
Separate documents can describe operations, yes and there is no room for
pushing them into this document.

Actually, CPE provides good environment and positive attitude stating
values. It is unfortunate actually to even mention any procedures in it,
but they are mostly relaxed for operations to have less work to do and
that EVERY community member, even not yet member of some working group
or active member, can use CPE to operate communication in most positive
way right ahead.

> 3. It does not make clear what is not tolerated (the list Adam gave
> covers the
> problems we see much more accurately)

There is absolutely need for such harsh wording in Openindiana
community, nor turning against people.
_Everything is tolerated_, if it does not conflict with Core Principles
and Expectations.
And it is very easy to find out if something conflicts, comparing with CPE.

As things are best to be growing organically, they are much better as
gaining more experience, also people react much better to positive and
supporting principles and create healthy environment.

It is obvious that as put firstly, "nontoleration" part is turned
against itself, too and (forgive me if I am repeating myself) whole that
nontoleration section is Trolling heaven and can't come back.

Nontoleration and exclusiveness can't mix with toleration, inclusiveness
and OI community. Just seeing "non tolerable" part in text induces wrong
feeling that contributing is all about power. It is not, it is about
principles.

> 4. It does not provide a mechanism to manage violations. Such a mechanism
> should be confidential. (Confidential, not secret.) Why?

Of course it provides it. For starter there are NO 'violations' as term
so no need to manage them.
Hence, less chance to even have any problem.

'Discouraged behavior' part should actually not be needed, and document
can function nicely without it, but it mentions few things.

And 'Managing misuse escalation' is what you are looking for.
It separates that channels of communications can have somewhat different
requirements, that there could be groups to self-organize and that there
are many different maintainers of various parts and channels, that
should manage those parts.
So no centralization per se and no bumping one's head all the time by
the same people, no policing, Everything nicely explained and allowing
everyone to take a role in the community at any time, like community of
equal it is.

>  a. Problems can become acrimonious and turn into a flamewar

Discussing is never a problem. Discussing a lot is also not even a problem.
Complaining about a lot of discussion and talking IS a problem and is
discouraged.
Saying "stop talking" is not benefiting community, because it supports
doing things in closed doors.

Following CPE will never go to problems, because staying on topic and
not falling into personal things, quickly solves it. Everyone is always
free to propose solutions including solutions to compromise and/or more
quickly find important points on topic.

>  b. People should be comfortable to report problems without fear of
> retribution

Completely agree. That is why they should do that fully _in public_ and
not secretly, beside closed doors and not actually seeing what is going on!

I don't know what 'retribution' one would be need to be feared from?? In
an open and cooperative community, even inducing word 'fear' (as part of
FUD..) is unneeded.
One can fear of something he/she do not know, but if everything is in
open there is nothing to be fear of.
That is exactly why Free software and Open source is releaving anyone of
fear of inclusion of malware etc, the same way having nice, public talk
is way better.
Working things in shades is also against growth and bigger inclusion of
people.

>
> 5. It fails to provide adequate attribution

I didn't  uderstand firstly what you meant by this. Attribution is in
distribution code contribution logs.

I suppose you are thinking about other communities and their documents.
Well, yes, we have our own community, and attribution parts in program
source or articles and is maybe good thing for cross-platform cooperation,
but this is one of core OI documents and we really don't need to
- copy things from others without need
- point to competition like we can't do it by ourselfs
- Attribution belongs to those writing it in OI and document as it is
does not reuse any part of other distro's documents like it is now.  It
is rewritten so it is NOT derived work, and that is also important to
mention.
- Making sure people see we are as community capable of making our own
documents, for being unique community that others can look upon :)

If it is needed for hitorical reasons or something, there are always
memoires, personal blogs, I dont' feel the need for that atm,
but i feel the need for the contribution.  :)

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


More information about the oi-dev mailing list