[kde-community] Discussion: KDE Manifesto, "established practices"

[Aaron J. Seigo]

On Tuesday, November 12, 2013 21:45:40 Peter Grasch wrote:
> On 11/12/2013 06:35 PM, Aaron J. Seigo wrote:
> > 3) if there are undefined escape clauses in the “what it means to be a KDE
> > Project”, even if we don’t intend them to be used in that manner, people
> > will use them to justify behavior that we explicitly do not want. they
> > will point to the Manifesto and say “well, you guys said that if there
> > are special considerations .. and we have them”. the “special
> > considerations” clause is a trap dug for ourselves that will be used by
> > the very sorts of projects the Manifesto ought to help us identify as
> > “not belonging to KDE"
> 
> Disagreed.
> Actually, any person that takes whatever we may write so literally as
> you are portraying in your email will always get it wrong. Something as

there exist people who are not as pedantic as the one you describe who will 
use it in exactly that fashion.

i’d prefer not to trot out dirty laundry from the last 10 years of the KDE 
project to prove my point. please, just trust me on this one: such people do 
exist. it will happen. how do i know? because it has happened.

when it happens, it tends to occur in times of crisis and stress which makes 
it too late to adjust things retroactively with any useful effect. i have sat 
across too many tables from too many frustrated, angry and feeling-like-
they've-been-betrayed people over the years to want to build new ways of 
generating such situations. 

i wanted to see something like the Manifesto specifically because of two 
different projects that pushed boundaries and claimed “special considerations” 
within months of each other (in completely unrelated cases), causing huge 
issues within the community. i ended up spending literally dozens of hours on 
the phone with people and meeting in-person with them to help resolve those 
issues. once completed, i left active participation in KDE e.V. because i had 
had enough of cleaning up messes due to KDE not having the temerity and the 
honesty to set proper boundaries for itself. we fear losing opportunities SO 
MUCH, perhaps because KDE we lack confidence in ourselves, that we create 
situations which actually result in KDE losing opportunities it once had.

this “special considerations” clause is simply classic KDE. and not in a good 
way.

> faceted as a full software development cycle just can't be adressed in
> detail in half a sentence.

the new language doesn’t attempt to do so. nor does it need to. i think we’re 
starting to miss the point here.

the question is do we:

a) put an undefined escape clause in the Manifesto that covers all practices?

or 

b) reference that we have practices defined in the Manifesto that are expected 
to be upheld and leave documenting exceptions to the documentation for each  
specific practice?

the benefits of (b) are:

* we don’t need an exhaustive list of exceptions (or to keep them up to date)
* there is no cart blanche “do whatever” clause available for misuse

to evaluate the utility we should look at this from three use cases:

1) New project coming to KDE seeing if KDE is the place for them.

2) New project understanding what they are committing too and getting in 
return

3) Existing project examining the boundaries of acceptable actions

in *none* of those cases can imagine anyone reading ""The project stays true 
to established practices common to similar KDE projects” and thinking “well, 
aren't they just a bunch of fascists!” 

so the remaining issue is: will new projects evaluating KDE read it to be too 
restrictive? let’s read it in light of the third principle:

"Inclusivity to ensure that people of all origins are welcome to join us and 
participate;”

also note the use of “similar .. projects”. if my project is unique in some 
way .. well ...

so i think it is unlikely to turn projects away in any great number. and i 
expect the most common way this document will get used for projects evaluating 
KDE is by being pointed to it by someone who is associated with KDE, which 
will help with possible questions.

now .. if we have the “special considerations” clause, we will fail for cases 
2 and 3 above.

a new project will enter KDE feeling that they don’t really need to follow 
established practices; they are all just kind of suggestions which you ignore 
when you have a reason to. that does not happen to be how KDE works. by 
leaving in “special considerations” we will be creating false expectations and 
asking people to commit to things under false pretenses.

n the other case, an existing project looking for the boundaries is likely to 
take hold of the “special considerations” clause and use it as justification 
for actions that would otherwise not fit. note that when projects look for 
boundary setting, it is usually when things aren’t going well. clarity and 
truth is paramount at such points in time.

> I could just as easily argue that the new language would have caused
> e.g., the Necessitas people to go "ah, we can't conform to the
> established practices so we obviously can't be a KDE project".

any language in the Manifesto that carries any restriction can have that 
effect. i understand that you are trying to ensure that we don’t lose out on 
opportunities. but we also need a document that is useful.

the Manifesto *will* create a wall between “KDE” and “non-KDE”. that is 
actually the point of it: to help define what KDE is. in fact, that wall 
already exists right now, but it hadn’t been well documented previously. as a 
result we *did* lose out on opportunities. i would like the documentation of 
that boundary to be accurate, however, since telling people “no, you can do 
whatever you like as long as there are special conditions* (*undefined)” is a 
lie.

there do happen to be some hard rules within KDE for which there is no special 
condition exception.

> This, actually, nicely brings me to my point: Because the meaning behind
> that point is complex, we should err on the side of caution on making it
> too restrictive. 

“special considerations” does not make it less restrictive, it makes it 
dishonest. not all established practices are mutable. there is no way of 
making that clear with brevity in the manifesto, either.

