A talk for the GitHub Global Maintainer Summit 2021 on the collaboration challenges of large, distributed, largely volunteer-run open source projects.

1. Collaboration Needs of
Massive Open Source
Communities
Angie "@webchick" Byron
(she/her)
Product Manager / Core Maintainer / Community Cat Herder @ Drupal
Drupal Acceleration Team @ Acquia

2. Background
● 🥳 Established in 2001
● 📈 Powers 13% of the top 10,000
websites, 1.39M+ users
● 🙀 121,000+ contributors (!)
● 🧩 Drupal is a flexible content
management framework
● 😬 As such, we used it in the early
2000s to build our own "GitHub"
● 🦊 Working on moving to vanilla
GitLab

3. Roles in a "traditional enterprise"
Guest Maintainer Owner
Reporter Developer
● Download
software
● "Me too"
an issue
● Write code
● Run tests
● Review
changes
● All of that, +
● Push to
main
● Release
stuff
● Access
control
● Destroy
things
● Create
issues
● Maintain
issue
metadata

4. 1. 🧳 Contributors are all part of the same organization
2. 💟 Contributors are known, trustworthy, and have good intentions
3. 💰Contributors are paid to give sustained attention to the project
4. 👀 "Outsiders" take from, not give to, the project
Assumptions
Guest Maintainer Owner
Reporter Developer

5. 1. 🌎 All have different organizations (or none) + unique motivations
2. 🕶 Contributors do not (cannot) all know/trust each other
3. 🙌 Most contributors are volunteers, "nights and weekends" time
4. 💪 "Outsiders" are integral to the contribution process
Meanwhile, in
open source...
Guest Maintainer Owner
Reporter Developer

6. ● Maintainer
in Training
● Can give
sign off, but
not merge
● Shows up
once,
never
again
And there are more "roles," as well...
"Drop-In"
Dani
"Life Happens"
Lena
"Provisional"
Pam
● Key
contributor
who
suddenly
vanishes
● Troll
● Tries to
sneak in
malicious
code
"Bad Actor"
Betty
"SPOF" Sally
● The lone,
single person
on this entire
earth who
knows how
something
works

7. Example: defining an issue @
Reporter
Well-defined issue following project template, clear steps to reproduce,
success criteria, etc.
Maintainer
Reads over the issue summary and then gets to work.
Reporter
Updates issue summary with additional details.
Developer
Posts clarifying information.

8. Example: defining an issue @
Maintainer
Wastes time wading through 28 comments to figure out what the heck the
problem even is before she can get to work.
"Drop-In"
Dani
Well-defined issue template obliterated, replaced with "it's broken, fix it." :P
27 confused but well-meaning comments posted, trying to figure
out what's going on (possibly including an argument instigated by
"Bad Actor" Betty. :P)
Develo
per
"Bad Actor" Betty
Guest
Figures out the actual problem and details steps to reproduce, but can't
edit issue summary because they're not a "Reporter" (we don't know/trust
them yet) and "Drop-In" Dani (who can edit the original issue) is long gone.

9. Example: fixing an issue @
Maintainer
Provides useful feedback.
Developer
Creates a merge/pull request for review.
Maintainer
Approves and merges changes.
Developer
Makes updates to the merge/pull request.

10. Example: fixing an issue @
Maintainer
Maintainer wastes time trying to figure out which version of the fix they
should be reviewing and signing off on, needs to understand discussion in
two places.
Developer #2
Creates a new merge/pull request incorporating Developer #1's feedback,
but is now forking both the solution and the discussion.
"Life Happens"
Lena
Creates a merge/pull request for review.
Developer #1
Provides useful feedback, and proposes a solution. Wants to improve on
Sally's code, but can't update the merge/pull request because it's not
theirs, and they're not a maintainer.

11. ● Issue summaries-as-wikis
○ Provides a single, known place to understand the nuances of an issue/what
remains to be done.
● Per-issue repositories
○ Keeps discussion on solution centralized.
○ Allows anyone to create pull/merge requests, and improve on others'.
● Robust issue classification system
○ Allows "crowd sourcing" issue triage/maintenance
● Contribution credit system
○ Incentivizes organizations to sponsor contributions
○ Upstream issue: https://gitlab.com/gitlab-org/gitlab/-/issues/327138
● … (numerous other things, but we only have 15 mins :)) ...
How do Drupal's bespoke tools handle
these challenges today?

12. Defining who gets credit for a
contribution

13. More credits? More perks.

14. Also, more contributor sustainability.

15. Path to GitLab? Work in progress.
Have ideas? "At" me: @webchick
Do these points resonate with your
community?
Let's work together to make robust,
sustainable open collaboration tools that
work for everyone! :D

16. Thanks! :)