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

[João Távora]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Naturally the sum of the two will be higher, but you *are* keeping the
> GitHub tracker alive, and people still use it 2x as often as Debbugs,
> even though the README asks them to use the latter. Even though that
> last part by itself necessarily increases the visibility of Debbugs
> with this additional advertisement. And despite all the active
> contributors having moved to Debbugs, again, by your request.
>
> This is the point I was making.

Just open

   https://github.com/joaotavora/eglot/issues/new/choose

And see these three proposed actions, in order

1. Bug report with MRE recipe
   Something didn't work right, and you've written a perfect MRE recipe

2. Report bugs informally, discuss Eglot, request features
   Informally and freely report problems, ask questions, etc

3. Start an email discussion in bug-gnu-emacs@gnu.org

...

The first two go GitHub's discussion facilities.  So, it's not true I
ask people to use Debbugs exclusively.  So please don't twist facts to
indulge your intuition, which is quite probably wrong in at least some
aspects.  You know these low-effort users don't even read the README
(most haven't read the big letters saying that the repo isn't the
upstream anymore, so I still get GitHub PRs).  They google "Eglot", land
on the github repo, press "issues", look around, press "new issue" and
get that list.  Then they choose most likely one of the first two
bullets..

>> and a "look it doesn't work".  They write it usually under their own name
>> and email address (as opposed to a somewhat anonymous alias).  I think this
>> is a good thing.
>
> That's the same "50 squats" principle I mentioned previously.

I missed it, but it's not a very good sporting analogy.  50 squats are
useless unless you're some kind of gym bronco.  In contrast, spending 5
minutes reading some prose I wrote about the usual difficulties with
Eglot bug reports is not 50 squats, it is time well spent.  And not much
to request of a user of Free software about to ask for much more than 5
minutes of my mind.  It will reduce the amount of questioning and
guessing that I have to do, thus severely increasing the chances that
the report reaches some positive outcome.

Even the super-fancy super-modern JS frameworks on GitHub ask reporters
to do much more, down to actually proving their MREs in actual code.

And yet I still explicitly offer people a forum to "informally and
freely report problems".  Of course, if they just want to chat, there's
a limit on how I can help, so often I end up referring people to the
troubleshooting guide.

>> So I don't know how to answer your question, given this hybrid model.
>> I think if I had just shut down the GitHub, we'd see more stuff pop up in
>> Emacs tracker, ...
>
> Interesting theory. I half-wish we could try it someday.

Why?  You asked questions about the frequency of bug reports I get on
both forums and I gave honest answers.  This last week I got more
Debbugs Eglot email feedback than GitHub email,for example.  Again,
don't try to twist my data to somehow categorically prove debbugs sucks.

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.

But Eli has already said that he's willing to give it a fair shot, IIUC.
I would just trust him.  You also have my support.  And because you
can't do omelettes without eggs, you could probably even muster some
financial support, an effort which I would contribute to..

> My own experience is that the projects inside the core, which were
> never on Github, get incomparably less feedback. Much fewer bug
> reports, questions, suggestions, and so on.
>
> project.el (for example) is most of the time treated like a code drop
> which people either use, or code around, or revert to Projectile.

What "feedback" are you looking for?  Improvements? Recognition?
(serious recognition, not silly github stars).  Scrutiny?  riticism?
All of the above?

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

João