LWN: The value of drive-through contributions

[Andrew Jeffery]

Hey all,

LWN recently ran an article on community and drive-by contributions:

https://lwn.net/SubscriberLink/688560/9fa49b203bb0997d/

I think the article outlines some decent points to measure ourselves
against, so I've picked some out and added my thoughts.

* Provide a quick start guide

    We have cheatsheet.md[1] in the docs repository 

* Provide an in-depth contribution guide

    Similarly, we have contributing.md[2]. We should probably expand on it
    to cover the split we have in the contribution styles: projects with an
    existing upstream use the upstream workflow, OpenBMC projects use pull-
    reqs/Gerrit (when it's available). This last point has already been
    brought up on the mailing list in an exchange with Rick.

* Describe how the project communicates

    So we use email (this list) and IRC with #openbmc on Freenode. Neither
    of these mechanisms appear to be mentioned in the wikis or repositories
    of openbmc/openbmc or openbmc/docs. This looks like something we can
    improve with little effort.

* Have a code of conduct

    To my knowledge we don't have a code of conduct. What are the opinions
    here? Should we have one? If so, what priority do we put on it, who do
    we get to write it and what process should be used to develop it?

* Document roles and who performs them (leadership, subject-matter-
experts)

    As far as I'm aware, the best snapshot we have of this is Chris' email
    "Resolving the lonely pull request"[3] where he makes suggestions for
    the owners of the various repositories that make up OpenBMC. This
    information probably deserves a more permanent home if people agree
    with the list, however should that be in the docs repository, or spread
    about in the relevant repositories? Both?

* Provide a road-map

    Probably the best way to get a grip on the roadmap at the moment is to
    look at the milestones in Github. That's not a bad place to be, but do
    we have all the information there (e.g. are we doing a v0.9)? If not,
    is there anything significant that's missing, and if so, why is it not
    there?

* Document rules and process (transition from drive-by to core
contributor)

    As we gain contributors this will become more relevant, but it's
    probably manageable in an ad-hoc way at the moment.

Process suggestions:

* Tag "starter" bugs

    We have our "bitesize" label[5]!

* Mentor new contributors with code review
* Contribution SLA (review patches at most X days after posting)

    For both of these points I think the fact that Chris sent "Resolving
    the lonely pull request" indicates we had a problem. Have we
    improved? As pointed out in the comments on the article this is
    probably a hard one to meet, but it seems like a decent aspiration.

* Credit contributors in release notes

    At the moment we're pushing tags to github with no further fanfare.
    Having release notes or an announce email would be a nice touch, and
    would allow us to give credit where it's due. As an example, Skiboot
    does a breakdown of various contributions in its release
    announcements[4], as do many other projects. I'd like to see release
    announcements for OpenBMC!

* Follow up with contributors about their experience

    Again, probably something to aspire at the moment, but seems like a
    decent suggestion.

Overall, to me the article highlighted the need for documentation and
transparency to help bootstrap people new to the project. In the vein
of transparency there was some discussion earlier today about
refactoring the codebase and how to approach it with growing interest
in OpenBMC. At a general level I think the answer lies in having open
(on-list) communication as much as possible so all parties can stay in
the loop. If off-list discussions occur I think it would be great to
seen them summarised on-list to improve communication and transparency.

Anyone else have thoughts on how issues raised in the article might
apply to OpenBMC? What can we do to improve the experience for new (and
existing!) contributors?

Andrew

[1] https://github.com/openbmc/docs/blob/master/cheatsheet.md
[2] https://github.com/openbmc/docs/blob/master/contributing.md 
[3] https://lists.ozlabs.org/pipermail/openbmc/2016-April/002677.html
[4] https://lists.ozlabs.org/pipermail/skiboot/2016-March/003028.html
[5] https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+user%3Aopenbmc+label%3Abitesize
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160602/3f6f75e6/attachment.sig>