Extend crediting UI to include organizations & customers

Could you show how this looks with a lot of authors? I wonder how this scales.

Note #2323715: [policy, no patch] Determine format for commit credit for individuals/organizations/customers has not decided on the format of the commit message.
So, is this issue just for the table?
The sample in https://attribution-drupal.redesign.devdrupal.org/node/2418017 lists a user twice (without org or customer on either).

Updated issue summary.

---
I'm not clear on if this issue should also save information in the DB. If that gets saved, or when it would get saved (on comments by a committer when they changed something in the commit summary table?, or on commit? parsing the commit message?).

I'm not clear on what "previously-credited" suggestions refers to. Is that in the case of multiple commits in one issue?

Ah, that issue was postponed on having a few months of attribution data before deciding on commit credit format. #2323715-61: [policy, no patch] Determine format for commit credit for individuals/organizations/customers

If that is still the plan, I think for this issue, so that we do not change the commit credit format, we want to consolidate duplicate users to just one user in the commit message.

---

I'm confused by #16

In practice, we will only want it for maintainers who can give credit.

In #2295411-59: Auto-generate Git attribution info / commit messages on Drupal.org there were some reasons why we want this collapsed (but not hidden) from non-committers.

@drumm, I just noticed that the summary still says "Decide if we should store the data in the DB, or just rely on commit messages and parse them." To clarify, we need to store it in the database in order for a maintainer to give credit on a non-code-generating issue. Want me to update the summary?

There is still a question as to what format we store commit mentions, but the actual credit used on Drupal.org can be completely database driven. That will allow us the greatest flexibility.

This might be a few steps too late (or possibly the wrong place), but something came to mind that I'd just like to ask for the rationale.

if we're extending the ability to attribute each comment AND we want to recognise a much wider array of contributions besides just code (presumably in a fair/consistent manner), at this point shouldn't we just give everyone their piece of the attribution rather than relying a maintainers arbitrary judgement?

@rcross, we currently rely heavily on maintainers to give commit mentions. This extends that pattern to a greater degree.

Maintainers giving credit does two things:

1. It prevents gaming the system. Becoming a maintainer takes significantly more effort than creating an account and commenting on an issue. We are acknowledging that maintainers with responsibility to help grow and shape positive contribution.

2. It promotes the value of reaching closure on issues. We will still have issues that stay open for years due to conflicting viewpoints, but maintainers will be able to give credit to those involved in an issue that can reach enough consensus to move to closed complete.

If we see maintainer-given credit is not working, we can look at other options. I think we will know within six months of the feature rolling out.

If this issue is going to hide the credit fieldset from non-maintainers... well. that aught to be a separate issue or this issue should provide a fieldset (or something) that gives that same info to non-maintainers but doesn't allow non-maintainers to *save* the info.

It would be nice to go back and credit old comments, but I don't think necessary for deployment.

Dries emphasized before that is _is_ really important that we be able to query on user => org associations, because we want to be able to study how contributions happen. I'm not sure if that's still possible with option a) or not.

One other thing that catch brought up in one conversation about this or another is that within a given issue, especially if it spans multiple years as many core issues do, the same individual may:

1) Submit work to the issue of their own accord (nights/weekends time). (comment #12)
2) Be paid by Customer Foo to work on said issue. (comment #20)
3) Have the issue assigned to them as part of Employer Bar's work time (comment #50)

We don't want to count the individual credit 3 times, but OTOH we do want to make sure that all three of those "sponsoring" relationships are queryable for the same individual in that issue. Not sure whether any option than c) gets us that.

I think we still need to strip out the duplicates from the commit message that is generated, since this issue is not about changing the format of the commit message.
example "git commit -m 'Issue #2421815 by bacon, bacon, ruscoe, bacon: Multiple_email integration'" should just be "git commit -m 'Issue #2421815 by bacon, ruscoe: Multiple_email integration'"

we should keep the "first" occurrence of the account user name.

Thanks @drumm! This is a good start. I think we all need to discuss how this workflow is:
1) actually intended to work and
2) when orgs/customers should be credited

This appears to literally separate each comment out. Do we need this level of granularity here? Is not the goal here to simply attach this data alongside the individual, opposed to treating it as an entirely separate line item? It feels like this is all about the orgs/customers rather than the individual.

