On Mon, Jun 2, 2014 at 4:31 PM, Gesh <gesh@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