[Nut-upsuser] web-forum about NUT

[Greg Troxel]

Charles Lepple <clepple at gmail.com> writes:

> On Jun 7, 2025, at 6:26 AM, Greg Troxel wrote:
>> 
>> I'll add that while I'm not in charge of the tracker, if I
>> were, I would say that asking for help in issues is not ok, not even a
>> little.  The place for help is right here.
>
> Given how many questions turn into either documentation tasks or bug
> fixes, I don't think it's an unreasonable starting point. We even have
> a "question" label:
> https://github.com/networkupstools/nut/issues?q=is%3Aissue%20state%3Aopen%20label%3Aquestion

My experience in unison is that most questions turn out to be true
questions, and/or about packaging issues (out of scope) or that
GNU/Linux distribution X has an old version.

I see your point about often leading to a bug, but there's a big
difference between "I read the docs and I am up to date and here is my
argument that there is a bug." and "I did X and it didn't work.  What am
I doing wrong?"

The real reason I don't like questions in issues is that as maintainer I
feel they land in my inbox personally rather than the list, and that if
I don't address them I'll just end up with hundreds of open issues.
Once there are more than about 100 issues, I feel like I can't deal with
them and it becomes not so useful.  There were lots of people opening
questions when they hadn't read the docs, and people that expected help
with old versions shipped by their packaging system.  And not rarely, a
sense of entitlement that would only properly go with a paid support
contract.

Directing questions to "not issue tracker" leads to a wider community of
responders.

> I am not volunteering to maintain this, but we do have the option of
> enabling "Discussions" in the NUT GitHub project(s):
> https://resources.github.com/devops/process/planning/discussions/

The real question is how many of the people that provide help want to
answer discussions.  I'm in the "it's a bug that the project is on
github" camp and do not favor any increased reliance.  But turning on
discussions and hitting the convert button for questions would help
clean up the issue tracker.

> I think it's an interesting meta-discussion.
>
> I personally like the "push" aspect of email, and for the first decade of NUT's presence on GitHub, I enabled the "firehose" and sent all of the GitHub notifications for new issues into the same folder as the mailing lists.

What I like about email is

  I can easily put it all in an IMAP folder, so I don't see it in my
  regular mailstream.

  It's all there when I check list mail, without needing to use a
  browser to go to 50 sites.  And thus without needing to use a mouse.
  As you say about push, I see things within a day or so even on lists
  that have 1 message a year, and I'd never go check their forum.

  I can use threading/scoring in gnus to ignore certain people (none for
  this list) and certain subjects (e.g. Windows).

so I can absorb the useful content in minimum time.  Plus

  I can send a private reply if I want (which is ok for those providing
  help, and not ok for those asking for help :-)

> While I agree with Sam's pushback against the notion that mailing
> lists have "no memory", I think it's worth trying to engage a little
> to see what new users might not understand about how mailing lists
> work. For a while, Google search in
> https://networkupstools.org/support.html was broken due to Alioth
> hostname changes. A developer who has an established email workflow is
> not necessarily going to notice that. Should we also update that form
> to not submit via plain HTTP? Probably. Should we offer an alternative
> search engine? Probably as well.

Agreed that a better archive would be better.

The other side of the coin is that I believe that lists build community,
whereas forums tend to be a helpdesk.  That's broad brush and not
totally fair, but I think it's more than half true.