Proposal for revitalizing the sponsorship process for packaging

[Nelson Marques]

2012/4/29 Michael Schwendt <mschwendt at gmail.com>:
> On Sun, 29 Apr 2012 19:31:43 +1000, GG (Guido) wrote:
>
>> > That's no new responsibilities. Sponsors have always been expected to do
>> > that. With pkgdb, it requires "watch*" access to the packages. Else
>> > it requires subscribing to the scm-commits list and filtering by
>> > username/packagename. I've done that, and I've been aware of sponsors
>> > who have done that, too.
>>
>> I wasn't aware of that; if it isn't a best practice, but a must do,
>> the wiki page
>> http://fedoraproject.org/wiki/Package_sponsor_responsibilities should
>> be updated.
>
> You've found a section in the Wiki that isn't pretty. :-)
> There's this other page:
>
> https://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor#Sponsoring_Someone_for_Fedora_Package_Collection
>
>  | You should be sure to review their commits to the Git repository for
>  | how they look, and consider watching their Bugzilla activity at least
>  | for a while (Account->Email->Users to watch).
>
>> >> More sponsors should bring more control, not easier membership.
>> >
>> > Too vague. Please expand on that.
>>
>> If this page is updated (I have no idea):
>> https://admin.fedoraproject.org/accounts/group/members/packager/*/sponsor?order_by=approval
>> the sponsors group has not grown as a function of packages, nor as a
>> function of package maintainers. Possibly because of the sponsor is a
>> provenpackager thing, possibly because that was meant as "we need X sponsors
>> to take care of the Y new maintainers requests we get each given time window".
>
> Rest assured, no such variables X and Y are in use anywhere related to the
> packager sponsor group. Potential sponsors either nominate themselves or
> get nominated by somebody else:
>
>  https://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor

My apologies for deviating the thread earlier. I would address this
issue in a different way:

 1) Assigning a sponsor to a new potential contributor takes a lot of
time from an active 'sponsor' and there's no ensurance the contributor
will go through it and succeed; in case it fails, it's 'wasted' time
that could be used into something more productive from the sponsor.

 2) Motivational issues: this are important, either from the sponsor
and from the potential contributor; While for the potential
contributor slow response times can break his motivation, for the
'sponsor' motivation can be affected by non-responsive contributors or
people who just 'disappear'

This are probably the most relevant factors, sponsor's workflow and
motivational issues. There's no easy fix for it, so my suggestion
would be to face the current issues from a whole different
perspective:

 a) Packages should be owned by a group of people and not necessarily
from a single person; face this as the real 'owner' of the package is
"X", where "X" stands for the group of all co-maintainers of the
package, which can be coordinated by a SIG;

 b) Introduce a more collaborative way; Imagine I want to get package
'foobar' updated; The step would be to encourage the current person to
file a bug report requesting the update and provide already a git pull
with the changes; When it comes to review one of the persons which
maintains the package can review the git pull request and merge
it/rebuild it or request further changes. This is the fase where
there's know-how transiction and everyone would be allowed to submit
changes to Fedora without being a packager. The review still happens
and isn't bound to a single person, but instead to a group of persons,
which should reduce the heat.

 c) Such a method would also mean that packages are harder to get
orphaned out, since theres more people looking after them;

 d) This should provide a faster review and response;

 e) This should allow that the 'trust' escalation on potential
contributors still happen;

 f) The integrity of the project and quality of the packages should be
maintained as there's always a higher review;

 g) People can escalate in trust based on past contributions to the
project, and this allows people with less technical skills to still be
able to contribute in a secure way to the project; furthermore, it
allows collaboration and provides also a know-how transfer from more
experienced users to newcomers;

I know this isn't perfect, but for me, such a method would be far more
easier; instead of being nagging people to do rebuilds/updates, etc,
potential contributors should actually be able to submit code directly
and having a group of people to review it and merge it when
accepted...

Would this make any sense and in your opinion would it be possible ?




>
>> But I am not saying that a sponsor should be turned to a forced
>> comaintainer for the time being, either.
>
> That wouldn't work well in all cases anyway. There is no requirement for
> sponsors to have indepth knowledge of the software the sponsoree has
> packaged. Not even the first package the sponsor has reviewed. Doing
> packaging and reviewing a package is one thing, being intimately familiar
> with the packaged software is another. Review-time testing of the packaged
> software is only a SHOULD in the guidelines. It is assumed that the
> package submitter is familiar with the software and that the reviewer
> is sufficiently familiar with packaging to not break the software by
> making false recommendations. ;)
>
> --
> Fedora release 17 (Beefy Miracle) - Linux 3.3.4-1.fc17.x86_64
> loadavg: 0.02 0.05 0.05
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel



-- 
Nelson Marques
// I've stopped trying to understand sandwiches with a third piece of
bread in the middle...