[kde-community] Proposal: KDE Manifesto wording revision

Eike Hein hein at kde.org
Tue Nov 12 16:06:51 GMT 2013


On Tuesday 12 November 2013 16:43:27 Cornelius Schumacher wrote:
> When I read the suggestion and this explanation I wonder why we don't just
> say what is meant: "The canonical version of the project is hosted on KDE
> infrastructure"?
> 
> This doesn't cover the part that all KDE contributors have write access to
> all projects, but that would be covered by the original proposal of  “All
> KDE contributor accounts are granted direct, universal write access to the
> software assets"

tl;dr: Explanations, acknowledgements; new proposal at the
bottom.


I'd basically like to kill two birds with one stone and define
KDE infrastructure as "infrastructure accessible and writable
to KDE contributor [accounts]" (brackets: see further down). I
feel that obviates the need for a separate definition; it
documents the bar infra needs to meet to be considered "KDE in-
frastructure" for the purpose of the bullet.

The problem I see with "The canonical version is hosted" is
the following: It's the goal we have in mind, but it doesn't
aid in implementing that goal. I feel the Principles section
of the Manifesto is less a collection of statements of intent,
but rather more practical than that. The reason I feel it
doesn't aid implementation is because it gives too much leeway
in the interpretation of "canonical". For example, someone
could interpret it as allowing the hosting of auxiliary assets
(say, scripts or utility programs) in locations that don't
meet the infra bar, causing spread, and possibly causing the
canonical location to drift as a result. The proposed wording
is explicit about *all* assets needing to be hosted on infra
meeting the bar. I feel that "canonical" just goes a bit too
far in terms of vagueness.


> I'll give you my feedback here, from when I read the proposed wording for
> the first time: I perceived it as off-putting, because it says "all" and it
> says "must". That feels as a pretty scary statement to me, especially
> looking from the perspective of someone trying to move closer to KDE, but
> not being there yet.

I'm not sure what we can do about the "All", because I think
both instances are very vital to what the bullet wants to
accomplish. I also don't personally feel that it's off-putt-
ing because it's inclusionary.

OTOH, the "must" is strong, and we can possibly do without.



> It also sounds like it would rule out using any other tools, which are not
> hosted on KDE infrastructure. In the IRC log there were mentioned Google
> Docs, Trello, there are certainly more (and not only closed-source ones). I
> don't think we are trying to say that, as that would obviously go against
> the status quo, and the manifest is supposed to document our current view,
> not a future goal.

In the IRC log, I voiced the concern that using "project
assets" rather than "software assets" could be read as
disallowing the use of e.g. Trello for project to do lists.
In the end, for the proposal, we made the decision that
"software assets" being misunderstood as referring only to
code was the bigger concern, but I do think the other con-
cern is valid as well. Aaron's take on this was that he
doesn't feel "assets" inherently covers the use of services.

 
> I guess the reason why I'm perceiving this as excluding non-KDE hosted
> infrastructure is that I read "KDE contributor accounts must have r/w
> access" as "I must be able to log in with identity.kde.org". That's
> obviously not possible with many services hosted by other parties.

Excellent point, perhaps we could address this by removing
"accounts"? The key interest is that the same *people* have
access; the authentication mechanism is indeed an implemen-
tation detail.


Here's a new version:

"All project assets are hosted on infrastructure available
and writable to all KDE contributors."


Changelog:
- "Must" is gone. It's kinda feels more declarative now!
- "Accounts" is gone.

Open issues:
- Do we need to do anything about "project assets"?


Cheers,
Eike



More information about the kde-community mailing list