On Sun, Feb 6, 2022 at 5:28 AM Noah Misch <noah@leadboat.com> wrote:
>
> > > - Canned responses are noise to every list reader other than the OP.
> > > - Canned responses make the list feel like a sales funnel rather than a normal
> > > free software mailing list.
> >
> > All bug reports posted through the bug form gets moderated before
> > they're passed through. Moderators also have access to a set of
> > pre-defined canned responses (such as the example of where they should
> > go to report pgadmin bugs). It will also catch posts made directly to
> > -bugs by people who are not subscribed, but people who are subscribed
> > will not have their posts moderated by default.
> >
> > If we're talking about people submitting bug reports, åperhaps a lot
> > can be done with (1) a couple of more such responses and (2) more
> > clear instructions fo the moderators of when they are supposed to use
> > them.
> >
> > Error on the side of letting them through is probably always the best
> > choice, but if it's clear that it can be better handled by a canned
> > response, we do have an actual system for that.
>
> I was referring to David G. Johnston's proposal to send canned email responses
> when a thread (presumably containing a not-obviously-unreasonable PostgreSQL
> question or report) gets no replies in N days. The proposed email directed
> the user toward paid professional services. Sending such a message at
> moderation time would solve the noise problem, but it would make the "sales
> funnel" problem worse. (Also, I figure moderators won't know at moderation
> time which messages will get zero replies.) For which part of $SUBJECT did
> you envision using new moderator responses?
IMO, having a postgresql wiki page describing the steps to debug or
perhaps fix the most common problems/bugs is a good idea. Of course,
adding the steps to wiki and maintaining it takes some effort from the
experts here. But this is better than having canned email responses
for bug reports which requires more effort than a wiki page. Today,
there are a lot of outside resources listing the steps to fix/debug a
postgres related issue. The users can always refer to the wiki page
and try out things on their own, if the steps don't fix the issue,
they can always reach out via postgresql bugs list.
I also agree with the point that improving some of the most common
error messages with hints on what to do next to fix the issues.
Regards,
Bharath Rupireddy.
