Re: [GNUnet-developers] Updating my git work-in-progess branch?

[Schanzenbach, Martin]

> On 16. Mar 2019, at 02:18, Christian Grothoff <address@hidden> wrote:
> 
> On 3/15/19 5:06 PM, Corvus Corax wrote:
>> 
>> Only maintainers had the ability to merge into "master" or
>> "next" ("master" was always frozen between releases, so we merged into
>> "next" for new features to be tested until the next release cycle,
>> while developers would regularly merge "next" back into their dev
>> branches or rebase into a new branch to stay up to date)
> 
> Most of what is discussed in this threat is in principle fine with me,
> but this is not. I would like to avoid setting up such hierarchies among
> developers. We're trying to build decentralized/egalitarian systems for
> liberal societies, so we should avoid building them with authoritarian
> methods.

Sorry I need to hijack this for a fundamental disagreement on the above:

Having quality gates and separation of responsibility between individuals is 
important. Else it will just be chaos and, inevitably, conflict or a crippling 
search for consensus.
And, yes, this implies hierarchies with respect to specific responsibilities.
The reason for this is that not everybody has the same skill set / interest for 
specific tasks.
Any other organisational form is not really based in reality but purely 
idealogical and bound to fail because
it will result in having not the most capable, but loudest and most audacious 
individuals slowing down everything because competency will not be valued.

There will be people responsible for CI, releases, features etc. because that 
is what they primarily want to do.
There will be a significant knowledge and skill gap between them depending on 
their area of expertise.
This gap implicitly defines a hierarchy.

Not having such gates or boundaries between responsibilities in my opinion will 
prevent new users from joining. Because either the existing dev base trusts 
them (ultimately) with all tools or not.
Gaining this trust seems to be to be very subjective at that point. It would be 
better to have new devs prove themselves, for example by demonstrating that 
they have read coding guidelines or are capable of writing code or know their 
way around documentation or CI and _then_ giving them respective access and 
responsibilities.
Before that, working with limited access rights (e.g. pull requests, patches) 
seems a lot more reasonable.
Trust in and respect of an individuals skill set can only ever be earned, never 
be given out on a whim, I think this is fairly logical?

Anyway, no matter how you implement this process or even leave it as it stands 
it will _always_ create a hierarchy. Of authority and of competence. Those two 
are extremely difficult if not impossible to separate in social interactions.

This is also why I think giving git access to contributors immediately is 
folly. You don't even know if more that this initial contribution will be 
provided. Onboarding new devs should only happen if there is clear intent to 
continuously contribute.
This is also why I find the fork+pullrequest vs project dev separation on 
git{lab,hub} to be very effective as it takes into account all of the above.

And if you are completely honest, we have such hierarchies. And you are at the 
top. Now, you may reject this by saying "I am fine" with doing this or that and 
saying that you happily give other devs access to do anything. But the fact 
remains that people will ask _you_ for permission and advice primarily. Because 
you are the most capable and powerful individual within this project. No 
ideological mindset will change this fact. Even if you give the world access to 
every aspect of GNUnet then there will be friendly contributors who will still 
ask the more competent devs (e.g. you) for advice and permission. The only 
difference in this case would be that destructive people will eventually 
sabotage something.
Some basic readings in social/group psychology is enough if you need background 
to support my thoughts on this. You cannot not have hierarchies.
I sincerely urge anyone related to this project not to conflate the project 
goal (decentralised/egalitarian system) with proper work organisation.


> 
> So I would prefer a policy where *either* _everybody_ can merge to
> master (with Git access, which is generally granted to anyone who has a
> plausible need and signed the CA), *or* _nobody_ can merge to master
> (because merges to master are done automatically by the CI when certain
> tests pass!).
> 
> For now, I've never seen serious problems with the 'everybody' policy,
> and would strongly prefer CI-based automation to solve the issue in a
> principled way instead of adding some hierarchy.  Similarly, if we at
> some point grow to the point where peer-review/sign-off becomes
> necessary (and feasible), it should be again that in principle any 2nd
> dev can sign-off, and not just a selected few (of course in practice it
> is more likely that someone familiar with the affected subsystem will DO
> the sign-off, but it should be self-organizing and not imposed).
> 
> my 2 cents
> 
> -Christian
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers

signature.asc
Description: Message signed with OpenPGP