Re: New Package for NonGNU-ELPA: clojure-ts-mode

[João Távora]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Surely what "low-effort" users do or do not do would not reflect on
> the number of reports in Debbugs where only "good" bug reports arrive?

Of course not, but it reflects on the _ratio_ of one type of reports to
the other, which is the data point I provided and the one which is
half-relevant to your quest of finding out if debbbugs is The Worst Bug
Tracker of All Time.

By the way, I get good bug reports in GitHub too.  I just meant that,
overwhelmingly the less good bug reports happen in GitHub.

> The point was that any kind of barrier will filter out the less
> motivated, likely resulting in higher average quality.

What you call the "barrier" are actually helpful instructions to provide
a better bug report, at least one I can help with.  In any sort of
office with a feedback loop, there's usually some kind of formality to
communicate feedback, not some box labeled "vomit any idea in here
please".  And I'm not particularly interested in ideas of people who
just dump their thoughts.  Even though sometimes they may be the
beginnings of interesting thoughts.

> It will filter some very good ones too, though.

I really can't see how.  If you have a "very good one" and can't be
bothered to provide some information (which isn't even absolutely
required to start the conversation), then I don't think you have a "very
good one", not even a decent one.

>> Corny as it sounds, instead advance your goals with positivity.  There
>> can be a better bug tracker out there, of course.  I think you should
>> "sit down and do the work" (TM).  If you're an expert in these things,
>> find a forge, implement all or at least most of the hard requirements.
>> Discuss (preferably offline) with the main stakeholders, show something
>> palpable even if not finished.  And yes, with every serious enterprise
>> comes the possibility of failure, partial or even total.  That's part of
>> the game and part of the thrill to be honest.
>
> That almost sounds easy when you phrase it like that.

No, it sounds easy when _you_ talk about it.  It certainly wouldn't be
easy _for me_ to do this work but you talk with such authority,
frequency and passion about it that I'm convinced you would be a
promising lead to the project.  I don't have to 100% agree to your views
to give you my support, and you shouldn't try to make everybody buy into
your plan beforehand.  At a certain point, just do it (more TM) You may
fail, but you may also succeed, and at least you did more than talk.

>> Not every package has to have direct feedback about it.  Some packages
>> are about infrastructure, and project.el is like that, partly.  Others
>> are about UI, like Company, so it makes sense you have more feedback
>> there.
>
> I can see when people have issues, from discussions online. And in one
> case they ask, in the other -- more readily work around.

That's a good thing: that can be just because the software you provided
is good and allows you to.  Do you like the workarounds or are they
somehow ghastly?  If the latter, the problem is the design of your
program.

By they way, I see lots of Eglot hacks and recipes and workarounds for
which I don't see any question in any of Eglot's forums.  It's just a
question of the general dimension of the program and the visibility it
has.

It seems you work on parts of Emacs with less visibility... Well, that's
life!  But it doesn't mean they are less important.  As, I've already
said that Xref, Eldoc, Flymake, Project and priceless completion system
tips from Stefan are the real champions that made Eglot possible.  But
Eglot gets much of the the visibility, it's true.  It's "bones of the
trade" as we say around here.

By the way, there's an Eglot report on Debbugs that is really more about
Xref, as usual (bug#65578).

>> It's good to have discrete packages, to be honest.  Who gives
>> feedback on Emacs's wonderful C macrology?  Yet they use it every day.
>
> The principle extends to all the core packages I had been paying
> attention to. ruby-mode and VC have graphical components as well. Xref
> -- even more so.

I use all your packages except ruby-mode.  I like them, but their
interfaces probably aren't as spiffy as Magit or packages with fancy
postmodern names.  I like that.  And they are stable, which I like even
more.  And the reason I don't comment on them too much is because they
mostly work.

A point worth making is that if you want to have a high visibility
project, start a high visibility project.  For the matter at hand, I
think a Debbugs replacement won't fundamentally change how people and
interact, judge or care about your work.  I would hope it would just
simplify the boring tasks we do currently.

João