Collaboration Needs of Massive Open Source Communities
0 likes215 views
The document discusses the collaboration needs of massive open source communities, specifically focusing on Drupal's structure and issues with contributor roles. It outlines the differences in collaboration between known contributors and 'outsiders', as well as the challenges faced in managing issues and contributions effectively. Additionally, it proposes solutions like improved issue summaries, per-issue repositories, and a contribution credit system to enhance open collaboration tools.
Collaboration Needs of Massive Open Source Communities
- 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! :)