I also feel that one could run the risk of overlooking an individual without and org/custom attached to them. Overall it feels a little bloated, tedious to look at and rather difficult to parse.

I'm not entirely sure what the solution here is yet, but I've gone ahead and marked up some comments and a possible solution to them. Let me know what y'all think.

Summary (before, I checked all for effect here):

Summary (after, they are still all checked):

UI (before):

UI (after):

Edit: Last image should say "shows the real impact they had in the issue at hand" at the bottom.

We could later, have a UI where maintainers could mark *comments* as credit worthy, and that would effect the credit & committing fieldset.

I think the current status is ok to me. (not all the things bacon did maybe credit worthy, and so we would not want to credit an org or customer for those by lumping them all together).

While the other dev environment is being spun up, I changed a few things around on https://attribution-drupal.redesign.devdrupal.org/.. I made bacon a maintainer of both Drupal core and Views, and then I went to https://attribution-drupal.redesign.devdrupal.org/node/2418017 (the core issue with the highest number of replies) and edited some comments to fill in a few values. dawehner in particular I edited two comments, one putting him at Acquia, one putting him working for a customer "Drupal Association."

The default commit credit UI at https://www.drupal.org/node/2418017 (the original issue) looks like this:

In the original commit credit UI, my focus is on two things:

1) individuals (I specifically check those whose great comments stood out in skimming through the issue)
2) issue activity (the green bars and how long they are, so I can credit people who participated a lot, but whose comments didn't specifically stand out in skimming).

I actually really love this UI, and in my "gut" estimation I think this results in about 400% more reviewers being credited than prior to its rollout (at least for credit I personally dole out as a core committer).

The new default commit credit UI at https://attribution-drupal.redesign.devdrupal.org/node/2418017 (currently) looks like this:

In the new version though, now suddenly I get thrown a third thing to think about: organization/customer. dawehner is no longer an individual; he's actually in the list 3 different times, once for each org/customer configuration. Two of them got auto-checked (since they were comments with patches attached), but one of them is not. The one where he's not auto-checked is a comment that was credited to Acquia. So in order for me to tell if I should in fact credit the "dawehner/Acquia" pairing, I need to go back through 125 comments, find the ~25 that were comments of dawehner, meticulously click on each and every little "Credit" box next to each one to figure out if it's from Acquia or not, then once I find the needle in the haystack, make a judgment call on whether or not that's "worthy" of being checked, then scroll back down to the commit credit UI and make my decision. Multiply that X minutes of effort by anyone else in this list more than once.

So, obviously, I am not going to do that. :P And neither is anyone else.

What I am going to do is continue to do what I've always done: scan on 1) individual and 2) effort. Except now, effort is split between multiple entries, which vastly increases the risk that people don't get the credit they deserve. The commit credit system was only rolled out a week ago, but there are approximately 4.7 million comments that pre-dated this rollout. So it's quite conceivable that an individual makes, say, 3 comments from before last week, and another 3 after last week. In the "old" commit credit UI, that'd add up to 6, which would flag for me on 2) effort, and they'd get credit. 3 comments, OTOH, most likely would not.

Who they work for is entirely immaterial to me when I'm in my "doling out commit credit" context. In that context, I only care about the "who" and the "what," not "who's paying to make the what happen." Organizational influence is way more relevant to me when the issue is actively in progress, but it's deliberately hidden during that phase.

So TL;DR I would just consolidate the list of names so we stay focused on individuals, and clump together everyone they worked for during the course of the issue in with their commit credit (similar I think to what Mark proposed). The only downside I can possibly see is that it's conceivable you have an individual who contributes multiple patches on nights/weekends time, then on company time makes some small "looks good, RTBC" comment, and the company wrongly gets commit credit for that one issue. But honestly, who cares? We also accidentally credit people for simple patch re-rolls, etc. I'd much rather err on the side of accidentally doling out too much credit than not enough.

Incidentally, I don't think #43 is workable. At least for me, I do not read all 125 comments in an issue like this. I tend to read only the issue summary, and the last ~5 comments. If it's not clear from doing that what's going on, I tag it "Needs issue summary update" and move on to the next issue.

