On Wed, Apr 18, 2012 at 2:51 PM, Colin Watson wrote: > Nowhere in this process seems to be the notion that you should > contribute actual effort first before adding yourself as an uploader. I > think that's important, particularly in the many situations where it's > not lack of packaging of a new upstream in question, but some other > problem.
I had thought about that, but forgot to write it. Add a subsection to Step 3 that states "c. A brief listing of the volunteer's contributions to the package" > alioth is just a Debian-specific hosting site, not a general gateway to > package maintenance. We're not set up for them to be dispute resolution > for the whole of Debian, and they have no constitutional authority to do > that anyway. De-emphasising the role of alioth administration in the > whole of this would be a good thing, I think; ownership of the alioth > project is often not that desperately important in practice. The requirement could be to include a link to a clone of the existing vcs with the volunteer's changes. Then it would be the existing maintainers responsibility to sync from that vcs when they return, which could be quite problematic if the repos get out of sync. Another problem that I see with this is that of an additional volunteer becoming interested. In that case, the alioth vcs is out of sync with the package. >> I know processes within Debian are often seen as bad, but I believe >> this one is good (or at least better) because it replaces an existing >> negatively perceived top-down process with a self-directed organic one >> (i.e. may the best work win). > > OK, so remove the top-down bit where admin@alioth has to decide stuff > about who gets to be a maintainer. There really is no dispute resolution required on the part of the alioth admins. Their roles would be to check that the package does indeed need help as suggested by the volunteer (plus with your suggestion that the volunteer has demonstrated aptitude on the package), and to listen to maintainers that detect possibly problematic behavior of the team members that they're personally not allowed to remove. Given that these case should be incredibly rare anyway, this should really amount to very little additional work. But if it really is, there could be a call for a volunteer interested in doing that specific task. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MNnqH=ycu0o6-sv2at_gkshcqqyvxuomhyv5olmfkt...@mail.gmail.com
