Proposal for revitalizing the sponsorship process for packaging

[Michael Schwendt]

On Mon, 30 Apr 2012 10:53:45 +0100, NM (Nelson) wrote:

> > 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'

A sponsor who has made a bad experience could sound like that. ;)

It's not necessarily a "wasted" effort, because for the reviewer it's
useful practice. And often, multiple reviewers visit a review request
ticket and read through the comments. Sometimes only as a self-test to
find out whether they would notice the same issues with a package. But
one can learn from reading [some] reviews. 

Which is also one reason why newbie packagers and needsponsor-packagers
are encouraged to try reviewing somebody else's package. That this could
speed on the sponsor-finding process should be enough motivation.

I'm more concerned about the apparent increase of package-orphans due to
packagers who drop off silently. No statistics known, but it seems to be a
steady percentage of the total number of packages. One one side of the
package collection there are attempts at adding new packages faster, while
on the other side packages must be orphaned because maintainer is AWOL.

> 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;

But this is possible already since the introduction of pkgdb!

Even if the interface lists one of the maintainers as "owner" (aka the
initial assignee in bugzilla), additional maintainers can be added to the
four ACLs, getting full access to the package, including even the ability
to approve further maintainers within pkgdb.

Additionally, the SRCRPMNAME-owner Fedora Project mail alias can be used
to reach all maintainer of the package. For some packages, the mail is
forwarded to a special mailing-list even.

Nothing (except for lack of motivation) really stops an interested
volunteer from signing up as the bug triager for a package, for instance.
The "watchbugzilla" ACL in pkgdb makes that easy. The person only needs to
be sponsored, which shouldn't be a big hurdle, provided the person does
the preparatory work, such as "signing the deal" with the existing package
maintainer(s). Another person could handle releasing the updates in bodhi,
and so on.


As I mentioned elsewhere in this thread, a problem IMO is that once there
is a single package owner already, hardly anybody else wants to take care
of this package, too. Unless the owner becomes non-responsive or doesn't
update the package frequently enough. Potential orphans have a higher
chance of attracting a co-maintainer, which likely becomes the new "owner"
if the previous owner drops off actually. Actual orphans are picked by
existing packagers like low-hanging fruit, sometimes apparently without
real interest in the packages.

>  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.

Same as above. Or?

Btw, we're facing the problem that update requests in bugzilla (similar
to bug reports in bugzilla) are not handled for some packages.
Non-responsive maintainers, different/conflicting workflows, too many
tickets per component, etc. And still, bugzilla isn't a place where bug
reporters would volunteer as co-maintainers.

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

Well, there are small and larger teams of maintainers for some packages
already. It's possible. Still there are thousand of packages, which are
maintained by a single person.

Imagine the following:

If the current package review process were turnt into a package popularity
contest, it would stall almost completely. For example, if the reviewer
were forced to become an initial co-maintainer, or if there were a
requirement for a package to be maintained by two initial people and not
just the single submitter.

>  d) This should provide a faster review and response;
> 
>  e) This should allow that the 'trust' escalation on potential
> contributors still happen;

"Trust" is something beyond this topic, IMO.

>  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 ?

I think it has been possible for a longer time already. It doesn't solve
the fundamental problems, however. It's all too easy to point the finger
at the packaging guidelines, and call them "unneeded bureaucracy" for
example, and not sign up as a contributor.

-- 
Fedora release 17 (Beefy Miracle) - Linux 3.3.4-1.fc17.x86_64
loadavg: 0.00 0.01 0.05