Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

How to tame a maintainer

How to tame a maintainer

Contributing to Open Source is hard. Too often we submit a pull request without hearing back from the maintainers, wasting our time that could be spent elsewhere. Being a long time open source contributor, and just recently maintaining MetalLB, a fairly popular open source project, I will share the insights and the issues a contributor (and a maintainer) faces when dealing with new contributions.

I will provide hints and reasons to maximize the chances to steer the maintainers' attention to our work, to gain their trust and establish a profitful relation with the community behind a project.

Talk presented at Opensource day 2023 (osday.dev)

Federico Paolinelli

March 24, 2023
Tweet

More Decks by Federico Paolinelli

Other Decks in Technology

Transcript

  1. Telco Network Team @ Red Hat Contributed to: - Athens

    - KubeVirt - SR-IOV Network Operator - OPA Gatekeeper - OVN-Kubernetes hachyderm.io/@fedepaol - CNI Plugins @fedepaol - MetalLB [email protected] About me
  2. MetalLB MetalLB is a load-balancer implementation for bare metal Kubernetes

    clusters, using standard routing protocols (github.com/metallb/metallb) - 5k stars on github - ~ 600 PRs since I started maintaining the project - ~ 40k LOC
  3. The Maintainers Priorities: • Find the root cause of the

    escalation that is going on for weeks • Deliver the feature promised to the customer • Try to understand why the CI is flaking and they are not able to reproduce it locally • Find the time to review all the PRs that keep accumulating • …. • Do the laundry • Your feature they never heard about
  4. First steps • (Say hi) • Declare your intention •

    Ask if you can work on it • Start working until submitting a PR...
  5. Once submitting the PR, you’ll get reviews • Reviews are

    really thorough • As a new contributor, maintainers will keep a higher bar • You’ll need to defend your ideas • You’ll have to accept critics and suggestions (or both)
  6. The Maintainers Priorities • Find the root cause of the

    escalation that is going on for weeks • Deliver the feature promised to the customer • Try to understand why the CI is flaking and they are not able to reproduce it locally • Find the time to review all the PRs that keep accumulating • …. • Do the laundry • Put the kids to bed • Your feature they never heard about
  7. On proposing a new feature • Discuss it during community

    meetings • Prepare a draft proposal • Show that you care about impacts (possible alternatives, API changes, how to extend the coverage of tests) • You must convince the maintainers that the project will benefit from it
  8. Conflicts • With reputation, you’ll work on more complex tasks

    • With more complex tasks, there will be different opinions • There will be conflicts
  9. You’ll initially be a second class citizen • Your PRs

    might still be ignored • The maintainers may decide the feature you spent so much time on is not wanted anymore • They may give unrelated comment / ask to redesign the whole thing
  10. “Of course, I'd also suggest that whoever was the genius

    who thought it was a good idea to read things ONE F*CKING BYTE AT A TIME with system calls for each byte should be retroactively aborted. Who the f*ck does idiotic things like that? How did they not die as babies, considering that they were likely too stupid to find a tit to suck on?” from https://lkml.org/lkml/2012/7/6/495 People may be rude
  11. - Multiple people may need to contribute to the project

    - Readability / maintainability is emphasized - The purpose must be clear - The architecture must be maintainable Why quality matters
  12. - Fixed #12345 - Fallback to single stack - MYPROJ-41256

    - Improvements - No description provided (Not so) good commit subject / body
  13. Good commit subject / body e2e: remove JSON progress output

    on stdout The original intention was to address "frustration of end users running the e2e suite is that they take a significant amount of time and it is difficult to gauge progress". But Ginkgo's output is different now than it was in Kubernetes 1.19. If users want to see progress, then "ginkgo --progress" might provide enough information. Printing to os.Stdout doesn't work as intended anyway when output redirection is enabled (the default for parallel runs) and causes these JSON snippets to appear as "show stdout" for each failed test in a Prow job, which is distracting.
  14. Good commit subject / body e2e: remove JSON progress output

    on stdout The original intention was to address "frustration of end users running the e2e suite is that they take a significant amount of time and it is difficult to gauge progress". But Ginkgo's output is different now than it was in Kubernetes 1.19. If users want to see progress, then "ginkgo --progress" might provide enough information. Printing to os.Stdout doesn't work as intended anyway when output redirection is enabled (the default for parallel runs) and causes these JSON snippets to appear as "show stdout" for each failed test in a Prow job, which is distracting. The area
  15. Good commit subject / body e2e: remove JSON progress output

    on stdout The original intention was to address "frustration of end users running the e2e suite is that they take a significant amount of time and it is difficult to gauge progress". But Ginkgo's output is different now than it was in Kubernetes 1.19. If users want to see progress, then "ginkgo --progress" might provide enough information. Printing to os.Stdout doesn't work as intended anyway when output redirection is enabled (the default for parallel runs) and causes these JSON snippets to appear as "show stdout" for each failed test in a Prow job, which is distracting. The what
  16. Good commit subject / body e2e: remove JSON progress output

    on stdout The original intention was to address "frustration of end users running the e2e suite is that they take a significant amount of time and it is difficult to gauge progress". But Ginkgo's output is different now than it was in Kubernetes 1.19. If users want to see progress, then "ginkgo --progress" might provide enough information. Printing to os.Stdout doesn't work as intended anyway when output redirection is enabled (the default for parallel runs) and causes these JSON snippets to appear as "show stdout" for each failed test in a Prow job, which is distracting. The why
  17. - Smaller commits are easier to review - It’s easier

    to scope and write a commit message if it relates to a smaller change - It’s easier to do backports Different commits for different sections
  18. - The maintainers care about the project, not the thing

    you are proposing - You need to earn their trust - You must convince the maintainers that the project will benefit from what you propose - The quality of what you submit must be high Wrapping up