lilypond-devel
[Top][All Lists]
Advanced

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

Re: Add Code of Conduct [Another RFC or not now?]


From: David Kastrup
Subject: Re: Add Code of Conduct [Another RFC or not now?]
Date: Sat, 08 Feb 2020 21:12:55 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

address@hidden writes:

> Anyway to answer Karlin's request, I am probably the last person in
> the 'dev' team to worry about. Yes I seem to do a lot of 'work' but it
> *is* just 'janitorial' duties (which is a rather good way to explain
> it) and, assuming we do manage to get the automation suggestions in
> place then there will be no need of what I do, which will be much
> better for the project (I hope).

The manual comparison of visuals is still not going to do itself.  But
yes, it would be better if the procedures took care of more stuff that
computers can do similarly well to people, given the kind of exact
instructions computers need.

> Anyway, the point is that nothing I do here is as very significant
> compared to those developers that actually write 'code' (I am not
> looking for sympathy here, I am merely stating what I believe),

I hope you will not mind if I believe otherwise.  The whole "janitorial"
procedures have been designed to put grease to the wheels that, in the
form of developers responsible for the "actual" progress, can lean quite
to the squeeky side.  I perfectly well remember the tensions that arose
when we were working with a single master and all developers ground to a
halt for days on end because somebody committed something that had some
trivial oversight somewhere.  Or because weeks later someone complained
that his use case looked much worse than before.

Now it's easy to say "that's work that anyone can do" (though not
entirely correct, particularly given the rather inconspicuous manner in
which you substitute scripts that are falling apart with manual labour,
something one all too easily forgets), doing so reliably for years and
years on end makes it a fixture of stability.  That the sometimes heated
developer discussions are an antithesis of.

Or, more poetically, your work turns a scrapyard of tools into a home
one returns to.

> so my opinions about a CoC are, in the grand scheme of things, not
> going to affect the code base of LP (i.e. you won't be losing a useful
> developer so to speak), but I was more and more objecting to the
> seemingly selected deafness/blind-eye turning of some of the people
> commenting on this CoC thread as if it was all 'sweetness and
> light'. So without any real skin to loose in this game I spoke up.
>
> If we end up waiting for the automation stuff to be working and THEN
> implement the CoC (or this GNU Happy Place Pamhplet)

It's not really a set of rules, just a bunch of advice that has some
chance of working.  Basically it was Stallman's way of saying "we don't
need a Code of Conduct with its enforcement mechanisms if people try
giving others the benefit of doubt some more and take some care to avoid
escalation, and here are a few tips for that".  They won't help against
willful and/or unabating provocations: where they turn disruptive, one
will still have to think about what to do then.  It has happened, but we
got through.

> then it won't affect the project at all as my current duties will be
> voided (and again, that is fine). But if this CoC was, as it was
> seeming as of yesterday, a foregone conclusion (unlike the Automation)
> then I thought I better warn the dev team so they could at least plan
> for my absence.
>
> Maybe this will help focus minds on the automation?
>
> If so, then something positive would have come out of this CoC thread
> after all.

Frankly, the state of the automatation is pitiful, but we were also
partly laboring from a dearth of API documentation IIRC as well as a
lack of people versed in the respective programming
languages/systems/frameworks.

Lame excuses, I know.  At any rate, things on my plate tend to make me
panic, and you give more a steady vibe of clearing plates rather than
stacking things up.  Which may not necessarily always act to your
advantage, but quite to that of the project.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".



reply via email to

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