Re: State of the GNUnion 2020

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-22 01:50, Samuel Thibault wrote:
> 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.

I strongly disagreee; people should come to freeware projects
as "self starters" with some meaningful combination of decent
industry experience and talent.

Simply put nobody has the time to tutor you.

You have all the code; you can study it. There are books,
tutorials, and other resources.

Changes from outsiders should be merged based on the merit
of those changes. (And that has been my experience; I've never
been challenged to provide a resume detailing my level of
experience!)

I think that someone who keeps sending bad changes may come to
be routinely ignored as an optimization; there has to be room
for associating bad changes with a person or online account,
for expediency.

Lastly, who have commit powers have nobody above them; they must
themselves be experienced. The GNU project should not take on
dabbling amateurs as maintainers and should never have any
sort of document which suggests otherwise.

GNU programs and components are production code relied upon by
the world in "mission-critical" deployments.

I'm all for mentoring. Maybe there should be a dedicated GNU
or FSF initiative for that, "GNU Bootcamp" or something.
Where would the resources come from.

> > 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.

But does it? If inexperienced people are a protected class, then it
doesn't matter how the blocking is done. The blocking violates the 
social
contract and that's that.

Analogy: you can't refuse patrons from your restaurant, on the basis
of their race, no matter how politely you behave.

Basically, equating inexperience with attributes like race is completely
unacceptable, insane nonsense that's not practiced anywhere.

In what industrialized nation can you not reject job applicants for low
experience, due to that being discrimination against a constitutionally
protected class?

> If the blocking is just "this is
> bullshit" mail without explanation, and stick with such behavior, that

That's just a straight violation of the kind communication guidelines.

> > Older people are politically insensitive, and too smart to accept crap
> > software changes.
>
> I'm not saying to accept crap software changes.

*You* may not be, but that "social contract" appears to be.
It supports that interpretation.

> I'm saying to explain why they are crap without calling them names.

There can be situations when you just have tobe done explaining
and that's that. As a volunteer, you don't owe anyone anything,
including detailed explanations which amount to tutoring someone about
why their change proposal cannot be merged.