Discuss ways to encourage more valuable contributions through issue crediting

When committing a patch, doesn't the module maintainer have the ability to specify who is the author?

I have re-rolled actually needed changes, and felt bad when I received the credit for someone else's work, however I also noticed that with other re-rolls, I didn't get credit. I'm unfamiliar with how it is from the module maintainer's standpoint, but it looks like it is manually defined. If this is the case, then the problem is a training issue where module maintainers should pay attention and select only people that contributed (rather than automatically selecting the last patch submitter).

I definitely agree this is an issue that needs to be looked into and potentially solved either via training or a way for patch submitters to flag an issue for re-evaluation in regards to credit.

There are also circumstances where the module maintainer doesn't give anyone credit and instead just sets the issue as committed, and applies the changes themselves (which is infuriating).

@kristiaanvandeneynde thank you for the clarification. I had no idea it worked this way.

Not sure if this is the right place, or the customs or content queue. I agree though that this is becoming a problem we need to adress.

IMO, it should go on the Drupal.org customizations queue if there is code to change, and there is an agreement with in which way to change it.

At some point there might be code to change, I think it needs to be here to monitor and figure out how bad this issue is.

This is an important problem statement, and definitely one of the areas of concern for the issue credit system. I know that some maintainers (particularly the core folks) make it a big part of their workflow to be very deliberate about whose credit boxes get checked/unchecked when closing an issue/granting credit. However, as was mentioned above, this puts the burden of moderation on the maintainer.

I suppose the question is: What could be done about it?

• Attempt to automatically detect low quality contribution? (e.g: re-rolls) <-- If we could do that, the bots could patch themselves :)
• Stop defaulting the credit boxes to checked? That puts just as much burden (if not more) on maintainers to make sure they grant credit at all, rather than screening out 'undeserved' credit
• Some sort of 'reactions' system? But this could be spammed as well
• The ability for a maintainer to temporarily/permanently ban a specific user from getting credit on their project? <-- This might work, but it would be yet another way we'd be relying on maintainers for moderation

Just brainstorming at the moment, but curious to hear others' ideas.

As someone who has been burned as well by this problem in the core issue queue, I really like the proposal to take issue priority into account :)

I spoke to hestenet about this issue and braindumped some information and ideas. However, before we write all the things up here that that the DA and committers are already working on related to this, please:

Assume good intentions.

Stop assuming you know why you are seeing the behaviors you see, or what the people behind them are doing. Stop using words like "offenders" and "disgusting". If you'd treated me that way when I eagerly rerolled patches and fixed coding standards, you'd be down a release manager, and possibly D8 wouldn't even be out yet. :P

And also, stop assuming that people doing things like broken rerolls will get credit just because you saw a broken reroll being posted. The two core issues you linked aren't even marked fixed yet, so no one has received any credit for anything. Core is not maintained by robots. Committers go over the crediting section thoughtfully to decide who gets credit when we mark the issue fixed, and if we do make a mistake, it can still be corrected after the issue is fixed.

I'll work with other committers to post a more constructive reply later explaining what committers already do to manage crediting for lower-quality contributions, but please start being respectful of the contributors and companies you're referring to. They're contributing back to Drupal too, unlike thousands of other companies that don't contribute so much as a reroll or a cent.

Just want to add that I agree with @xjm 100% here. When I started contributing to core in 2006-ish, I did a lot of patch re-rolls, docs and coding standards fixes, manual testing when there was no automated tests at all etc.. I was teaching myself PHP more or less from scratch, in my own time while being a new parent, and core contribution was a way to get free training from very skilled people and assist in getting a few bugs that were really annoying me fixed. I was using Drupal for personal projects but not for work. By 2008 I was doing Drupal full time mostly due to very constructive help from people in the core queue.

While a lot of very minor fixes are automated, it's really disappointing to see some of the more minor fixes and re-rolls denigrated as simply gaming. People have been doing stuff like this long before there was issue credit, and often didn't get explicit commit mentions if they only re-re-rolled, but they still did it to keep issues moving/passing test bot etc.

There are ten year old issues in the queue, sometimes older, and many of them have had to be re-rolled literally dozens of times - this in itself can be dispiriting when that's the only attention an issue gets for months. Automated re-rolls and coding standards interdiffs or similar would be great, we don't have them yet.

But intentions and how the marketplace works are two different beasts and we must be careful not to confuse them. The way the marketplace currently works, allows for manipulation. What we are seeing now is, in fact, gaming of the system. Whether it's intentional or not, it's undeniably the case.

The marketplace is only gamed to much the same extent as http://drupalcores.com/ is gamed. drupalcores counts raw commit mentions parsed from commit logs, it doesn't take into issue priority either, and afaik it counts contributions with no time limit (at least since 8.x opened up).

