[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-community
Subject:    Re: [kde-community] Proposal: KDE Manifesto wording revision
From:       Eike Hein <hein () kde ! org>
Date:       2013-11-11 12:56:32
Message-ID: 2010632.6lfJsDR8Ls () ehw1 ! ehn
[Download RAW message or body]

Heyo ...

After the exchanges in this and the other leg of the subthread
there ended up being a follow-up discussion on IRC, with Aaron,
Sune (svuorela), me (Sho_) and others contributing.

Ultimately, we've together settled on this wording suggestion:

"All project assets must be hosted on infrastructure available
and writable to all KDE contributor accounts."

Summing up the thoughts behind this:

* This is intended to cover the ideas behind both the original
  ALL and ONLY clauses by specifying that 'all project assets'
  must be on infrastructure that's covered by our contributor
  account system. The way this implements ONLY is by implicitly
  ruling out mirrors that contain additional assets - in other
  words, it's meant to ensure that KDE's repositories are ca-
  nonical for projects, and not outdated. This brings parity
  between what ReviewBoard is doing and what a GitHub mirror
  is doing.

* The new wording hopefully succeeds in being less off-putting
  to readers, to avoid defeating the purpose of the original
  ONLY cause (i.e. we want to successfully pitch/convince
  people to be part of the community, not appear to force them).

* Hosting location is still not nailed down further than "KDE
  contributor accounts must have r/w access", answering a de-
  mand in the original Manifesto discussion.

* "Software assets" changed to "project assets", with Aaron
  acting as a test case for folks having an easier time under-
  standing that this also covers e.g. the Oxygen icons project.

The full log of the conversation is attached, with unrelated
conversation and names stripped as requested (topic-unrelated
reason).


Cheers,
Eike
["konvo.txt" (konvo.txt)]

<aseigo> previous discussions about the manifesto .. well, the manifesto is a living \
document, and there will be new people who come to it <aseigo> the manifesto is \
unlikely to survive if it requires in any way prior knowledge of private discussion \
<aseigo> it is similarly unlikely to "live" if it requires knowledge of prior \
discussion (public or not) <aseigo> a successful document of this sort is self \
documenting, and where there is territory to be covered that can not be \
self-documenting in such a fashion, it is territory best left untrod <aseigo> btw, i \
heard about the extensive discussion through others, but was not part of it myself; i \
was taking a haiatus from kde, something things such as manifesto helped to end .. so \
the theory of 'new voices' is practical rather than theoretical, even if the 'new \
voices' are 'old voices' within kde <Sho_> whoops, I had my notifications for this \
channel disabled ... to cc my reply from #plasma: <aseigo> ah, and i should probably \
note that it is not necessary to know all the discussion that leads up to a given \
part of the manifesto ... <Sho_> [12:21] <Sho_> aseigo: my point with that is just \
that the manifesto is designed to be a cache of previous discussions, so diffs to it \
need to be argued with "why this is better" than "let's discuss from scratch" usually \
imho <Sho_> [12:21] <Sho_> aseigo: but it's difficult to balance people's needs to go \
back to the root of an issue with trying to avoid churn / maintain consensus <aseigo> \
.. rather that the manifesto itself should be understandable without that <Sho_> i.e. \
basically I totally agree ... it's also unfortunate that the previous discussion was \
on the ev list and now we have the k-c list with a wider audience <Sho_> so yeah, i \
agree it's a reasonable concern <Sho_> and i don't mind debating things with friendly \
folks anyway ;) <aseigo> mm.. see, i'm not sure we acdtually agree fully here. the \
manifesto is not a "cache of previous discussions" imho <aseigo> it is the *result* \
of previous discussions <aseigo> but it is not the record of them, not even in cache \
form <aseigo> that is more important than it may seem; if the manifesto is not \
self-documenting then we get the kind of legalistic and difficult to understand (and \
therefore implement) language in the ONLY / ALL clause <Sho_> aseigo: What I mean is \
that when we're faced with a decision, we can base the discussion that goes into \
making that decision on the Manifesto instead of <nada> <Sho_> aseigo: It's a \
discussion aid, it provides a starting point <aseigo> and i guarantee you that in 5 \
years time, all discussion that led to that language will be *lost* <aseigo> yes, it \
is a touchstone document <Sho_> aseigo: Yes, but ... that's exactly why I feel it's \
important to be explicit in the manifesto <Sho_> aseigo: If we lose the ONLY, we've \
lost a part of the Manifesto's utility <aseigo> even if that ecplicit language fails?
<aseigo> again, i think you expect things from the manifesto that it can not deliver
<Sho_> aseigo: It explicitly affects policy decisions we make frequently (e.g. Albert \
and I just this month talked with the Kst maintainers but making Kst \
manifesto-compliant again, and as a result of that it's getting back to having a \
master repo on git.kde.org) <Sho_> if we couldn't have pointed the Kst dudes to the \
Manifesto, .. <Sho_> so I'm not argueing theoretical concerns here
<Sho_> This is practical stuff
<aseigo> if i'm honest, i find coercing people back to git.kde.org to toe a \
legalistic line to be less than forthcoming on our part <aseigo> if the point is that \
we want the "real version" of a project on git.kde.org, let's just say so <aseigo> i \
even suggested this on the list; i'm not sure if you missed it, ignored it, whatever, \
but i did suggest it <Sho_> aseigo: Well that's a matter of how you approach people \
... not "we're the police and this is the law". The legitimacy of the Manifesto stems \
from the consensus-building that went into it <aseigo> it remains that the ONLY \
language does not match what we do now, anyways <Sho_> aseigo: We had a pleasant chat \
with them that lead to the best possible outcome: They're happy to be part of the KDE \
community <aseigo> and on that basis i object to it wholeheartedly as the manifesto \
starts to become an exercise in engineering kde rather than documenting it <aseigo> i \
do not dispute that one can pleasantly manipulate others <Sho_> aseigo: There are \
other bullets in the Manifesto that are significantly more law-like, e.g. the \
sysadmin website access one <aseigo> http://www.thefreedictionary.com/legalistic
<aseigo> there is a difference between "having agreed upon rules" and being \
legalistic <aseigo> there is a difference between overly specific rules that do \
exactly what they say and rules that attempt to socially engineer others <Sho_> That \
I've manipulated anyone is a pretty big accusation, bt <Sho_> *btw
<aseigo> the sysadmin website access point is also flawed, by the by, though for \
different reasons. as a first editon the manifesto was awesome, but it there is room \
for improvement <aseigo> so really, i go back to:
<aseigo> * the ONLY clause contradicts what we currently do right now anyways
<aseigo> * if needed, let us document the gateways for contributor recruitment in a \
purposeful document outside the manifesto (just as the code of conduct does) <aseigo> \
* if there are actual end results we wish to see shored up, let us define what those \
are in specific rather than attempt social engineering cleverness. if there is \
consensus that those results are critical then the manifesto can include them \
<aseigo> iow, if a "KDE project" means that it the "real" (or "canonical") repository \
for that project is hosted on kde infrastructure, then let's just say so <aseigo> * \
removes inconsistencies between the manifesto and our current practices <aseigo> * \
gives us an opportunity to clarify our actual hopes/desires/needs <aseigo> * will \
result in a document that will not be incorrectly interpretted by future generations \
of developers (let alone current ones) <Sho_> Sorry to barge in, but you're missing \
(a) elements of the original discussion and (b) elements of the current discussion \
that lead to the current wording :) <aseigo> you think i am :)
<aseigo> that i did not participate in that discussion is not the same as i am \
unaware of it <Sho_> (a) It's not about hosting on KDE infrastructure - the current \
wording explicitly says "Direct write access" because we didn't want to nail down \
hosting location to avoid precluding things like what we did with Gitorious back then \
<aseigo> a) is a non-issue. KDE defines what "KDE infrastructure" means <Sho_> (b) \
It's not about where the canonical repository is hosted, it's about how the access \
model affects the trust dynamics in the community and contributor success stories \
<Sho_> I'm all for finding nicer wording that accomplishes the same goals <Sho_> \
Simply dropping the ONLY clause, however, does not <Sho_> So we're still in search of \
a better wording <aseigo> how does saying that ONLY kde contributors can contribute \
                to a project improve the trust dynamics?
