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

[Aaron J. Seigo]

On Tuesday, November 12, 2013 10:52:45 Peter Grasch wrote:
> On 11/11/2013 06:35 PM, Aaron J. Seigo wrote:
> > On Monday, November 11, 2013 12:16:38 Peter Grasch wrote:
> >> These people can not expected to know that deviating in case of
> >> special considerations is standard practice within the KDE
> >> community.
> > 
> > not at all. the key phrase is "established practices”. so, the
> > established practice of, say, respecting string freezes. yes, there
> > are exceptions to that rule, but those exceptions are codified *in
> > the establishment of the practice of release engineering*.
> > 
> > if a given practice establishes *for itself* exceptions, then those
> > exceptions are part of the “established practices”.
> 
> IIRC, this clause was put there - among other reasons, some of which
> you address - to justify e.g. Necessitas and even Owncloud not
> following a whole range of our "established practices".

i understand that; however, putting that language in the Maneifesto was a poor 
way of gong about it. there are 3 reasons for this:

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.

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.

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"

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

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.

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

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

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

our written policies have things like "Honor KDE coding policies” which states 
that this varies and is documented elsewhere. “if in doubt ask on the mailing 
list” is what it says.

http://techbase.kde.org/Policies/Commit_Policy#Honor_KDE_coding_policies

no reasonable person is going to look at “stays true to established practices” 
and think “well, that’s a faceless set of laws"

> To me, this is a really important
> point and also something that is often surprising to people who
> haven't interacted with FOSS communities before.

i agree that it is a valuable aspect of the community. this particular wording 
in this particular document is not the way to communicate that. why? because 
it will be used in ways we do not want in future.

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

-- 
Aaron J. Seigo