Re: Proposal: Nuke negative comments

Have we considered allowing a threshold to be set and hiding comments voted
below it? Default to zero if you so want. Deletion is a harsh action.

On Sun, Jun 5, 2022 at 5:36 PM Daniel P. Brown <[email protected]>
wrote:

>     Yeah, I'm good with it, and can do mass changes via Master, as
> well as the lowest-rated notes (anyone with access can, it's not just
> me).  Maybe a threshold, for now, of -15 or below (if there are any),
> then work our way up to a comfortable level.
>
> On Sun, Jun 5, 2022 at 8:32 PM Larry Garfield <[email protected]>
> wrote:
> >
> > On Tue, May 10, 2022, at 4:46 PM, Daniel P. Brown wrote:
> > > On Tue, May 10, 2022 at 5:28 PM Larry Garfield <[email protected]>
> wrote:
> > >>
> > >> I'm fine with some slightly stricter threshold for purging (-5, or -1
> but also at least X months old, or whatever).  No strong preference here.
> > >
> > >     This is another good idea of which I didn't think.  I've removed
> > > thousands of notes that were using coding styles that had deprecated
> > > functions and other such detrimental qualities over the years, but
> > > making a point to check - at least after EOLs and major releases - is
> > > probably a really good idea, Larry.
> > >
> > >> .... (I never use Windows, so I have no idea if it's valuable or
> misleading.)
> > >
> > >     Hear, hear.  Over a hundred devices (servers included) in our
> > > house, and - aside from the as/when needed spin-up of a Windows VM -
> > > not a single Microsoft product.  Nothing against it, like I used to be
> > > in the nineties and early aughts, but this was one of my feelings
> > > toward what Chris pointed out, specifically, about a heavily-downvoted
> > > Windows-based function notes.  Was it because there were factual,
> > > programmatic design errors, or just pseudo-/cyber-cultural bias?
> > >
> > >> To Dan's point, I am happy to discuss better options than this
> sledgehammer.  Mainly I'm just trying to improve the signal to noise ratio
> to make the janitorial work easier and more productive.  But I don't want a
> mythical future solution to block a simple and easy one now, either.
> (Having a stricter one-time purge rule could still leave us sufficient data
> to test more nuanced tools in the future.)
> > >
> > >     We stand in agreement here.  Considering the consistent amount of
> > > posts and voting on the user notes, it's likely to be substantial
> > > enough to outweigh the current state of disrepair it's in now.
> > >
> > >     Regardless of opinions and turnout, though, I have to thank you,
> > > Larry, for bringing up the point.  Because fully-manual intervention
> > > just isn't a reasonable approach anymore, and it's becoming a
> > > hinderance to the quality of the documentation as a whole.
> >
> > So can we proceed here?  Only a select few have access to run any
> mass-purge like we've been discussing (which is good), so those few, are
> you open to it?  What deletion rule would we want to go with?
> >
> > --Larry Garfield
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Daniel P. Brown" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to [email protected].
> >
>