Improving our processes for new contributors.

[Nick Coghlan]

On 17 July 2015 at 18:17, Michael Schwendt <mschwendt at gmail.com> wrote:
> But else, I don't think this would improve the process for new contributors
> significantly. As one can see, the new contributors manage to submit packages
> into the queue, and they even point at koji test-builds. One problem is that
> a growing number of package submitters stop at that point instead of trying
> to follow the process guidelines -- which recommends providing some more things
> ahead of time.

Don't underestimate the explanatory power of worked examples 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".

There's a large number of potential moving parts in that pipeline,
from fedpkg, to rpmbuild, to rpmlint, to rpmgrill, to Bugzilla, to
dist-git, to Bodhi, to COPR, to mock, to pyp2rpm, to anitya. If you
already know what all the parts are, then you can devise your own
custom pipeline, but as a new contributor, it would be helpful to have
a prescriptive guide that said something like:

1. Generate an initial spec file with pyp2rpm
2. Create a COPR repo based on the initial spec file
3. Register the upstream package with release-monitoring.org
4. ...?

Once someone has a visualisation of the end to end pipeline from
"upstream release" to "end user installation", and the tasks involved
in maintaining a package over time as upstream makes new releases,
then that provides a framework to structure all the other tooling
knowledge needed to be a good package maintainer, as well as the
additional complications that can arise that make it harder to get to
a policy compliant package.

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.

The language specific sections in the proposed developer portal
(https://fedoraproject.org/wiki/Websites/Developer) could potentially
cover those simple cases, and then provide pointers to the guidelines
for handling the more complex cases.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia