Dear all, thanks for all the feedback, based on this I'd like to modify the proposal like follows:
(1) Given that all new source package come with an ITP bug, when a package must be rejected, the FTP team could CC this bug in the rejection message. This would have the advantage that for everyone interested in the package the information why the package was rejected can easily be found. In addition, For large packages, where a review takes more than one day, the reviewer could send messages to the ITP about problems the moment they are found, so maintainers could start to work on correcting the errors earlier. (2) To improve the initial quality of uploads to NEW I also propose the introduction a (voluntary) review step: Someone who is interested in getting additional reviews to a package before uploading it to NEW could file a "Request for review" (RFR) bug against wnpp. Then those who are willing to review packages can step in and also have a common place to comment on problems of the package that need fixing. When someone satisfied with the package they add a comment to the bug "Reviewed-By: name <email>", and when doing the actual upload, the maintainer replicates these R-B messages in the changelog closing the RFR bug. For large packages one might also add a comment "subir/module X Reviewed-By: ..." to indicate only a partial review. This R-B- information could also be added to that persons QA page under a new section "Reviewed Uploads". In a way this replicates what sponsors do for uploads of non-DDs, but especially for large packages a second pair of eyes is always helpful. -- Implementing the first point is essentially up the the FTP team. For the second point some formalization would be required and made public, for this I'd volunteer. Adding reviewed-by information to the developers QA page would require that someone steps in who is knowledge able in how these pages are created. In any case, this is only a "nice to have" thingy. any comments are welcome, Gert
