[aur-dev] AUR bad package moderation queue
elij.mx at gmail.com
Mon Jun 13 22:38:46 EDT 2011
On Mon, Jun 13, 2011 at 6:25 PM, Dan McGee <dpmcgee at gmail.com> wrote:
> We now have 29998 packages and counting in the AUR, of which 8122 have
> never been updated since initial upload, and I would guess another
> 8000 are also steaming piles of...something.
> My suggestion is a moderation deletion/cleanup queue that is visible
> only to Trusted Users to prevent the public from seeing it as a
> numbers game, and to prevent abuse. It would work as follows:
> 1. Package pages get a "Flag as Sh*t" (or equivalent) button,
> available to all logged in users. Perhaps there is a "reason" box.
> 2. Users start flagging packages. Whether a package has been flagged
> or not is not visible to anyone except TUs.
> 3. These flaggings are tracked and a TU moderation page is available
> for perusal. Heading the list are packages that got the most bad votes
> in descending order. Next might be those packages that have never been
> 4. TUs can then review, on their own time, these bad packages. From
> there, they can do one of three things: a) delete it on the spot, b)
> comment and suggest improvements and delay the decision, or c) mark
> the package as non-sh*t, which will prevent the package from being
> flagged again for a 3-6 month span.
> Thoughts? The only goal here is to make the AUR more usable and not
> have to wade through old/outdated/less than well built packages.
>From a feature-proposal standpoint though, I sounds very reasonable
and much needed.
A bit bikesheddy here...but wording like 'report package', and
functionally like how the bbs has a 'report post' feature, makes a
good deal of sense. I think 'flag' (the name you used) is a bit of a
loaded term. The main site uses 'flag' to mean marking packages as out
of date, and I think users are trained in that regard. I think end
users being confused and conflating the two (flag out of data and
report as bad) would be problematic and counterproductive to TUs
trying to clean things up. As long as the functionality is clearly
distinct and easy for end users to discern between, it should be very
More information about the aur-dev