MESSAGE
| DATE | 2020-02-22 |
| FROM | Samuel Thibault
|
| SUBJECT | Re: [Hangout - NYLXS] State of the GNUnion 2020
|
Kaz Kylheku (gnu-misc-discuss), le sam. 22 févr. 2020 10:22:55 -0800, a ecrit:
> On 2020-02-22 01:50, Samuel Thibault wrote:
> > 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.
Perhaps that's one point where opinions diverge.
> 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.
So the new generation will have to learn by itself? Do not be surprised
if it doesn't wish to pick up the software that was produced by the
previous generation, and will just rewrite everything with non-free
tools etc.
If nobody is there to hold their hand, I don't see a reason why they
would listen to the free software goals.
> Changes from outsiders should be merged based on the merit
> of those changes.
Sure!
> I think that someone who keeps sending bad changes may come to
> be routinely ignored as an optimization;
Sure! I'm not saying otherwise. If even after remarks etc. somebody
doesn't improve, it's fine to stop trying to help.
> 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.
Sure, see what I mentioned above.
> > > 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.
Could you avoid interpreting everything either pure black or pure white?
I didn't mean *pure* protection. I just mean that for instance when
a complete newcomer proposes a crappy patch, one should tell him why
it should be improve (and not just call it crap). And if after a few
iteration there is no progress, one can just say "well, I'm sorry, the
contribution does not have the level we can accept, please work on it
and come back once you have improved".
> Analogy: you can't refuse patrons from your restaurant, on the basis
> of their race, no matter how politely you behave.
That's not the same situation. I'm not saying the social contract would
impose to accept contributions from inexperienced people. The text is
saying "It welcomes all contributors". That doesn't mean committing
everything that gets submitted.
> In what industrialized nation can you not reject job applicants for low
> experience, due to that being discrimination against a constitutionally
> protected class?
The protection is against harassment, not about getting changes
commited.
> > 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.
And the proposed social contract provides the general idea.
> > > 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.
How is it appearing to be?
"welcomes contributions from all and everyone"
"providing a harassment-free experience for all contributors"
"give everyone the opportunity of contributing"
"welcomes all contributors"
None of these say changes have to be committed.
"Welcome" or "give opportunity" doesn't mean "commit the change".
> > 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.
Sure, volunteers can take the amount of time they wish. But the minimum
is to point out the problems.
Samuel
_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout
|
|
