Commits on Drupal.org
I'm a huge advocate for finding ways to encourage more Drupal participants. Due to the complexity, it's unreasonable to expect people to initially pick up programming-heavy issues. This is the motivation behind the "novice" label, providing a means for identifying potentially low-complex tasks new contributors could safely pick up. The end result is usually one or more commits which are credited to you and/or your organization on Drupal.org.
Commit Bias
For those looking to bolster their Drupal expertise, organizations will often look at who has "given back" to Drupal as a means of vetting. The same can be said for hiring of technical candidates. It is quite appealing to find someone who has contributed a large number of commits to larger, heavily used projects or to identify someone who maintains such projects. There is no stronger evidence: you can see their work first hand. But, this bias is more complex than meets the eye.
Sam Mortenson alluded to this in a recent Twitter thread, which paralleled thoughts I have had based on recent activity I have seen on my projects:
A lot of @drupal.org users are beefing up their profile through code standard issues, how do people feel about this? pic.twitter.com/ACnAhEF3j0
— S.A.M. (@DrupalSAM) August 12, 2016
The Conflict
With progress comes conflict. There is conflict in the optics of certain types of commits. If someone can be measured by their number of commits and the projects they contribute to, an easy strategy is to clean up coding standards, typos, and minor commenting in major projects. I've seen this taken to an extreme where contributors appear to intentionally file multiple issues and multiple commits for each individual code standard violation, in lieu of addressing all within the same commit. In short, a commit for a one-line spelling error weighs the same as a substantially complex and impactful technical contribution. Coding standards evolve and, as a human, there will always be typos and issues with comments in code. This trend is not going to go away.
I am quite conflicted by this.
- Coding standards and typos are important
- Contribution in any form is important
- I want more people to participate
- I don't want people to abuse the system
- I don't want to de-value the more technically advanced work performed by experts in the community
To summarize, I'm all in favor of increased participation if those participating are trying to not abuse the current practices we've established as a community.
Challenging Optics
What are some ways that we can improve on this? First, we need a recognition that the current evaluation system is flawed and we need to explore steps to help improve this.
As a maintainer of many projects, I rarely label issues and I should. We need more data that helps to classify issues and their respective commits. It would be useful to see advanced contribution metrics on drupal.org profiles outlining the level of complexity in the issues people resolve or even the lines of code impacted.
As an evaluator of talent, deeper research is needed to understand individual contributions. Before we hire, I always dig into the actual commits people have contributed. I have seen applicant posturing their community involvement only to find their contributions were technically under-whelming. I could see how it would be challenging for those that do not know Drupal to know to do this. I think we need to better communicate this to help ensure those that want to use Drupal have better means of evaluating talent.
I think we need to consider enhancing our community practices and documentation to define expectations that discourage abuse. We should encourage maintainers to be more proactive in using data metrics in their issue queue. We should define more standards on what constitutes a commit. And, we should promote a practice in which maintainers proactively avoid giving commits for those attempting to game the system, even at the expense of perceived progress.
Moving Forward
This all may seem a bit heavy handed, biased, or even counter intuitive to community building, but we need to respectfully acknowledge that the current system can be indirectly manipulated and that this can damage the community or adoption of Drupal. I appreciate Sam opening up this conversation and I will appreciate the progress we, as a community, agree to make.