[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: State of the GNUnion 2020

From: Samuel Thibault
Subject: Re: State of the GNUnion 2020
Date: Sat, 22 Feb 2020 10:50:12 +0100
User-agent: NeoMutt/20170609 (1.8.3)

Kaz Kylheku (gnu-misc-discuss), le jeu. 20 févr. 2020 13:55:37 -0800, a ecrit:
> On 2020-02-20 11:42, Andreas R. wrote:
> > On Thu, Feb 20, 2020 at 02:45:02PM +0100, Samuel Thibault wrote:
> > > > On the flip side, an argument is made that your initiative might make 
> > > > GNU
> > > > more exclusionary because of the extra conditions on what it takes to 
> > > > be a
> > > > part of it.
> > > 
> > > At some point you have to exclude some people in order to include
> > > other
> > > people, yes.  We can see that in various communities:
> One group whose inclusion is being specifically promoted by the
> proposed social contract is people with a low level of experience.

Not "promoted" but "protected".

> The exact rhetoric is that people must be included regardless of
> their level of experience, which can only possibly mean
> regardless of how low is their level of experience.

Yes. Which doesn't mean they should immediately be given commit power
etc. But at the very least be helped to improve and acquire experience.

> So, if people have to be excluded to bring about inclusion,
> let us ask: whom do you have to exclude in order to include
> people with a low level of experience?
> I suspect that the answer is: some experienced people,
> who would block their bad work.

That wholy depends how "block" is done. If the blocking is just "this is
bullshit" mail without explanation, and stick with such behavior, that
is detrimental to the project: newcomers will not come, and the project
will not be florishing. If the block is "this can't work because this
and that, this is not properly written because this and that", that's
helpful to the newcomer, who will improve over time, and become a useful
contributor to the project.

> Older people are politically insensitive, and too smart to accept crap
> software changes.

I'm not saying to accept crap software changes. I'm saying to explain
why they are crap without calling them names.

Really, not including the next generations in a project is running the
risk of the project just dying with its leaders.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]