[aur-general] Another removal request

[Martti Kühne]

On Mon, Jun 2, 2014 at 4:31 PM, Gesh <gesh at gesh.uni.cx> wrote:
> Forgive me if this is a stupid question, but wouldn't a design like the
> following give you this paper trail?
> * Add a "flag for deletion/merge/orphan" button on the AUR - possibly
>   subject to restrictions requiring the package to have been marked out
>   of date for a while, as well as requiring the specification of the
>   package/user to replace the current package/maintainer.
> * This button would send out an automated email to the maintainer, who
>   would get the opportunity to respond.
> * If no response has been received, the package is hidden from AUR
>   results and added to some page on the AUR visible only to TUs.
>   Alternatively, the package's AUR page gets marked with a prominent
>   warning that it has been flagged for deletion/merge/orphan and might
>   stop being available. It would still appear in that TU-only page.
> * The TUs get to choose the appropriate response to the flag.

Hmm. One appropriate repsonse to the flag could be "ban user from
flagging for action"... Add a mandatory message textarea, and it's
almost the same as today, except.
Well, there's that one point where the email could be sent once, at
high traffic even several times a day, remove noise on this ML and
collect requests all over different users which the TUs then can
consider one by one.

> * Every day, a flag report gets sent to the ML, listing the packages
>   for which the maintainer hasn't responded to emails regarding the
>   flag, as well as the changes made to the AUR by TUs.

Integrate the deletion request/request for update/adoption into that
interface, and we can measure the 2 weeks in code, and then drop the
request automatically (if it's still relevant) without always having
to remind people about it.

How do we know it's still relevant? Well. That would require human
interaction, which is bad, because the emails get delivered and the
TUs would not have to ask back if that request was sitll relevant.
Although, there could be a 13-21 day reactivation time frame in which
the requester could check his email and remind the system to actually
drop the request.

> This reduces the administrative burden users have to go through in order
> to request the deletion/merge/orphan of a package, as well as making it
> easier for the TUs to see what has been requested. It would unclutter
> the ML, and would still provide a paper trail. As far as I can see, it
> would be a net win for all users.
> However, to paraphrase Schneier's Law, anyone can design a system of
> which he can't see the bugs. So, can anyone point out the problems this
> system would have?
> Gesh

That is, I am going to guess there should be a long-standing flyspray
/ feature request about this, but I'm too lazy to look it up.

cheers!
mar77i