[kde-community] Proposal: KDE Manifesto wording revision

[Eike Hein]

On Monday 11 November 2013 10:10:56 Thomas Zander wrote:
> Could you please explain to those that don't immediately spot it how the
> before and after are functionally different?

Of course.

There's two halves to the access model:

* All KDE contributor accounts must have direct write access. (There
  is some debate about this wrt/ what it means to review processes,
  so think about this in terms of technical means, not the social
  etiquette around committing.) That means it's not allowed to host
  your code at some place that wasn't enabled for this. git.kde.org
  is an example of infrastructure that is enabled for this access.
  For a while, we enabled Gitorious.org.

* Only KDE contributor accounts may have direct write access. That
  means if your code is in a place that in theory allows giving
  others access, you're not allowed to do so.

The former does not imply the latter, and it doesn't do it in prac-
tice. We currently have several KDE projects that mirror to GitHub
and accept code contributions via pull requests there for example,
but under the Manifesto aren't allowed to provide direct write
access to the GitHub repository to folks not holding a KDE contri-
butor account.

None of us like restricting freedoms. We tend to react negatively
to the phrase "not allowed", and to those who use it, even if that
use is the result of a collaborative consensus. So I understand and
am prepared to reiterate the reasons for these restrictions again
and again:

* There is significant trust placed in the process that contri-
  butors undergo to get their contributor account. It's a process
  based on peer review and a process that tries to ensure a cer-
  tain level of familiarity with the rules and workflows of the
  community. If you can be sure that the new contributor who has
  started committing to your codebase underwent this process, it
  tends to alter how you engage with them - both the respect you
  have for his right to do so, the expectations you have for how
  he goes about it, and the level of trust you bring with you
  into conflict resolution, for example.

* The process also works to emancipate new contributors. The
  broad, equal write access - granted at a time when familiarity
  with the social etiquette build on top of it is hopefully also
  in place - should signal equality between contributors and en-
  courage accepting additional responsibility. There's a lot less
  friction in becoming a maintainer or simply performing maintain-
  er-like actions on an unloved piece of code if there are no
  additional bars to meet.

These ideas end up reinforcing each other in a number of ways. If
the access model allows everyone broad access, you need broad
trust. If you want people to give the freedom to expand in their
role and implement things like shared ownership, you need broad
access. And so on.

I think that this wording change is an accident because the
original language seems to do poorly at getting these points
across. 


Cheers,
Eike