Improving our processes for new contributors.

[Michael Schwendt]

On Mon, 20 Jul 2015 17:34:09 +1000, Nick Coghlan wrote:

> Don't underestimate the explanatory power of worked examples

-snip-

Don't underestimate them how? I fail to see what your response has to do
with the paragraph from my mail you've quoted.

Some of the current (and past) problems with the review queue:

 - There are more new contributors waiting for a sponsor than sponsors
   working with those people to turn them into Fedora packagers.

 - There are poorly made packages in the queue. Sometimes even submitted
   by approved packagers. Even in dist git there are packages, which would
   not pass review anymore. In other cases, reviewers have made mistakes,
   too.

 - A growing number of new contributors submit only a single package,
   which is very limited input for a sponsor to review, especially if the
   single package is flawed. Sometimes it's a library API, and a year
   later there's still no package using that API => adding a package
   to Fedora's package collection won't make new API users pop up like
   mushrooms.

 - A growing number of new contributors prefers waiting for something
   to happen instead of following the recommendations and attempting at
   doing a few reviews.

 - A growing number of [new] contributors do something completely
   different than how it has been done for many years, ignoring common
   practice. This is problematic for potential sponsors and/or reviewers
   as the packaging guidelines are complex but never complete.

You cannot fix this with more detailed guides, "worked examples". The
opposite might happen: It could be that more beginners would manage to
submit a package following examples in trial-and-error fashion, but the
real "fun" starts as soon as the first bug reports are submitted.
Handling bug reports and releasing updates cannot be simulated well
with Copr.

> [...] aimed at
> the relatively common cases like "I want to take an existing PyPI
> package with no dependencies other than Python itself, propose adding
> it to Fedora, and keep it up to date as upstream make new releases".

An attempt at creating package-monkeys?

Turning upstream releases into RPM packages is something that literally
asks for automation. On the contrary, maintained packages is what adds
value to a package collection: responding to bug reports, debugging,
bug-fixing, forwarding [enhanced] bug reports to upstream, observing
upstream activity/commits/communication, integration testing, ABI/API
stability, handling FTBFS issues. That involves a lot of stuff you cannot
cover in documentation specific to Fedora. Or you can try to, but it will
reach the size of a book. Don't hope for more contributors then.

> Unfortunately, the presentation of information at the moment tends to
> focus on the individual steps (e.g. the packaging review guidelines),
> without first providing that larger context of how software flows from
> an upstream project *through* Fedora and into the hands of end users.

??? With all due respect, replies like that are reason to stay away from
this topic. Which target group do you have in mind?
There are various howtos ranging from building a package to submitting an
update, or a page covering maintainer responsibilities and update policies.
Once a person can access Fedora's infrastructure, only few of the approved
packagers run into major problems trying to "release an update" -- unless
a service is down or is affected by bugs.

What Fedora must be careful with, however, is not to flood existing
contributors with new "services" that are too experimental. For example,
AutoQA reports in bodhi that are false positives and manage to confuse
the update submitters. Or, for some time I receive ABRT notifications of
the class "ABRT report for package XYZ has reached N occurrences", and a
bugzilla ticket is missing, and there is no way to ask the reporter to
submit a full report.