* aseigo notes that all the costs to the ONLY wording have been happily ignored in \
the thread on the kde-community list. <aseigo> and i have to admit that annoys me. :)
<svuorela> ONLY doesn't cost anything if it is cheap to become a kde contributor
* aseigo puts on his Aaron the Self Repeater hat :)
<aseigo> svuorela: the wording literally creates an us/them wall .. "your project \
only gets direct contributions from other kde people". that is not very inclusive \
sounding in the least <Sho_> aseigo: it improves the trust dynamics because it means \
you can maintain a certain set of expectations against those who directly write to a \
repository (this was written down in one of those mails) <aseigo> svuorela: the \
meaning behind the wording is not readily understandable to others; i've tried it on \
people <aseigo> svuorela: the intention of the wording requires knowledge of past \
discussions whose results can not be codified in the Manifesto without turning it \
into a book on the matter, which means future generations are likely to lose the \
meaning/purpose and that is an existential threat to the "living" status of the \
document <Sho_> that the ONLY clause has costs doesn't mean dropping it doesn't have \
costs either <Sho_> if we find a way to have our cake and eat it, yay
<aseigo> Sho_: yes, it's always cost/benefit. i've been trying my best to address \
both the costs and the benefits as presented. <aseigo> so .. "it means you can \
maintain a certain set of expectations against those who directly write to a \
repository " <aseigo> who is "you" in this case?
<aseigo> the project maintainer? the sys admin team? the user? another random kde \
contributor? <anon> you is all of us
<anon> all of us asume we all of us want the well being of all ofus
<anon> and trust us with direct access
<aseigo> ok, so it's all of us.
<anon> in my interpretation
<anon> don't want to put words in svuorela's Sho_'s mouths
<aseigo> in which case, why do i get to care about who commits to konversation?
<Sho_> let's try some practical scenarios ...
<aseigo> that seems to be something the *konversation* team needs to worry about
<aseigo> not me
<anon> aseigo: that'd mean you don't care about kde as a whole
<anon> just as bits of pieces
<aseigo> anon: no, because i can care about kde as a whole without having to have \
oversight on who commits to every project <Sho_> let's say konversation starts \
mirroring on bitbucket and we grant random bitbucket accounts direct write access, \
and over time, a substantial amount of konversation developers doesn't have a kde \
contributor account and doesn't interact with the wider kde community <aseigo> i've \
mentioned it before, but: we have maintainers <anon> aseigo: you don't have any \
oversight <anon> aseigo: no we don't
<anon> having maintainers is something very few projects do
<Sho_> - does this affect how kde contributors engage with konversation?
<Sho_> - does this affect how konversation engages with kde?
<aseigo> no matter how much i care about okular, i don't decide thing sthat the \
maintainer of okular does <Sho_> - do you still consider konversation a kde project, \
then? <Sho_> the Manifesto is meant to answer the latter, btw
<anon> aseigo: that's a noop you wrote in there
<Sho_> the result of the discussion was "no"
<anon> of course you don't decide things the okular maintainer decides because you \
are not the okular maintainer <aseigo> anon: yep. as i've stated on the list a few \
times, the ONLY clause leads to tautologies <Sho_> (note: the manifesto was born out \
of the owncloud situation) <anon> aseigo: don't think so
<anon> it's a clear statement that all of us are equals
<anon> and if you want to be one of us you have to be one of the equals
<aseigo> anon: right, so who does it matter to who writes to okular? well, the people \
working on okular. if that isn't me, then i am not benefited by that knowledge, \
though i would still care about okular <aseigo> what i *am* benefited by is knowing \
that *should i choose to* i can contribute to okular <aseigo> that is a prime \
difference between the ALL clause and the ONLY clause <aseigo> the ALL clause is \
inclusive and grants privelege <Sho_> aseigo: now it's you who introduces an us vs \
them <Sho_> "i'm not working on okular" means "okular is them, and thsi is me"
<Sho_> which is precisely what we don't want to have
<aseigo> the ONLY clause is exclusive and either implies the removal of privelege or \
it discusses a privelege that doesn't even exist <Sho_> we want to encourage \
cross-pollination between teams <aseigo> Sho_: that is the ALL clause, not the ONLY \
clause <aseigo> and no, it is not an "us vs them"
<aseigo> the FACT that i don't contribute to okular (well, that's not entirely true, \
but let's pretend it is :) is not the same as creating an us/them that precludes \
involvement <Sho_> i think the manifesto shouldn't allow me as konversation developer \
to grant direct write access to kde non-contributor accounts <svuorela> the ONLY \
clause also ensures that I can say to a plasma committer 'please fix it in \
kcoreaddons' and know he can do it. <aseigo> my involvement (or not) with okular \
demonstrates my relationship with okular <Sho_> because I consider Konversation to be \
owned by the KDE community, not by me <Sho_> I'm just at the wheel for a while
<aseigo> by not being involved does not introduce a "vs"; absence can not imply that
<Sho_> which by the way is thinking that's reflected in many points of the manifesto
<aseigo> that's great. and that is the ALL clause
<Sho_> e.g. the trademark and domains bullets
<aseigo> nobody has issues with the ALL Clause
<aseigo> can we agree that we all agree on the inclusivity benefits of the ALL \
clause, and instead discuss the ONLY clause? <Sho_> (none of which i wrote btw, i \
made my battlefield the access model bits ... which means all the other points \
following the same thinking indicate what others in the community think) <svuorela> \
aseigo: they are connected. <aseigo> svuorela: i understand that to you they are
<aseigo> but they aren't in a literal sense
<aseigo> or rather:
<aseigo> i'm trying to get you to explain how they are connected
<aseigo> we can say that the whole manifesto is connected: it's about describing our \
commitments and benefits within kde <anon> aseigo: with an ALL clause it's ok if i \
have an okular repo in github and i consider that repo the canonical repo and give \
write access to people that don't have KDE accounts, i don't think that's ok, that's \
why the ONLY clause is needed <svuorela> whattabout rewording the ONLY clause to "the \
way to get write access to a KDE Project is to get a KDE Contributor account thru \
normal means" <aseigo> so yes, it's all connected; but the ALL and ONLY clause do not \
depend on each other <aseigo> they can be taken separately and individually
<Sho_> i've explained how they're connected
<Sho_> both on the list and in the konvi bitbucket example
<aseigo> Sho_: no, you've explained how the separately contribute to a larger goal \
you have, a goal which is not actually explicit in the manifesto <aseigo> s,how \
the,how they, <aseigo> anon: the way to ensure that is to state that the canonical \
repository must be on kde infrastructure <anon> aseigo: and then we have to update \
the manifesto when we decide to move to github <aseigo> it's more direct and less \
likely to get lost in translation in 5 years time <anon> which seems weird
<aseigo> anon: again, no
<Sho_> aseigo: well, ok. then it doesn't matter that they're not connected, they \
simply have to both be there. <aseigo> KDE defines what "KDE infrastructure" means
<Sho_> aseigo: oh and the larger goal is super explicit in the manifesto btw
<Sho_> go to page one
<Sho_> "shared ownership"
<aseigo> the Manifesto does not duplucate the code of conduct; it just references it
<aseigo> the Manifesto does not redefine who the sys admin team are, what they do and \
how they get their mandate, it just references it <aseigo> the Manifesto can be seen \
as "connective tissue" between different parts of "what matters to KDE" <aseigo> \
Sho_: shared ownership is achieved with ALL <Sho_> No, it isn't
<aseigo> and before i answer a single one of your further objections, please do me \
the respectful kindness of answering a question i keep asking and you keep dodging: \
<Sho_> Because it doesn't enable shared ownership for the folks with direct write \
access to Konvi who don't have a KDE contributor account <Sho_> None of those enjoys \
shared ownership over non-Konvi <Sho_> None of those is encouraged to share ownership
<aseigo> ONLY is not reflected in what we do already (e.g. reviewboard); how do you \
justify having a statement that contradicts what KDE does right now? <Sho_> It \
doesn't <Sho_> The statement specifies direct write access
<Sho_> ReviewBoard isn't direct write access
<aseigo> good, that's step 1
<aseigo> step 2 is:
<Sho_> Look, the thing is that it's a complex matter, and complex matters are \
difficult to write down in simple language <Sho_> I sure hope we can find nicer \
language <Sho_> But pretending the matter is less complex doesn't help that
<aseigo> having a repository on github that clones into git.kde.org requires someone \
with a kde contributor account to proxy the changes in <aseigo> so either github -> \
git.kde.org does not violate ONLY, or reviewboard does <aseigo> they are the exact \
same thing <aseigo> were i the kstand people, i would have pointed that out to you
<Sho_> Ok, so here's an alternate approach then
<aseigo> er, kst.. not kstand..
<aseigo> (stupid paste shortcuts on this keyboard ...)
<Sho_> Ignore style, focus on substance: "All KDE contributor accounts must enjoy \
direct write access to all software assets" <aseigo> no no... before we go to \
alternate approaches <Sho_> The key addition being 'all'
<aseigo> i would like some acknowledgement on the reviewboard issue
<Sho_> Since it precludes having an out-of-sync mirror that's out of sync in the \
sense of containing more assets <Sho_> aseigo: That I'm suggesting an alternate \
approach is a result of acknowledging your point <Sho_> I'm not convinced it's \
psychologically the same, though <anon> aseigo: reviewboard is not an issue, \
otherwise you'd say people posting emails with patches is an issue <anon> which is \
not <aseigo> anon: yes, i agree. that's the point, though. they are not an issue. \
apparently github is (and i agree that it is). so if email/reviewboard is fine and \
github is not, but they both "violate" ONLY in the same way .. then it is not the \
ONLY clause that is the root issue <Sho_> anon: Allow me to translate: Aaron's point \
is that "people write to mirror, someone wit gitko rw access syncs over" is identical \
to "people write to ReviewBoard, someone with gitko rw access syncs over" <Sho_> \
That's technically true - I don't think it's psychologically true <aseigo> anon: the \
goal then becomes to find what the *actual* root cause is and document *that* instead \
<aseigo> Sho_: i agree. <Sho_> which is why Aaron is championing the "where is the \
canonical repo" clause <aseigo> what you call the "psychological truth" is what i'm \
refering to when i write "the root cause" <Sho_> Yeah, I know
<Sho_> You're getting through
<aseigo> the problem with technically innacurate wording in the Manifesto is one day \
all that will be left is the wording <aseigo> you and i will be gone and our \
brilliant dialog ;) will be gone with it <aseigo> so we have to achieve our root \
cause / psychological goals without digging traps for ourselves <aseigo> mostly that \
just means defining what the root issues actually are and documenting them directly \
<aseigo> so .. "all software assets" <aseigo> yeah, that sounds good
<aseigo> (to me anyways ...)
<aseigo> it's inclusive, it phrases it in a positive manner and can only be satisfied \
by having the "canonical version" of the software open to kde accounts <Sho_> aseigo: \
"All software assets must be hosted on infrastructure available and writable to KDE \
                contributor accounts."?