> The ambiguity in the original language is imho an
> *advantage* because it is indicative of the actual practice: special
> considerations may arise that are to be treated on a case-by-case basis.

this can be, and is, documented in the procedures and policies documents.

> No, we can't give a list of valid considerations but that doesn't mean
> there won't be any that warrant exceptions.

simiarly: just because we don’t explicitly note in that exact place of the 
manifesto that there aren’t exceptions, this does not mean they don’t exist.

> We’ve  done it in the past
> and will do it again. What is important is that there is *communication*
> - something that a strict wording imho hinders.

again, i don’t think the wording is strict. “stays true to”, “practices”, 
“similar .. projects”. 

> >> It was my understanding that attracting such diverse project to the
> >> KDE umbrella was recognized as being in our best interest and
> >> something we want to encourage.
> > 
> > we want to attract a diversity of projects, but within principles that
> > have
> > gained consensus over the years and become part of KDE’s culture.
> > 
> > we do exclude projects even now: we could attract more projects by
> > dropping
> > the Free software requirement.
> 
> You misunderstood me here. I'm not saying we change our policies and
> become more open toward potential "special considerations" in the
> future. I'm saying that keeping the clause as we have it now better
> indicates our actual practice.

it actually doesn’t. our *actual* practice is that many practices offer broad 
lattitude; some don’t offer any; and most require a community process to adjust 
them. there is no way to wrap that up in half a sentence in a way that is 
understandable. the Manifesto can not reflect every nuance of KDE, nor does it 
need to; it simply needs to provide the broad brush strokes within which all 
the details, which are too numerous to grasp quickly, fall.

the Manifesto is a summary. it must also be an accurate summary.

> Saying that there can be special considerations doesn't lock us into
> granting exceptions all the time.

in times of crisis, people will argue *exactly* that.

> > then what are the boundaries of “special conditions"?
> 
> If we could anticipate them, they wouldn't be all that “special”.

precisely why we shouldn’t reference them in the Manifesto.

> So, to answer your question: to be determined on a case by case basis.

this is already covered in the manifesto principles, #1 of which is open 
governance.

> Let me try to explain what I mean: Suppose there is a project team that
> considers moving to KDE. They like the community, agree with the
> principles, etc. However, they want to do X (where X is against our
> established practices).
> Now here's what I personally would like to see happen: The project team
> reads the manifesto and sees the clause. They then look up our policies
> and discover that X does not fit in. However, they do need to do X
> (because of technical reasons, their employer or whatever). They then
> *get in touch with us* to ask what to do about this.
> 
> Note that I did not say that an exception for X should be granted or not
> - that's not the point. It's the "getting in touch with us" part that
> I'm worried about.
> A strict interpretation of "The project stays true to established
> practices common to similar KDE projects" makes the step of getting in
> contact with us completely unnecessary: it's clear that the answer must
> be "No".

you started this email by saying nobody would be so pedantic and then you 
propose a scenario where the person is pedantic. :/ i can’t address such an 
issue.

yes, i grant it is theoretically possible to lose such a project.

i would suggest it is more likely that someone who is interested enough to 
read the Manifesto, understand it, then research policy and practice specifics 
would get in touch with us rather than go away silently.

> In short: I don't think we should give up the kind of wiggle-room that
> our current language gives us. We can always say no to "X". I'd just
> like to know what "X" is before we do it.

yes, we can always say “No”. the damage caused by doing so can be extremely 
high without the proper frameworks to support it.

the code of conduct, the manifesto and the various policies on 
community.kde.org provide that framework. one reason we have such documents is 
so that we don’t have to say “No” nearly as often (people self-regulate) and 
when we do have to say “No” we have agreements in place that we all agreed to 
*before* we got into the position of having to say "No"

> >> But maybe this is just me misinterpreting it, so let's stay with a
> >> practical example: How would Necessitas be justified under the KDE
> >> umbrella given the updated language?
> > 
> > which established practices did Necessitas not follow?
> 
> I would argue that "Use kdelibs" would be an "established practice" in
> KDE but I recognize that there was/is some disagreement as to what
> "practices" this clause is referring to (even in the initial discussion
> of the Manifesto).

“use kdelibs” is not an established practice. we know this due to the 
libraries we host which do not use Qt, the websites which do not use Qt, etc.

if that is the only concern, then the answer to “How would Necessitas be 
justified under the KDE umbrella given the update language?” would be: it 
doesn’t impact Necessitas at all.

> Maybe our disagreement on the wording is down to different
> interpretations of "established practices"? Did I maybe miss the list of
> practices this applies to?

there is no list that i am aware of. nor does there need to be one: one pairs 
up the task with the practice. e.g.:

* how does committing work? there’s a policy for that
* how is internationalization handled? there are guidelines and technical 
methods for that, maintained by the l10n project
* what colour scheme do i have to use? there is no established practice for 
this, so this is not relevant

hopefully community.kde.org can serve as the gateway to information on these 
practices, obviating the need for an explicit list.

by avoiding an explicit list we avoid having to keep it up to date.

-- 
Aaron J. Seigo