Let's Start a Conversation
Dear friends,
Over the past few weeks there have been some conversations among many of us regarding the issue credit system and how it could be used to "game the system." This started with a conversation in a Slack team asking if a d.o user was a bot because of the number of issue credits attached to their profile. At the time it was around 550 in the past year. There was assurance from someone who knew this person that the person in question was not a bot, however a cursory look at the issues they had been credited for revealed that the majority of these issues were issues that could be considered Novice level and were very similar to each other.
I didn't think much of it until I pushed a custom module into the contrib space, and within 30-60 minutes I received an email notice from d.o saying an issue had been opened on my module. My brand new, still in alpha, less than an hour old module. I read the issue and two things stuck out:
- The name of the person creating the issue.
- The verbiage used in this issue.
These stuck out because it was the exact same person who had been brought up in Slack and the words were an exact copypasta of issues I had looked at when trying to figure out how this person had earned so many credits without being a bot. I did a little more looking into it and noticed that the issue description was exactly the same as other issues opened by this person, and so was the comment. I copied the text of the comment and pasted it into Google and found that there were 8 pages of results with this exact same text, almost all of them were opened by this person. This did not help claims of being a definite human not-bot.
What's Wrong With This Picture?
Now why is this an issue, you may be asking. Why do I care and why am I making a fuss about it?
Let me preface this by saying that I don't care about the number of issue credits by my name. My skills (or lack thereof) speak for themselves, as does my reputation. I'm happy in my current position, I have a reasonable grasp on what I do, and even though I don't have a ton of credits next to my name, I consider myself a member of the community and an asset to the Drupal project.
As for making a fuss about it, there are three main reasons that I'm bothered by this situation.
Reason 1.
We've all seen the CMS Learning Curve image, right?
If not, here it is.
This has always been a joke within the community. Drupal has a high barrier to entry from a developer perspective. Drupal 8, even moreso than Drupal 7 which (IIRC) is the version that earned Drupal's place on this infamous image.
Because of this barrier, we've tried to make it possible for new contributors to get comfortable with contributing through issues that are tagged "Novice". These issues are often documentation, coding standards, or basic code fixes that can be handled by someone who may not have as much experience contributing to the project, whether it be the core Drupal project or contributed modules.
These novice issues are important to have. Sure, they may take some of the core maintainers or more advanced developers a few minutes to handle, but if they're not critical then there's no reason to not utilize them to help bring in new talent and give novice contributors a chance to get into the weeds a bit.
Looking through this person's issue credits, every single issue I found has been a novice issue. I did not take the time to look through all 570 credits to verify this, but my sample size was large and based on that sample, I'm willing to wager that the vast majority of these issues would have made for decent entry points for new contributors. With one person collecting all of the proverbial "low-hanging fruit" to pad their profile, this effectively gates new contributors from having the opportunity to help the project and removes upwards of 570 novice issues that would make perfect entry points for novices, not counting issues that have not been credited yet.
Reason 2.
In speaking with some other developers, it's demoralizing. This person was recently mentioned in a tweet as "the most impressive http://Drupal.org profile page I've ever seen". I'm not trying to say that these issues aren't important, and if they improve the project overall, then it's a good thing that they're being handled, but the process and the "reward" system makes it seem like the problems are larger than they really are.
Imagine this scenario, please: Developer A has taken the challenge to move from novice issues to something a little more advanced and spends twenty four working hours debugging an issue in core that is preventing an entity from saving under certain circumstances. They find the problem, discuss it with the core maintainers on Slack, toss ideas back and forth on the issue node, create a patch, create tests, submit the patch, wait for RTBC, and the patch gets committed. The project is made better because Developer A is passionate about Drupal, they spent their free time trying to improve Drupal, and when the patch is committed, they get credit for the issue. This credit is worn as a badge of honor on their profile. They feel pride in what they've done and what they've given back.
Developer A is scrolling through Twitter and sees mention of Developer B as "the most impressive http://Drupal.org profile page I've ever seen" and wants to know what their secret is. Developer A starts looking at the issues, and finds that the "impressive" profile is primarily novice issues that can be handled in a matter of minutes, yet they're the ones marked as "impressive". Developer A feels like their credit is devalued because the only thing seen on the profile is the number, not the number of issues by difficulty or number of lines in a patch, but number of issue credits.
Developer A decides that contributing back isn't worth their time because the only thing that seems to matter is the number of credits. Drupal loses a talented contributor, and the project is poorer for it.
Reason 3.
The Drupal Marketplace page puts weight on the number of contributions over the last 90 days in its ranking system. Outwardly, this would seem to reward companies who invest in improving the Drupal project, and it does. However, it also incentivizes companies who hire new developers who are just thrilled to have a job into positions that exist only for the sake of getting their company to the top of the marketplace. This is unfair to other companies who may not have the budget, but still contribute how they can, and it's unfair to the employee who is stuck searching for module releases, looking for novice issues, and copying and pasting descriptions and comments to get more and more credits.
In a sense, it's gating the employee from being able to move on from this position because even though they have 570+ credits, they've potentially never done anything past that. I'm not claiming that the person who sparked this conversation doesn't have skills, but churning out that many bug reports and quickfix patches doesn't really empower that person to show what they're really capable of. I know if I spent all day doing the same thing over and over, I definitely would not want to even look at a text editor on my free time, let alone feel that it would be worth it to try and expand my skill set.
Possible Solutions
There is no one-size-fits-all solution for this. Hell, there's probably no good solution at all. However, here are some ideas that I would like to throw out there that are just that, ideas. They're not fully fleshed out, and they aren't ultimatums of "Do this or I'm going to walk!" They're potential starting points and hopefully help to spark a larger conversation.
Solution 1: Weighted Credits
Not every credit should be worth the same as others. There could be a number of ways to do this, but in my opinion the easiest way would be to weigh by difficulty of the task. A novice, non-critical issue could be weighted less than an advanced, critical issue.
Pros:
- Could incentivize contributors to move up in difficulty of tasks.
- Gives contributors who spend a lot of time on difficult issues more credit than contributors who seek out the easiest fixes.
- Rewards growth as a developer.
Cons:
- Difficult to implement.
- Creating a weighting system can be difficult and fairness cannot be guaranteed.
- Valuation of an issue is subjective and could be gamed if a module maintainer decides to start tagging every issue as "Critical" or similar.
Solution 2: Mandatory Difficulty Tagging
The word "Difficulty" is difficult here. Some other possibilities would be "severity", "level of effort", "need", or any number of words that could be placed there. The point is that for this solution, I recommend creating a specific taxonomy that relates to difficulty or [insert word here] of the issue. This would be mandatory before marking an issue as fixed by the maintainer, whether it be a contrib module maintainer or a core committer. Then, on a user's profile credits could be divided by rating. For example: User Credited on 50 "Novice" issues, 3 "Intermediate" issues, 15 "Advanced" issues, and 3 "Critical" issues.
Pros:
- Makes it easier to discern how much effort is actually being put into contributions.
- More transparent for potential employers looking at d.o for references.
- Creates a weight system without actually having to weight contributions.
Cons:
- Puts the responsibility on module/core maintainers to assign difficulty, which can be very subjective.
- Does not prevent a module maintainer from marking their own issue as "Critical" when it could easily be tagged "Novice"
- Potentially devalues novice credits and gates new contributors.
Solution 3: Credit limits
I'm of the opinion that if someone has over 100 novice credits, they should probably be at a point where they are either taking on more serious issues and leaving the novice issues as entry points for new contributors. This solution would still require tagging of issues by maintainers, but instead of creating tiers based on difficulty it would limit the number of "novice" issues a contributor would receive credit points for. The number would have to be decided and I don't know if it should be 10 or 100. I'm just spitballing here.
Pros:
- Incentivizes contributors to move on from novice issues.
- Keeps novice issues for actual novices.
- Creates more entry points for new contributors.
Cons:
- May deter non-novice contributors from taking on novice issues that need to be done.
- Again, module maintainers may tag issues inappropriately to ensure credit.
- The term "novice" is very subjective and could easily be debated.
Solution 4: Redistribution of Credits
Sorry, my politics are showing on this one, but I don't mean take credits from the top 1% and give them to the bottom 25%. Instead, give others a chance to take on the tasks and open the gates to new contributors. The issues that are being created, fixed, and credited are issues, but they're mostly novice issues. My Google-fu returned over 20 pages with identical descriptions. I don't know exactly how many because I just stopped clicking "Next Page" when I hit about page 15, but it's safe to say that this person knows how to fix this issue.
Great. Good job. Now give someone else a chance!
If the goal of these issues is truly to move the project forward and not just farm credits like a World of Warcraft sweatshop circa 2008 CE, then let's get some new people contributing. Create the issue, tag it as novice, and let it be. Find an upcoming camp and tag it with that camp so that if there is a space for contribution and/or a beginning contributor workshop, there are plenty of issues to work on to help get the new contributors comfortable with the steps needed for code contribution. If it's critical, go ahead and fix it. If it's non-breaking and a good chance for someone to learn some git-fu, how to branch and create patches, how to comment in the issue queue, how to push up a patch in a comment, and the lifecycle of an issue from creation to RTBC to fixed, then let it be for a bit.
If there's no movement after a few days or after the camp it was tagged for, then go ahead and fix it. Sure, maybe the module maintainer will fix it in the meantime. Maybe it'll get marked as "Closed: Outdated" because it's already been taken care of on a dev branch that just hasn't made it up to d.o yet. Maybe, just maybe, a new contributor in the wild will be searching the issue queue for novice issues to get started and they'll take the reins on the issue and get their first credit. You may not get credit for authoring the issue, but you'll definitely get a warm fuzzy feeling for helping foster a new contributor into the world of Drupal. That's truly what building community is about.
Pros:
- Gates are open for new contribution.
- Knowledge is shared and the community grows stronger.
- You can almost hear the DING when they level up into the world of open source contribution.
Cons:
- Won't necessarily get credit for every issue created, but we shouldn't be here just for credits.
- Issues may become stale and overlooked.
- That's all I can think of...
Closing Thoughts
This post is not meant to attack any person or any company. If anything, I hope that it sparks some conversations and helps make the Drupal project richer and more diverse by helping spread the wealth of entry-level issues and credits to people who may or may not have opportunities otherwise. Since I began writing this post I've tried keeping an eye on things in the issue queues and I found that some people are taking the example from the account that got me thinking about this and running with it. I've even seen some people trying to patch core testing modules with the .info.yml Dependency Namespacing issue. Fortunately these were caught pretty early and core maintainers made it a point to redirect the issue reporter to fixing more than just one file in core in a patch.
The credit system is great and it rewards hard work, but the issue credit system has issues with credits and needs some work as well. I have brought this up to both the CWG and the DA and they're understandably in tough spots. Yes, fixing issues definitely makes the project better regardless of how small the issue is, but there are thousands upon thousands of developers out there just looking for a project to grab onto and start working with. We need to make it as easy as possible for these people to jump in and become part of the Drupal community. I travel for a lot of camps and, unfortunately, for the most part I see a lot of the same faces in the contrib rooms and areas. I would like to see some new people feel welcomed the same way I felt welcomed at my first contribution days when I was able to get my first patch committed to core. Sure, those maintainers could have taken care of the issue and taken credit for themselves, but instead they created the issue and passed it to me, an eager entry-level developer still trying to find my place in this crazy Drupal world.
We shouldn't have to rely on the CWG or DA to police these things. We should be able to police ourselves. We should be able to know if what we're doing is self-serving or if it for the betterment of the Drupal project and the Drupal community. We should be able to feel good about the credits we get and the credits we help others get. We should try our best to be good people and do the right thing whenever we can.
We shouldn't reward companies or individuals who hoard issue credits just to look better on the marketplace or in a wordcloud on a powerpoint. We can do better than that.
If you're a new developer or an aspiring contributor looking for something to do to contribute back to the project, contact me. I'll help you find an issue to work on and run you through the process of patching, commenting, testing, and whatever else it is that you need to succeed. I want to stress that you don't need to know how to code to contribute back to Drupal. Ask me how!
If you're a seasoned developer or contributor, I challenge you to mentor someone who's eager to learn. Give up a credit or two to someone who is looking for that first DING. Take the time and we'll all be better for it.
Sincerely,
JD Flynn, Drupal Developer and Community Member