[kwlug-disc] FLOSS contributions

[Chris Frey]

On Wed, Aug 17, 2016 at 01:47:08AM -0400, Paul Nijjar via kwlug-disc wrote:
> How easy is it for potential contributors to pick up the right way to
> make useful contributions? Are the procedures necessary to complete
> the other 80% of the job well understood/documented, or are they only
> in the heads of the developers?

Depends on the project.  Some have coding style documents, and roadmap
documents.  As for coding style, that's fairly easy to document, and
if it's not followed, you push it back to the submitter.

It is also possible to write documentation with step-by-step instructions
on how to submit a proper patch.  This is also very useful and I'd
highly recommend it.

But the roadmap is only helpful if the contributor really wants to help
and doesn't know what to do.  I've found that most contributions are
actually sharing a feature that the contributor wrote in order to scratch
their own itch.

And then there is the varying level of experience in contributors, and
varying code quality.  That's not really a problem that you can
solve through documentation, only experience.


> How much patience/energy do the developers have towards handholding
> potential contributors through completing the other 80% of the work? 

The patient / mentoring maintainers are needed.  If you're running a
small project, that mentoring may help build fans, which may draw
more contributors, but it can also draw time away from features that
you yourself want to do.


> How feasible is it for outsiders (who are neither core developers nor
> the people proposing features) to do this kind of cleanup work? Does
> this stuff require a lot of in-depth knowledge of the project, or is
> it rote enough that somebody who is not expert enough to code a new
> feature can do the cleanup?

When I was working on Barry, I would closely review everything that came in,
and test it if I could.  If it needed a lot of work, I tended to write
a summary of what needed to be done in email and hope the contributor
would fix it.  If it was minor, I'd likely do it myself.  And if the
contributor just had no idea how to do what I wanted, I'd have to refactor
it myself anyway.  I tended to incorporate as many contributions as possible,
because it was a way of appreciating my users, and especially contributors,
even if they required work on my part.

I had a surprisingly high level of quality in the contributors that gave
to Barry.  The quantity was not high, but the quality was.

On the flip side, I once wrote a feature to the GNU split command that
I needed for myself.  This was before I had much notion for why high
quality in contributions mattered, and how high standards can help in
maintaining a project in the long term.  My contribution worked fine for
me.  My memory is fuzzy, but as I recall, it was pushed back with small
suggestions on how to improve it, along with a discussion as to whether
it was the right approach, and whether it would be ultimately accepted.
I took it as a rejection of my idea, and dropped the whole thing.
My eagerness to send any more changes to them also evaporated.

So I have experience as both the harried maintainer and as the newbie
contributor.  Both sides need to have compassion for each other for it
to work well.  I'd say that if someone went to the effort to create an
actual patch for your code, even if the code is low quality, that shows
way more interest than just an average user.  There is potential there.
What you do with that potential depends on you and whether you have the
time.

- Chris