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

[Dmitry Gutov]

On 28/08/2023 04:37, João Távora wrote:

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

I made that conclusion from your past statements and, yes, the README: 
https://github.com/joaotavora/eglot#status-of-this-github-repository

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

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?

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

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

It will filter some very good ones too, though.

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

All good to me.

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

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

Sure.

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

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