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

Re: long-standing bugs and tar pits (was: Are users of Debian software members of the Debian community?)



On 9/16/22 11:57 AM, G. Branden Robinson wrote:
> At 2022-09-16T19:12:40+0530, Nilesh Patra wrote:
> > On Fri, Sep 16, 2022 at 08:47:19AM -0400, Chuck Zmudzinski wrote:
> > > That's easy to explain why your bugs are fixed quickly. You are a
> > > DD, so your bugs are important. I am not a DD so my bugs are not as
> > > important to the maintainers who have a greater responsibility to
> > > respond to a DD's bug than to an unknown user's bug.
> > 
> > That's a completely wrong interpretation that you are drawing here.
> > No, that's not really the reason here.  The reason is rather that
> > people _do_ work on bug reports regardless of who reported them, but
> > you somehow do not want to acknowledge the fact that package
> > maintainers do work on bug reports.
>
> As a person of gray Debian beard (but of sufficiently low profile to
> have been forgotten about as a developer), I encourage diligent
> volunteers to _not engage_ with people who, whether intentionally or
> not, seem determined to increase the amount of friction in processes and
> to make themselves into tar pits for anyone who attempts to engage with
> them constructively.

I don't know how many people here understand what you are
saying here, but I do. Although I do not have a grey beard I
certainly am old enough to have one LOL!

>
> That said, such people define "constructively" in an odd way, as can be
> seen above; they assert that the only way they experience respect is to
> be _obeyed_.  They claim that they are treated as second-class citizens
> because they are not deferred to like monarchs--or dictators.  I advise
> people to be watchful for this pattern because you can be sucked into an
> energy-sapping dynamic that reduces your channel capacity as a volunteer
> and dilutes your enjoyment of (what should be) a collaborative
> environment.
>
> I think we can take substantial value from basic game-theoretic models
> of behavior: if a person defects more than they cooperate, don't play
> with them.  We should ask ourselves, what does Chuck Zmudzinski
> contribute to raising Debian's barn?[1]  The answer isn't necessarily
> "nothing"; maybe it's "application of an angle grinder to the base of an
> erect load-bearing post".

I think that is a nice analogy of what I am trying to do. But there
are also those who think Chuck Zmudzinski is an idiot and does
not know how to do it the way Debian people want their barn to
be raised.

>
> Bugs can take a long time to get fixed and sometimes you have to do it
> yourself.  For your amusement and as a case in point I refer the reader
> to one I had forgotten about for many years.
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=243238
>
> Among other things, Debian is a software engineering organization.  We
> can benefit ourselves and our community by becoming better software
> engineers.  And indulging in "simple sabotage" of production less.[2]
>
> I would emphasize that the list in that oft-cited resource is not an
> enumeration of activities that must be avoided at all costs in all
> circumstances.  I find it useful instead as a diagnostic tool in the DSM
> sense; for example, if you find a person doing at least two of these 16
> things at least once in every meeting (or some applicable time
> interval), then they may be functioning as a drag on production--even if
> they see themselves as heroically frustrating the rolling Panzers of the
> wicked Axis power that is the Debian Project.  The obvious defects of
> the most vilified regimes of the 20th century were that they had too
> much anarchism, too much democracy, and left too much to individual
> initiative.  Imagine the tragedies that could have been averted if
> they'd had a BDFL like Chuck Zmudzinski.

LOL

>
> Regards,
> Branden
>
> [1] https://en.wikipedia.org/wiki/Barn_raising
> [2] https://www.businessinsider.com/oss-manual-sabotage-productivity-2015-11


Reply to: