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 _______________________________________________ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
