Re: Volunteer-initiated team maintenance as a solution for packages with low activity
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
Reply to: