Draft of maintainer and sponsor responsibility policies

Toshio Kuratomi a.badger at gmail.com
Sun Feb 14 16:38:21 UTC 2010

On Sun, Feb 14, 2010 at 12:20:08PM +0100, Patrice Dumas wrote:
> On Sat, Feb 13, 2010 at 02:08:36PM -0500, Toshio Kuratomi wrote:
> > 
> > packager group.  We want to encourage more sponsors to take on people that are
> > not yet good packagers but have the potential to grow into good packagers with
> > a little mentoring.
> > 
> > Updated policy drafts are here:
> > https://fedoraproject.org/wiki/Package_sponsor_responsibilities%28draft%29
> It is not clear to me how the changes in the draft policies address this
> issue.
<nod> When I checked the original page, I was struck by some of this as
well.  In particular, we had a rule before this page was written that the
sponsor was responsible for cleaning up after the sponsored maintainer
should they run amuck and make a bunch of bad commits in the repository.
Since we remade packager and provenpackager groups to limit what a packager
can commit to and make smaller the number of provenpackagers, this isn't as
big a concern.  However, with the potential re-adding of an "open my
package to packager group, the issue of who is responsible for that cleanup
comes up again.

> More precisely, I agree that, in the current policy, 
> 'Make sure the maintainers you sponsor follow guidelines'
> and 
> '  Fix issues caused by sponsored maintainers '
> 'Help answer maintainers' questions'
> are redundant. So it is a good thing to merge them. But I don't think that
> 'Make sure the maintainers you sponsor follow guidelines' put more 
> pressure on the maintainer than what is in the draft in 
> '  Fix issues in sponsored maintainers' packages '
> (although explicitly saying that solving an issue may be finding other
> sources of information is good).
So, at least the titles and phrasing of the two sections is very different.

"Help answer maintainers' questions" is driven by the needs of the
maintainer.  They come to you, the sponsor with a specific question and at
that point you start working with them to resolve their issues.

'Make sure the maintainers you sponsor follow quidelines' and 'Fix issues
caused by sponsored maintainers' demand a more active role of sponsors --
you, the sponsor becme responsible for watching what the packager does.  And
if the packager makes bad commits, you are on the hook to clean it up.
That's why I see them as putting more pressure on the sponsor.

> Moreover, I think that in the draft some aspects of sponsoree help have 
> been removed (they were in 'Make sure the maintainers you sponsor follow guidelines'
> and weren't put in another section), I think that they should be readded. 
> More precisely, I think that
> 'sponsors should guide the sponsored maintainer to do the best choices in packaging and reviewing, and to follow the guidelines.'
> should be readded in '  Help answer maintainers questions '.
I've added Packaging Guidelines as an example in that section.

Feel free to modify it... but be careful to keep the distinction that
a maintainers responsibilities extend to helping the packager understand the
guidelines but do not include having to police their sponsorees (which is the
problem with the wording in the precise quote you have).

> Also the information on how to watch the sponsoree in bugzilla should
> be kept, in my opinion, but put in a specific section and explicitly marked
> as optionnal.
I went back and forth on this one but couldn't figure out how to put it in.
Perhaps, marked as optional and introduced by something like: If you want to
take a more active role in watching what your sponsoree does and correcting
their mistakes you can do....

Another thing that could be added to such a section is adding yourself to
watchbugzilla/watchcommits in the pkgdb (this is automatically granted now).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100214/1c3d19c1/attachment.bin 

More information about the devel mailing list