logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

FOSS-contributor-tracks.md (4219B)

    

  1. ---
  2. date: 2019-07-29
  3. layout: post
  4. title: FOSS contributor tracks
  5. tags: [maintainership, free software]
  6. ---
  8. Just like many companies have different advancement tracks for their employees
  9. (for example, a management track and an engineering track), similar concepts
  10. exist in free software projects. One of the roles of a maintainer is to help
  11. contributors develop into the roles which best suit them. I'd like to explain
  12. what this means to me in my role as a maintainer of several projects, though I
  13. should mention upfront that I'm just some guy and, while I can explain what has
  14. and hasn't worked for me, I can't claim to have all of the answers. People are
  15. hard.
  17. There are lots of different tasks which need doing on a project. A few which
  18. come up fairly often include:
  20. - End-user support
  21. - Graphic design
  22. - Marketing
  23. - Release planning
  24. - Reviewing code
  25. - Translations
  26. - Triaging tickets
  27. - Writing code
  28. - Writing documentation
  30. Within these tasks there's room still for more specialization - different
  31. modules have different maintainers, each contributor's skills may be applicable
  32. to different parts of the codebase, some people may like blogging about the
  33. project where others like representing the project at conferences, and so on. To
  34. me, one of my most important jobs is to figure out these relationships between
  35. tasks and people.
  37. There are several factors that go into this. Keeping an eye on code reviews,
  38. social channels, etc, gives you a good pulse on what people are good at now.
  39. Talking with them directly and discussing possible future work is a good way to
  40. understand what they want to work on. I also often consider what they could be
  41. good at but don't have exposure to yet, and encourage them to take on more of
  42. these tasks. The most common case where I try to get people to branch out is
  43. code review - once they've contributed to a module they're put on the shortlist
  44. for reviewers for future changes to nearby code. Don't be afraid to take risks -
  45. a few bugs is a small price to pay for an experienced contributor.
  47. This also touches on another key part of this work - fostering collaboration.
  48. For example, if someone is taking on a cross-cutting task, I'll give them the
  49. names of experts on all of the affected modules so they can ask questions and
  50. seek buy-in on their approach. Many developers aren't interested in end-user
  51. support, so getting people who are interested in this to bubble up technical
  52. issues when they're found is helpful as well.
  54. The final step is to gradually work your way out of the machine. Just like you
  55. onboard someone with feature development or code review, you can onboard people
  56. with maintainer tasks. If someone asks you to connect them to experts on some
  57. part of the code, defer to a senior contributor - who has likely asked you the
  58. same question at some point. Ask a contributor to go over the shortlog and
  59. prepare a draft for the next release notes. Pull a trusted contributor aside and
  60. ask them what they think needs to be improved in the project - then ask them to
  61. make those improvements, and equip them with any tools they need to accomplish
  62. it.
  64. One role I tend to reserve for myself is conflict prevention and moderation. I
  65. keep a light watch on collaboration channels and periodically sync with major
  66. contributors, keeping a pulse for the flow of information through the project.
  67. When arguments start brewing or things start getting emotional, I try to notice
  68. early and smooth things over before they get heated. At an impasse, I'll make a
  69. final judgement call on a feature, design decision, or whatever else. By making
  70. the decision, I aim to make it neither party's fault that someone didn't get
  71. their way. Instead, I point any blame at myself, and rely on the mutual trust
  72. between myself and the contributors to see the decision through amicably. When
  73. this works correctly, it can help preserve a good relationship between each
  74. party.
  76. If you're lucky, the end result is a project which can grow arbitrarily large,
  77. with contributors bringing a variety of skills to support each other at every
  78. level and enjoy the work they're doing. The bus factor is low and everyone
  79. maintains a healthy and productive relationship with the project - yourself
  80. included.