Benji Fisher
I believe in contributing to open-source software (OSS).
I started contributing to the Vim text editor in 2001, and I have been giving back to Drupal since 2011, before I ever had a paying job working in Drupal. I have contributed code, provided support, written blog posts, presented sessions at conferences, and mentored new contributors. These days, I focus on writing and reviewing patches for Drupal, and I regularly attend the weekly Drupal Usability meetings (and sometimes run them). In 2020, I became one of the co-maintainers of Drupal's Migrate API.
I have the usual, rational reasons for wanting to contribute: it improves my reputation, it lightens my maintenance burden, and I feel an obligation to do my share after benefiting from OSS. But my primary reason for contributing is that I hate the idea of duplicated effort. If I have solved a problem, why should someone else have to solve it again? If I can contribute code to Drupal or some other project, or explain my solution in a blog, or write one of the most popular Vim plugins ever, then I have taken a small step to making the world a little better, or at least more efficient.
I believe in helping my team.
As a contributor to Drupal core, I am part of a world-wide team numbering in the thousands. In my regular work, I am part of smaller teams, and I understand that a properly functioning team is more than the sum of its parts. This is the basis for some of the Agile principles: for example, unblocking another team member always has priority over working on my own assignment.
In my experience, one of the best ways to share knowledge among a team is through code reviews. The learning can go either way: sometimes the reviewer suggests a better approach than the first draft, and sometimes the reviewer sees something new in the code. We usually sell code review as a way to catch errors early and improve code quality. This is true, but less important than spreading knowledge (both project-specific and more general) among the team.
I believe in writing reliable, maintainable code.
That means good documentation, from code comments and commit messages to wikis and READMEs. This principle ties in with some of my earlier points. I structure my commits with the idea that someone will review them, and I want that review to be as painless as possible. When I join a project and have trouble setting it up, I take notes and share them, since I know that I will not be the last person to have the same problem; and if I have already solved a problem, why should someone else have to solve it?