What would be more workable is #42232: Help Maintainers Manage Issue Priority by Encouraging Voting and "crowd-sourcing" the responsibility of voting on comments to help elevate the really good ones, though I'm not sure if people who come to the issue queue to get things done really want that responsibility/distraction. It'd most likely be "observers" doling out commit credit in this case, which may or may not be desired.

The commit credit system was only rolled out a week ago, but there are approximately 4.7 million comments that pre-dated this rollout. So it's quite conceivable that an individual makes, say, 3 comments from before last week, and another 3 after last week. In the "old" commit credit UI, that'd add up to 6, which would flag for me on 2) effort, and they'd get credit. 3 comments, OTOH, most likely would not.

Exactly! This is way too granular IMO. It has always been my understanding that org/customer attribution credit would be sprinkled on top of individual attributions, not separate it out.

Oops, sorry, #43 was a reference to YesCT's idea for maintainers to effectively "flag" comments worthy of commit mention. But yes, agreed the granularity in the UI is also not really workable. :)

Before we go rearranging the data model here, though, I wanted to be clear that we do still want the granularity on the back-end IMO, so we can continue to do the queries suggested in #28 (we'd also want this granularity in commit messages). The "smooshing" I'm suggesting would be for the UI only, or at least I think so.

I guess as long as it's still possible to tell that a user contributed both as an individual and as a sponsored person within the same issue, that's probably ok. #2453271: Make "I'm a volunteer" an explicit choice in the credit UI might help with that.

For Dries's use case of an accurate picture of how are community works, how many contributions are volunteer vs. paid, etc.

#55 And we'll have to disallow deleting credit-referenced comments?

Sorry that I can't test just now, but what happens if a user comments as both themselves and sponsored by Acquia (or whatever)? Does it show "independent, Acquia" or similar? Because IMO it should, at least for comments after the deployment of this feature. One sponsored comment doesn't undo all the work I might've done in my nights/weekends time. (Not me, per se, but a person.) This was one of the concerns catch raised, that the company credit would "overrule" credit to individuals who were volunteering their time.

However, otherwise, that looks great! Thanks so much for making the change to a list of people instead of "creditors" :)

Ah, indeed that might be a good choice, if that's planned to happen.

Well, once again the issue is not the individual credit. I think it's widely understood that individual credit always happens (or I haven't seen anyone confused on that point at least).

The issue is that if you're donating your own time to resolving an issue, you are making a sacrifice of time that could be otherwise spent sleeping, watching a movie, hanging out with friends and loved ones, knitting, whatever. In short, you yourself are "sponsoring" your work, in terms of time rather than a monetary donation.

So it is considered highly offensive by some who do a lot of volunteering (which is about 95% of core contributors) if companies' sponsorships outweigh/obliterate their own "personal sponsorship." Especially given one single "looks good, RTBC" on company time obliterates the effort you spent as a volunteer on an issue, esp. if that time was spent creating, rolling, re-rolling, re-re-re-re-rolling the patch, etc.

Does that make sense?

ok.

tried both. work well.

I can try and take a look later, but not really sure how to test this given the credit is not yet displayed on org page.

So are there plans for a mass-email to everyone with Git commit access to inform them that they should be using the commit credit UI to explicitly check anyone they feel deserves credit in an issue?

I worry people are still using that UI the same as they ever have, as a starter to a commit message that they then tweak manually. However, unfortunately unless explicitly check more boxes and leave a comment or otherwise save the form, it sounds like that's going to leave non-patch contributing individuals/companies without credit, since for org profile purposes the commit messages don't matter at all.

We are planning a system message for all users with Git vetted for next week. (System messages are likely going to be our default for this sort of thing as we don't have to worry about delivery.)

We should be able to track the usage of credits and tweak it to be more explicit in the UI. I agree that a big "give credit" button that triggers an issue save is a likely solution.

Well, reviewer/non-technical credit right now often happens organically thanks to the existing UI, as noted in #44... it helps surface larger efforts of people who didn't contribute patches. I do agree that issue's still open in that we don't have the "how did they contribute?" granularity yet, but if it's going to be maintainers doling out credit I'm not sure how much of that specification we can reasonably expect them to do.

Oh, and +1 for some small UI tweaks to make this stand out a bit more (but not "marquee" more :D), and thanks for verifying the communication plan. That all sounds great.

fixing