
How Does Contributors’ Involvement Influence the Build Status of an OSS Project? [pdf] - ghlp
http://gustavopinto.org/lost+found/msr2017b.pdf
======
sjrd
Dude, I'm the lead developer and maintainer of an OSS project with roughly 120
kLoC in Scala, and I probably break the build more often than not. (Of course
commits don't make it into master until they're green.) In fact, I'm typically
surprised when a PR passes the CI on the first try! There are way too many
configurations to test locally (a PR triggers around 10 hours*CPU of tests on
our CI servers), so I only test a single config before submitting a PR.
Uncovering the impact on the other configs is left to the CI servers.

So yeah, I'm not surprised by those results.

------
zellyn
My summary: “Commits from casual or infrequent contributors are no more likely
to break the build.”

Not super exciting, unless you need ammunition when arguing against some kind
of non-benevolent project dictator.

------
graphememes
Interesting that this is something of interest and research since anyone who
does active development in Open Source could have given the answer without it.

The majority of PRs tend to not affect the build status.

The rare cases (4-5%) where it does, is a complex architectural reason, or the
tests are variable. Which doesn't even factor into this research... Such as
tests that rely on timestamps/external requests/etc that randomly fail, yet
are still a part of the test suite (pretty common).

The places where people are afraid to contribute generally tend to have overly
complex contribution guidelines, rules, and acceptance criterion where you
must sign a waiver, agree to their code of conduct, submit some form of a
RFC... rather than the CI.

------
awinter-py
I wonder what % of casual contributions are CI / build improvements? The most
serious contrib I've done as an outsider was build instrumentation.

