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

[Peter Grasch]

On 11/12/2013 06:35 PM, Aaron J. Seigo wrote:
> 1) where exceptions are appropriate, they are encoded into the individual 
> descriptions of “established practices”. we have a commit policy, for 
> instance; it probably has exceptions to its guidelines. those exceptions 
> belong in the commit policy, not the Manifesto. since those exceptions are in 
> the commit policy, they are part of the established practice of the commit 
> policy, and therefore the Manifesto does not need to add yet another “escape 
> clause” on top of that.
Agreed.

> 2) the point of enumerating the attributes of a “KDE Project” is to ensure a 
> certain continuity amongst those projects. if we want to be permissive and let 
> anything go, we don’t need a Manifesto, a Code of Conduct or even a commit 
> policy. as we agree those things have utility, we need to be willing to accept 
> that there may be projects that will not demonstrate the necessary attributes.
Agreed.

> 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
faceted as a full software development cycle just can't be adressed in
detail in half a sentence.
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".

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. 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.
No, we can't give a list of valid considerations but that doesn't mean
there won't be any that warrant exceptions. 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.

>> 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.

Saying that there can be special considerations doesn't lock us into
granting exceptions all the time. This would be akin to saying killing
people is legal because it is in certain specific circumstances
(self-defence, for example).

> being overly permissive leads to there being no identification of “KDE” and it 
> is exactly that community and culture that leads to a group of diverse 
> projects being able to work together.
Agreed.

>> I don't think that the clause as it stands today can really be seen as
>> a "wildcard" for projects to do what they want. (And, afaik, this also
> 
> then what are the boundaries of “special conditions"?
If we could anticipate them, they wouldn't be all that "special".
So, to answer your question: to be determined on a case by case basis.

>> hasn't been a problem as of yet but please correct me if I'm wrong here.)
> 
> you don’t buy insurance after your house burns down. the Manifesto has not 
> been around long enough for it to become an issue, but it is plain to see how 
> it can and will be.
Obviously we should be proactive but I want to point out that the fear
of people "exploiting" the Manifesto is not just unfounded in theory (as
it's not a binding document) but - so far - also in practice.

>> What these few simple words do signal, however, is that while we do
>> have rules, KDE is a community of human beings that can be talked to
>> instead of a faceless set of laws.
> 
> "The project stays true to established practices common to similar KDE 
> projects”
> 
> how can you claim that that is a faceless set of laws? it doesn’t even use the 
> word “policy” but rather "practice.
Okay, this may have been harsh language on my side. This is not what I
meant. I apologize.

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".

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.

>> 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).

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?

Best regards,
Peter