While there has been some level of critique of drupalcores (that it ranks based on quantity rather than quality, even though those do in many cases correlate), no-one to my knowledge has accused any of the individuals on that listing (or the companies listed at http://drupalcores.com/companies.html) of 'gaming' anything, even though people do use 'top 30 Drupal core contributor' and similar in job applications. As soon as similar metrics are applied to the marketplace listing, the tone changes.

Things like adding weighting to critical issues is fine (and for me would be an improvement regardless of any gaming, as long as it doesn't result in issue priority wars (given this already happens especially between critical and major issues)), but there are also many minor contributions made to critical issues - re-rolls, docs fixes, coding standards fixes, sometimes manual testing etc. which are entirely welcome and good even if it would be useful to automate more of these.

@kristiaanvandeneynde, I've already (before I first commented here) spoken to someone at the company that employs the contributor you referenced in your original post, asking about how they might incentivize contribution within the company. Based on the discussion, your posts' implications that the contributions were just intended to manipulate marketplace rankings are not correct. As far as I can tell, what is actually going on at that company is that they have access to a great, enthusiastic mentor who is helping them learn the simple novice tasks we encourage at sprints and in the handbook. For example:

• https://www.drupal.org/contributor-tasks/reroll
• https://www.drupal.org/contributor-tasks/improve-patch-standards

So, unless you specifically have other firsthand information from someone at the same company that contradicts my own secondhand knowledge, you have in fact... well... let's say drawn an incorrect conclusion based on very incomplete data and perspective? :P

I'm not dismissing that contribution crediting (and especially the marketplace ranking based on it) is difficult and sometimes fraught or inequitable. As I tried to explain above, core committers have been observing and managing some of the things that concern you for as long as the contribution crediting system has existed. Others definitely share your concerns.

As I tried to point out above, I'm working with the other core committers to try to provide folks with a more holistic picture on this problem space (not because of this issue node; it's been a backlogged agenda item in core committer meetings for ages).

There are lots of existing infrastructure issues proposing specific adjustments, so the merits and drawbacks of those adjustments are best discussed in the dedicated issues. For example, the notion of weight by priority has been discussed since long before the system was even deployed, and I specifically asked the DA to hold off on it because it has lots of drawbacks (edit: adds more burden on maintainers, incentivizes exaggerating priority, incentivizes the gaming you are concerned about on issues that matter the most instead of just on any old issue, etc.). Still, there is at least one issue for this proposal from wayback and I think @effulgentsia created another duplicate of it recently.

Similarly, we already have consistent expectations among the D8 committers in a draft doc. In a revision to this document from May 24, 2015 (I would almost abuse my webmaster privs to add a blink tag around that), I added a note that "Useless file attachments" should not be credited:

We've followed that as long as the contribution crediting system existed, and meant to make that into a public handbook page for ages, because it will increase transparency, set clearer expectations, and also serve as a resource for contrib maintainers. (Keep in mind though that the time we spend working to create such documentation is time we are not reviewing RTBCs, so your patience is appreciated.)

And so on and so on and so on.

I'm marking this issue postponed while we (DA, core committers, etc.) help provide more firsthand information about this problem space. Edit: As well as examples of effective and courteous ways to encourage more valuable contributions, because I think it's really important to help the community understand how the emotional labor we put into these things effects positive change.

And also, I want to restate that I really actually became the #1 "top" D8 contributor in 2011 by rerolling patches, fixing coding standards in others' patches, and nitpicking documentation.

In particular, I wrote a shell script to reroll patches for the /core directory move and used it on dozens of patches in the span of a couple weeks. It was a very similar situation to the array syntax standards change: one scheduled commit invalidated and disrupted core patches on a massive scale, but patches could be corrected with an automated tool if one just took the short minutes time to curl them down, reroll them, and reupload them. And I did that. A lot.

I didn't do it because I wanted my username to appear in giant letters in a tag cloud in a presentation by Dries (which happened), nor to make the University of Wisconsin (srsly) a big name in Drupal. I did it because I'd found a way I could do a small thing that would save a little pain/annoyance for core contributors who'd patiently helped me when I was struggling with D7 APIs.

People were patient and respectful to me even though I got so much undue recognition for something so trivial (versus calling me "disgusting" or posting issues calling my rerolls spam), and that support gave me the encouragement I needed to keep learning and eventually do things like review 400K API rewrites. That potential could be in any broken reroll, if you take the time to be patient and kind.

This has become crazy. Valuebound employees with hundreds of commits and credits consisting only of short array and $this->t() changes.

This poisons the system of low hanging fruit issues which definitely has great value in attracting more long-term contributors. I've had to start "won't fix"-ing all such trivial patches, and I'm not the only one.

Furthermore, it devalues the whole Marketplace ranking system to see them ranked #2, higher than shops that spend hundreds of thousands of dollars contributing to Drupal. It's also detrimental to Valuebound itself, cause now people get to associate them with gaming the system and producing no value, even though they also have real Drupal people doing real work (#2854495, #2856505, just in my queues).

We are currently working on making testbot automatically apply coding standards fixes #2881456: Phpcs: automatically generate patch to fix coding standards violations and link them on issue #2851916: Expose phpcs patches to comment stream which will remove trivial coding standards cleanups on larger issues as a way of receiving issue credit. We will only deploy it for core at first, but eventually it should be rolled out for contrib as well.

Core also has strict issue scope guidelines https://www.drupal.org/core/scope to prevent racking up trivial credits for issues only about coding standards fixes.

It is still up to the maintainers of each project to determine who receives credit and what patches they will accept. Core maintainers are very thoughtful and careful about credit -- we do not credit broken rerolls or other unhelpful attachments, and if you see that credit has been granted for such an attachment for an issue that has been marked fixed, please inform a committer and we will remove the credit. (Edit: Keep in mind that only issues that are marked fixed with a comment from a maintainer receive any issue credit, and we evaluate credit at the time of commit.)

If maintainers grant credit for unhelpful contributions, that is the maintainers' fault, not the contributors'.

For what it's worth, after having discussed it with @catch, I do support a slight Marketplace weighting by issue priority, at least a slightly lower weight for minor issues, so long as the issue priority field cannot be changed by non-maintainers after an issue is fixed. (I still would not add weighting for normal vs. major vs. critical until we see how it goes with minor issues, because I don't want to incentivize priority wars if we don't have the capacity to manage it as committers.) This will require infrastructure changes, and I'm pretty sure a dedicated issue might already exist for it.

There are in fact dozens of dedicated issues for thing surrounding this, so people who are very concerned about this problem could invest their energy in linking the issues here and writing an emotionally neutral issue summary that respects attempted contributions while also listing the issues that attempt to fix it.

Also, @kristiaanvandeneynde:

Also, if I were mentoring people I'd sure as hell wouldn't have them spend days running the same script and then copy-pasting the same text all over the issue queues. That would be pretty awful mentoring if you ask me.

Until I see you spending your DrupalCon working with other overworked volunteers trying to scale to the demand of hundreds of people who want to give back to Drupal but don't know how, you have no context to make such judgments. The sprint mentor signup form for Vienna is here: https://events.drupal.org/vienna2017/sign-up-to-mentor

@bojanz:

It's also detrimental to Valuebound itself, cause now people get to associate them with gaming the system and producing no value, even though they also have real Drupal people doing real work (#2854495, #2856505, just in my queues).

Thank you for recognizing this. To me, this is actually the most important problem, because the hostility directed at companies and individuals who are trying to contribute is toxic.

Asking us to PM a core committer for incorrect credit someone else got doesn't feel right. No-one wants to be "that guy" who "snitches" on his colleagues. I'd rather see this being discussed publicly than privately.

As I have documented above, core committers do not intend to grant credit for a broken reroll. Therefore, you are not being a snitch if you tell a core committer that credit was granted for a broken reroll. You are helping a committer, who is a human being, correct a minor oversight that is easily corrected. And it's appropriate to do so in public, if you post politely that it appears that credit was granted by mistake in a scenario where it is documented that credit is not normally granted.

There is value in helping good programmers become great programmers.

So you go do that, then, and stop passing judgments on the core mentoring program and the mentees they have taught who are in turn mentoring the people you are judging, or being insulting on this issue about the mistakes of novices. Until you have mentored novices at a DrupalCon and know how draining and exhausting it is to meet the demand of hundreds of people trying to set up a dev environment for the first time and work on a first core patch, you are not in a position to be passing judgment on what the documented novice tasks are. When you have 10, 15 peoeple needing your help all at once, it's not really possible to sit down and teach someone how to be a better programmer. What you can do is give them a simple task they have the background to complete, and help them perform that simple task in a minorly helpful way on a core issue.

And even if I hadn't, I still stand by my statement that having someone run a script 24/7 teaches them little to nothing. It doesn't take an overworked volunteer to figure that out.

Why do you think anyone told anyone to run a script 24/7? See my story above about the core/ move rerolls and why I did them. No one told me to do it and I thought I was helping. And people thanked me for it, so I was helping. And all I was doing was running a script and attaching new patches to issues with the script run on them. Now I'm a release manager, because people weren't jerks to (or about) me when I was just a noob doing a noob thing and they got the same amount of credit I did.

@kristiaanvandeneynde, I've just checked the issue you linked, and the reroll was not sloppy or broken. It applied, had all the needed hunks, and was a necessary reroll as your previous patch did not apply at the time (I checked out commit hashes on the relevant days to verify this). Furthermore, @tstoeckler also said it looked good.

So, the individual contributed to the issue, and therefore has received issue credit for it.

I apologize for participating on the offtrack discussion here in the most recent comments. I don't think this issue thread is helping solve anything at this point, so I am closing it "works as designed" (because in the two examples given in the original issue report, it is working as designed).

If you want to help resolve instances of repeated low-quality contributions, help by mentoring the person you see making a low-quality contribution, using constructive feedback and writing your comment in a way that assumes good intentions, or contribute to the higher-level problem by helping with the dozens of existing issues around improving the contribution crediting system, automated rerolls, automated coding standards cleanups, etc.