* aseigo reads and gives it a moment to sink in.. it sonds great on first read .. let \
me grab a new tea <aseigo> "All project assets must be hosted on infrastructure \
available and writable to all KDE contributor accounts." <Sho_> aseigo: If we manage \
to agree on something, I'll write a mail reply to the list presenting it, with an \
explanation and the log attached (no hurries, just idly thinking ahead) <aseigo> \
software -> project .. to cover art projects (e.g. oxygen icons) <aseigo> to KDE -> \
to all KDE .. just to be super duper explicit about that <Sho_> aseigo: That's \
actually why "software assets" was chosen for the original wording, too :) <Sho_> but \
project assets is fine to me too <Sho_> And I agree about the +all
<aseigo> yeah, i hesitant about the "software assets" thing as well
<aseigo> in the original manifesto, that is
<Sho_> aseigo: The problem with "project assets" is that it disallows a team trying \
out trello or so <aseigo> we already have non-software projects, and projects with \
things like documentation (no, really! ;) <Sho_> theoretically you could even \
disallow Plasma's use of Google HAngouts and Google Docs <Sho_> I think "software \
assets" might be more reasonable <aseigo> ah, a definitional issue
<Sho_> I mean, yes, we want key docs to be around, too ... but I think that happens \
socially due to the editing tedium if they aren't <aseigo> is this about content that \
makes up the project, or services the project uses to create that content? <Sho_> \
aseigo: What I mean is, I'm not sure we care about "KDE projects can't use Trello \
becase Trello doesn't have identity.kde.org support" <Sho_> But it's tricky
<aseigo> ah, no, we don't :)
<aseigo> but "a project's assets" are the content that make up the project, not \
random services a project team uses to create them <Sho_> I think "software assets" \
gives a bit more leeway since it definitely covers what we care about (code, icons, \
key scripts) <Sho_> but leaves the rest a bit more flexible
<Sho_> aseigo: yeah but project todo lists (e.g. trello) are definitely project \
assets <aseigo> ok :)
<aseigo> well, i would define project assets as things that ship as part of the \
product <Sho_> aseigo: I just think we don't really need to worry about that because \
if you can't fidn a project's todo list, the project has a problem anyway, so there's \
already pressures on projects to make those kinds of assets available <aseigo> \
support services (and the content in them) used by the team should be covered by a \
separate item if covered at all <Sho_> aseigo: right ... well, I'm fine with both \
software assets and project assets, i don't think the world will burn with either \
<Sho_> so if you have a preference for one way, I'm not going to object <aseigo> \
Sho_: yes, i'm thinking more about projects like oxygen icons which has no software \
at all <Sho_> aseigo: yeah but back then we decided that "software assets" reasonably \
covers icons because software is more than code <aseigo> either is fine; i lean \
towards 'project' due to its lack of project type specifics <aseigo> but yeah, it's \
not a key issue <Sho_> aseigo: "we want to cover oxygen" was exactly the talking \
point back then <Sho_> but, if "project" meets that end better, why not
<Sho_> aseigo: Ok, I'll write an email and pastebin the draft before I hit Send, \
sound good? <aseigo> Sho_: sure
<Sho_> aseigo: hm, i'm still faced with some uncertainty, though ... I'm not sure \
there's a strong-enough force acting to make the KDE repo canonical in terms of \
mindshare, just because the Manifesto forces people to keep it up to date <Sho_> \
aseigo: draft is http://pastebin.kde.org/payqzs4qk/ou2pqc, but I'm still concerned \
we're not meeting the goal <aseigo> Sho_: i agree; but imho that's an issue best \
addressed as part of a bigger strategy .. <Sho_> aseigo: right, you don't want the \
Manifesto to be off-putting to avoid people not /wanting/ to be part <aseigo> e.g. to \
buiidl value in people's minds about kde infra <Sho_> aseigo: I get that, it's just \
supertricky stuff <Sho_> but well, let's roll with that for now
<aseigo> +1 on the email
<Sho_> aseigo: http://pastebin.kde.org/pqtwvs56e/czjeuc < rev2, bullet #2 is new
<aseigo> second point is important, thanks for including it



_______________________________________________
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

[prev in list] [next in list] [prev in thread] [next in thread]