Problem/Motivation

In http://buytaert.net/a-method-for-giving-credit-to-organizations-that-con..., Dries proposed a commit message format that would allow providing credit to customers and agencies who fund contribution back to Drupal.

The goals around this are three-fold:

  1. Give credit to the funders of work in the community. The hope is that exposing this credit will give companies incentive to give back more.
  2. Study how the community works, by studying the relationships between customers, agencies, and volunteer contributions and how and where the money is flowing.
  3. Clearly identify "teams" of people who work for the same employer/customer (and thus raise potential conflicts of interest on controversial issues)

The idea seems to have a pretty broad base of support, both from business people and from individual contributors, even outside of Drupal.

This issue is to figure out how to make that happen on Drupal.org.

Proposed resolution

Start with a UI for collecting credit information on issues and store this in the database. Over time, expose this information on organization profiles and use it in other ways (e.g. sorting the list of marketplace vendors by biggest contributors).

  1. Expose fields in issue comment form for "attribution." & Display organization/customer info in node/comment view
    #2340363: Add issue comment attribution
  2. Auto-generate commit messages with org credit since obviously this will not be sustainable for a human to figure out on every commit. See also #2295411: Auto-generate Git attribution info / commit messages on Drupal.org
    #2369159: Extend crediting UI to include organizations & customers
  3. Add contribution info to organization pages No mockup yet.

In order to support that, we need the following:

  1. Make the current "Organizations" profile field an entity reference off to canonical organization nodes. #2323705: Add user's organization computed reference field
  2. Possibly others.

Remaining tasks

  1. #2295411: Auto-generate Git attribution info / commit messages on Drupal.org
  2. Resolve the child issues.
  3. Do that.

User interface changes

See above.

API changes

None?

Comments

webchick’s picture

Issue summary: View changes
drumm’s picture

See also #968994: Multiple Values for listings of current companies and organizations. The issue comment form is already complex, so we'd want the select box to only show companies someone is affiliated with. I think the dereference_list module we use for issue components may help the customish code down.

drumm’s picture

Issue summary: View changes

The Git log message parsing is Git-specific, I think the change will land somewhere in http://cgit.drupalcode.org/versioncontrol_git/tree/includes/plugins/repo...

webchick’s picture

Awesome, thanks for the initial pointers!

webchick’s picture

Ok, step 1 is having some means of adding this information to a patch, or really to a comment, since reviews are valuable contributions as well.

We already track "Current company or organization" (single value) and "Companies worked for" [in the past] (multivalue). I think we'd probably want to change "Current company or organization" to multiple value instead. (This would have some implications for the logo display logic on user profiles, but hopefully nothing too terrible.) This would cover what I think is most peoples' situations, which is they have an employer, then 3+ customers who they work on for said employer, then their on-the-side freelance gig, etc.

We also track past organizations, which might be good to surface here, esp. if we could go back and edit old comments to attribute them. Not 100% sold on this though, since "worked for" is not the same as "worked on their site." Maybe we need different profile fields altogether for this, "Current customers" / "Past customers". Hm.

At any rate, let's assume for the moment that that's sufficient to list the organizations your comment may or may not be affiliated with. (I think it might be, but haven't really thought it through that much, e.g. what to do in cases where NDA prevents you from saying who the customer is... I guess in that case they don't want organization credit for your work, though. :D)

Simplest thing I can think of is adding this to the "Issue metadata" box, and biggest place where there's screen real estate to spare is the issue tags field. So what about something like this? (That probably needs to be a multi-select field as well. Hm.)

New organization field that contains list of both current/past organizations. (full-size version)

Tricky thing is that this field would affect the comment metadata, whereas the rest of the fields here affect the node metadata. Given that, we might want to just stack it below e.g. "Text format," but that also pushes it a lot more "in the face" of people who are not contributors, which is definitely not the goal.

Then, we need a way to display this information in the issue itself. Maybe something like this:

webchick 'on behalf of [link]Acquia[/link]' commented on date

The specific phrase that's used there is very important to get right, and will likely need lots of bike shedding, so please focus on the placement, not the words for now. :)

webchick’s picture

Showed this to Dries for a quick peek and he noted that being able to credit end-users / customers of Drupal, not just Drupal organizations/employers, was a critical piece of the proposal. So we need something more like this, with opt groups or whatnot:

opt groups of 'Organizations', 'Customers', 'Past'

But I'll work with him to draft up something that he likes. :)

drumm’s picture

webchick’s picture

Status: Active » Needs review
FileSize
69.3 KB

And then finally, the attribution itself would happen along the lines of #2295411: Auto-generate Git attribution info / commit messages on Drupal.org, in my mind:

New git attribution info box below every patch upload that shows recommended commit string, including org/customer info.

What do you think?

xjm’s picture

I'm not sure if this is just an implementation detail of the mockups, but I would strongly, strongly encourage us to not overload the commit message with the data. I think we could also make a field to supply it as git notes.

Edit: Meant to say, I like the look of the mockup in #8 other than that point. :) Nice to attach it directly to a patch.

webchick’s picture

Yeah, the commit message munging was part of Dries's original proposal. But one of the todo items of this issue is to figure out the proper format for this. I agree git notes is probably the way to go, but we need to come up with a template (ideally one that works across multiple software projects, not just Drupal) it needs to be really easy to copy/paste for maintainers.

jhodgdon’s picture

So... Consider this use case:

On a particular issue, let's say person A adds a patch and wants to credit her company Z. Then person B adds a patch and wants to credit his company Y. And person C goes back to person A's patch, modifies it, makes a new patch, and wants to credit his company X.

As a committer, I decide that person B's patch was not useful (or maybe it was uploaded to the wrong issue or whatever), and I want to just credit person A/C for the commit, so I should also just credit company Z and X, but not Y. Will there be an easy way for me to collect that information? There needs to be, or this becomes a huge burden (especially on a large issue) for the committer to gather the company information together.

webchick’s picture

Yes, that's the goal. The user would self-identify their individual comments as coming from a particular company (or not). Then either a tool like Dreditor (or ideally Drupal.org itself) would extract those company associations that were on comments with patches associated, just as it does now, just formatted slightly differently.

So in that auto-generated string, you'd get something like:

Issue #42 by A@Z, B*Y, C@X: Issue title here.

(The * vs @ is for customer vs employer distinction; doesn't really matter here, just showing it as an example.)

Then you as the committer would edit out B*Y from the message prior to using it, since you didn't end up using their patch at all. Exactly the same as right now you might remove ", B" from the commit string auto-generated by Dreditor.

Make sense?

jhodgdon’s picture

Does that mean that a particular contributor could only supply one company for credit?

webchick’s picture

Oh, I see. In the current proposal, yes. Each comment (and any patch that's uploaded as part of that comment) is associated with only one company.

[mind-wandering]
That might not be desirable in the real world, though. I guess when I was doing work at Lullabot I might want to credit both Lullabot and e.g. Sony with work I was doing on Features module related to a Sony website? And for someone like yourself, probably both PoplarWare and CustomerX, so your own consulting company gets credit for the work you're contributing back as part of your customer work. Are there situations where you'd credit multiple customers though? I guess maybe if your work was sponsored in some way by multiple parties... for example, the distribution tools re-work that Phase 2, Acquia, NodeOne, Pantheon, and Lullabot supported. In theory, dww could've credited all of those "customers" for any commits / comments related to the work, in addition to 3281d Consulting.
[/mind-wandering] ;)

Ok, then, need to do a bit of thinkering on how multiple company credit might parse. Issue #42 by A@Z, A*Y, C@X: Issue title here. is easy enough, as long as each individual was only credited once per commit in whatever algorithm any leaderboard script like http://ericduran.github.io/drupalcores/ is using.

webchick’s picture

Ok, Dries and I had the chance to sit down and talk more about this the other day. His feedback was:

- We should make the distinction between customer + employer clearer; perhaps as two different fields. Also make the distinction “I’m doing this on my own time” clearer as well. (Distinction between freelance vs. volunteer?)

- If we move to using Git notes for this (which would probably make the most sense), we should probably remove the usernames from the commit messages themselves (which would eliminate a Drupalism as well). So for example something like:

git commit -m ”Issue #2125621 by davidhernandez, mgifford, jessebeach, mparker17, anandps: Fixed Contrast between title/slogan and header is too low.”

This would now come out instead as (for argument’s sake, saying David Hernandez did enough work on this to deserve the “author” flag, and totally guessing at orgs/customers just to show the various permutations):

git commit -m “Issue #2125621: Fixed Contrast between title/slogan and header is too low.”  --author=“David Hernandez <foo@bar.com>” —git-notes=“davidhernandez*New Jersey Something Something
mgifford@Open Concept
jessebeach@Acquia
mparker17@Open Concept*Government of Canada*Whitehouse
anandps
”

Or, if we wanted to be *very* explicit, we could include the uids/nids there to allow for tracking stats despite changing user/company names:

git commit -m “Issue #2125621: Fixed Contrast between title/slogan and header is too low.”  --author=“David Hernandez <foo@bar.com>” —git-notes=“davidhernandez[261131]*New Jersey Something Something[756332]
mgifford[782321]@Open Concept[543211]
jessebeach[27123]@Acquia[21322]
mparker17[1717171]@Open Concept[543211]*Government of Canada[99999]*Whitehouse[00000]
anandps
”

While that’s certainly a complete mouthful, none of this would be “user-facing” per se, and the advantages are:

- This format would be portable to any other project out there, and could potentially help Drupal set a workable standard for others.
- Commit messages are actually descriptive, versus having to read the long version to get any decent info out of it.
- Git notes is machine-parseable to build lists of what employers/customers are contributing the most, and who is employed/contracted by those organizations
- Committers could go back and change the git-notes portion *without* adjusting the commit message/commit hash.
- It’s still just a single copy/paste command.

- We want the organizations + customers in the drop-downs to be entities on their own right, rather than just CSV text. In addition to making the data cleaner and less error-prone, this allows us to do things like create a page that “back-links” a list of things that company has done, or to allow users to sort companies in the Marketplace by “Highest contributions” or do like a “Featured contributing company” block on the Drupal.org home page, etc.

- In theory then, places like the Marketplace and DrupalCon Sponsor list, etc. would just be additional flags on these nodes that only d.o admins can set so we don’t end up with “content type bloat” and duplicate organization nodes floating around.

- In general, Dries really feels strongly that this is a “game changer.” It allows us to actually get meaningful data on how our community’s ecosystem is structured, and how Drupal actually gets built. It’s also great because it allows Drupal “champions” within organizations to make a business case to their bosses that giving back to Drupal.org has a financial benefit (company name mentioned in issue queue, user clicks that to organization page, sees all kinds of awesome contributions there, clicks into company website to hire them/work for them, D.o referrers to foo.com goes up, win!)

So what that means implementation-wise is:

User profile changes:
================
- Current company or organization: Single select -> Multiselect - Autocompletes based on existing names, new names == a new node.
- Current customers (new field) - Same deal.

We don’t need to worry about past organizations/customers since there’s no way to go back and edit issue metadata on a comment. So we can probably leave those fields as CSV.

Content type changes:
=================
- TODO: Look into how existing organization nodes are implemented, maybe there’s little to change here.

- Since any old contributor will be able to add these nodes, we need a) a spam process and b) an organization “ownership claim” process (since “webchick” should not own the “Sony BMG” node as a contractor for them, for example).

- We should track some fields on the org nodes such as “size of organization” (# of employees), # of websites, industries they work in, where they’re located, etc. This would allow us to segment the data by “Highest contributing company of 5 employees or fewer” since it’s not really fair to compare them against a company with 100+ employees.

Issue queue changes:
=================
- Play around more with making it more obvious what this data is for, better separation between employer / customer / freelance / volunteer.

- Maybe a way to implement this is a button to “Provide credit” which gives “Funded” / “Unfunded” as options and pulls in the relevant fields depending on what was selected (via the #states system or whatever).

- Possibly incorporate what Mark Carver’s working on in the other issue to allow selecting an author so this can continue to be just a single copy/paste command.

VersionControl Git changes:
======================
- A field to store git notes content per commit; don’t think we need any changes to commit log views, etc. because this isn’t human-readable info.

Whew. :P I think that was everything. :P Please feel free to leave feedback, but with the caveat that I won’t be looking at this again until the first week of August at the earliest due to vacation. :)

Bojhan’s picture

When the details are figured out, I will help out on the design part

drumm’s picture

Issue tags: +D.o UX
webchick’s picture

Ok, back from vacation, made it through the 40,000 emails that came in while on vacation ;), now digging into this again.

Organization nodes

I dug a bit into organization nodes, and looks like we don't really need to change anything at all about them. They're currently just a standard content type (albeit with TONS of fields), any authenticated user has permissions to create them, and marketplace listing is an optional checkbox on the organization node form. Hooray!

And, in other good news, that field is already multivalue as well, thanks to #968994: Multiple Values for listings of current companies and organizations. In not-as-good news, it's only a text field, not a true entity reference field. This was a deliberate design decision taken by drumm in #968994-14: Multiple Values for listings of current companies and organizations:

I think the company/organization name should be a string, rather than entity reference to organization nodes. A string makes migration straightforward, and lets people keep entering whatever they want, without needing an organization page. An entity reference would be easier to work with for future development, such as creating Views using the relationship. We can convert it later if we need to; or even make a hidden computed reference field.

So, spun off an issue for that at #2323705: Add user's organization computed reference field.

Also spun off #2323709: Add a "Current customer(s)" field for the customer(s) field.

#2322257: Remove 'Company or organization size' profile field? removed the "Company size" field entirely; we want that to instead go on the organization node. Spun off: #2323713: Move "Company or Organization size" to organization nodes

Git Notes

There's already an issue for this at #1282040: Add support for reading git-notes. No work done yet, but some musing from sdboyer on the challenges.

Re-trying the issue queue mocks now...

webchick’s picture

webchick’s picture

Ok, here's my current thinking, based on talking to Dries a few weeks ago. Please note that I am NOT a designer, which will become readily apparent shortly. ;) The intent is to get ideas out and then hopefully get the help of someone like Bojhan to make it deployable. :)

Step 1: Issue queue node/comment form

There's a new section there called "Contribution type" with a radio selection (or maybe fancier looking buttons, whatever) of whether you're contributing as an individual or on behalf of an employer/customer (defaults to whatever was last chosen). Help text points you off to where to fill out those values.

Contribution type choice of Individual or Employer/Customer

If you choose "Employee/Customer" you get a modal dialog that prompts for more information (again, defaulting to whatever was last selected and with help text pointing off to the user/edit/X/Work page):

Modal dialog showing contents of Current organization / Customer fields.

(Blocker: #2323709: Add a "Current customer(s)" field)

After hitting OK, the values you selected will be visible next to the "Contribution type" section, kinda like Vertical tabs, so it's obvious to whom you're attributing credit:

Updated Contribution type showing an employer and two customers.

Step 2: Issue / comment view

For individual contributions, nothing changes in the comment display (ignore the subtle font differences):

Standard comment view

For employer/customer contributions, you'd get something like this instead:

commented on behalf of Acquia, Blah, Blee

(Blocker: #2323705: Add user's organization computed reference field)

Commit Message Generation

No real change since last time, I don't think:

Patch has a 'Git attribution' expandable section under it.

Note that #2295411: Auto-generate Git attribution info / commit messages on Drupal.org is covering highly related ground, but is getting pretty fancy.

Also note that #2323715: [policy, no patch] Determine format for commit credit for individuals/organizations/customers has been spun off to discuss the exact format we want to do here. In the interim though, commit messages formatted like this would work.

Bojhan’s picture

I am wondering, design-wise a side. Does it make sense to "comment" on behalf of an organisation? I can imagine that organisations would feel quite uneasy about such a feature.

The best way to promote contributions from an organisation stand point, would be to bring this "commit" information to the organisation profile. But also improving the way we list organisations by contribution.

jhodgdon’s picture

I agree with Bojhan that "commented on behalf of" is problematic.

Maybe we just need to change the wording to "Work supported by" or something like that? So it would say (maybe):

-- field:
Contribution support
() individual () Employer/Customer

(optional) Specify whether this contribution was done on your own volunteered time, or was supported by one of [link]your current organizations and/or customers[endlink].

-- comment header:
(user name) contribution supported by (org1) (org2) ... (date)

Thoughts?

webchick’s picture

Sure, I'm definitely not married to that text. I think the important thing is mainly to get the company name(s) in there somewhere.

webchick’s picture

And good point @Bojhan, I should also do a round of mocks on how this info would be reflected back on the organization pages, as well as a "leaderboard" type thing, but figured that's a later step, after we have the ability to even capture this info.

Mixologic’s picture

This will be awesome to be able to credit organizations and groups, and yet maintain the individual's contribution as well. Love it.

I would like to echo @xjm's concerns in #9 - I think we should avoid attaching more metadata about a change to the git commits that represent those changes. Even putting credit into the commit messages seems unusual to me like @webchick said in #15

we should probably remove the usernames from the commit messages themselves (which would eliminate a Drupalism as well).

It seems to me that coming up with a format to store credit in git is inventing another drupalism.

It may be true that other projects attach some kind of metadata to their git data, but those projects don't already have a great metadata repository that could handily manage all of that data (drupal.org in this case), so why not use drupal to store that data?

We already provide a pointer to all the metadata that is associated with a commit, the issue #. What if all of the credit related information was additional fields on an issue? It seems that project maintainers could update credit on an issue when they close an issue (or at any time), additionally if we decide there needs to be new *types* of credit granted (like reviewer credit or sponsorship credit) it'd be much easier to add that to the interface on d.o. These form elements would not be visible to most folks, only maintainers.

It feels like we're trying to use git as some sort of metadata database, and that we're looking at ways to serialize that data into git (https://www.drupal.org/node/2323715), and we'll need to get that data *out* of git to use it on the place where its useful (drupal.org) - so why not store it on d.o. in the first place?

webchick’s picture

I figured we would do both; store it in the DB in hook_comment/node_save() for our own integration with Views etc, and also write it out to Git for external tools to parse. But Josh sent on an email to Dries to find out how integral he feels the "get it in Git" part of this is. If it's not, that could potentially eliminate a nice chunk of work.

My only other question then is are we sure those commit records can reliably be used to refer back to in other tables? I thought one of the reasons we didn't allow an interface for re-assigning author in case of a screwed up commit, etc. was because the VCAPI tables were essentially a "cache" of what was in Git and could be rebuilt randomly. I guess sdboyer or marvil07 would know.

drumm’s picture

also write it out to Git for external tools to parse

External tools have a new option, what Drupal.org provides via RestWS. Since we'll almost certainly leverage fields for this, it will appear in the API without extra work. Either way, 3rd party tools are either implementing something new to read either our API, or something new to read our special Git data. The special Git data does have a chance to be adopted by other projects, but I expect not without someone motivated working within the Git community.

I thought one of the reasons we didn't allow an interface for re-assigning author in case of a screwed up commit, etc. was because the VCAPI tables were essentially a "cache" of what was in Git and could be rebuilt randomly. I guess sdboyer or marvil07 would know.

Changing Git's --author or commit message changes the commit hash, so that's set in stone as soon as your branch is pushed publicly.

VersionControl re-parsing does change some sequentially-assigned IDs, and is smart enough to update changed IDs in tables that refer to it. For example, the ID that a release node uses to point to the branch or tag is kept updated. We can do that again; or store the reference as a commit hash, which won't change.

Mixologic’s picture

The special Git data does have a chance to be adopted by other projects, but I expect not without someone motivated working within the Git community.

I think that would be possible if what we were trying to define had a widely accepted data model. But we haven't agreed as to how to define attribution, and whether and how to segment the nature of peoples contributions. Who to give credit to (individual/freelancer/employee, the sponsor/client, the employer, the client), and how to categorize the nature of their contributions (reviewers, patch writers, patch editors, issue opinionation, sponsorship, testing, administrative requirements gathering, mentoring) can be looked at in many ways, and organized in many ways.

I think that each project would have different enough crediting requirements that Im doubtful that we'd be able to come up with a model that suits other projects without first researching or consulting with them to find what they need. Ultimately we're trying to see who's responsible for helping create the delicious Drupal cake, so I would think that building something that works for other projects would be a bigger thing that we would want to take on.

webchick’s picture

Yep, that's all fair enough. We'll see if Dries concurs.

webchick’s picture

Spoke with Dries and he does feel strongly about the credit info being in Git. He wants it to be visible on both Drupal.org and e.g. Github. He also strongly advocated for credit being included in commit messages themselves, as is proposed on his blog. If we did that, it would avoid having to futz with git notes and that whole pile of potential pain in VCAPI, but it also exacerbates the issue with log messages being largely meaningless in lists like http://cgit.drupalcode.org/drupal/log/ (only maybe 20% of those do not have an ellipsis, and several of them are like this: "Issue #2271251 by ParisLiakos, undertext, JeroenT, StevenPatz, tim.plunkett: ..." with absolutely no real "message" at all). Nevertheless, it's a pretty easy fix that we could always improve on later.

I still maintain though that we should be able to do both include the credit info in commit messages, *and* add the metadata to d.o on hook_node/comment_save() (as opposed to pulling the data back out of git), so I don't think it's an either/or proposition.

Bojhan’s picture

@webchick Just wondering here - can we not do the "by" part at the end of the commit message. Then we can have the "meaningfull" part readable and just add an ellipses for the rest.

webchick’s picture

Hm, yeah that's a thought. I can't think of a reason we couldn't do that, really.

jhodgdon’s picture

+1 for #31. I was just going to say the same thing.

Gábor Hojtsy’s picture

There is not much mention of reviewer credit here but @Dries linked to here from https://twitter.com/dries/status/502805736020537344. Is this issue to cover introducing reviewer credit (eg. the necessary Dreditor changes, etc) or another issue should be opened?

fago’s picture

As discussed on twitter, our current process lacks giving credits to reviewers. However,

  • it actually takes more knowledge for being able to tell whether something is a good chance or not than writing it
  • doing proper reviews takes a lot of time, sometimes even more than writing it
  • the lack of any credits for reviews does not encourage people to review more code. That's in particular problematic as most people would probably consider writing patches being more fun anyway.
jhodgdon’s picture

RE #35 - When I make commits to Drupal Core for Documentation patches, I normally try to credit:
- person who wrote original issue pointing out the docs problem
- anyone who suggested wording
- anyone who reviewed
- people who actually created patch files

I do not know what the practice of other committers is, but... to me "credit" for a patch is shared and all of these types of people contributed to the patch. I do not use dreditor so I am not relying on it to make my commit messages... and I think there is a separate issue about patch credits anyway and we shouldn't be discussing it here... so I just contributed to the problem. :(

webchick’s picture

I do think reviewer credit is a separate issue, if there isn't one already. We can discuss that independently of giving organizations credit.

Mixologic’s picture

webchick’s picture

Any thing left to do to move forward here?

Bojhan’s picture

I think this needs an updated summary, then the Dev Tools team needs to figure out the UI and implementation.

webchick’s picture

Issue summary updated.

Bojhan’s picture

FileSize
143.14 KB
32.86 KB

I've done a few explorations. I think it makes most sense to hide this functionality behind a link. I assume most users won't be switching between company and individual all the time. Therefor we can show it behind a additional click. It also gives us more room to explain the choice they are making and possibly link to relevant sources.

The idea below is relatively minimal, but I expect some more discussion around this. The only thing I truly worry about is the inability to add customers here, perhaps we can provide linking or an actual add button. I think this is up to drumm to decide.

new comment type showing selector to change, using edit link

Modal dialog showing fields for contribution type

webchick’s picture

That's definitely a lot more compact, which I like. I guess the only issue is it's not real discoverable that "Organization" is another option, though perhaps that could be addressed with some help text?

Bojhan’s picture

@webchick That's true. Though I hope the label triggers the "concept" of individual/company time contribution. Perhaps we should pick a better label? People often don't read help text and the issue metadata part is already pretty filled with help text.

webchick’s picture

Definitely not married to the label. Would "Contribution source" be more evocative, maybe? Unfortunately I wasn't able to find any other sites that do this kind of thing so not really a precedent to copy/paste here.

drumm’s picture

Untagging since Bojhan is providing feedback.

I agree the "Contribution type" label isn't exactly right. Maybe something like:

Attribute contribution to myself [edit]

webchick’s picture

Ooooh, +1! :)

jhodgdon’s picture

+1 pm #46 also!

Bojhan’s picture

Oh, thats a great idea. Adding to that - I would go with "Bojhan Somers" and not "myself". From what I've seen in the countless usability tests I have done, is labels like "myself" "me" don't really perform well as people don't immediately recognise them.

Frankly this is quite ready for some technical input, I am sure we can figure out the details of the UI from here on.

drumm’s picture

Issue summary: View changes
drumm’s picture

Issue summary: View changes
drumm’s picture

Issue summary: View changes
Issue tags: +Needs issue summary update

Updating the issue summary with images from #42. It looks like the issue summary is missing more, such as the resolution to this from #22

I agree with Bojhan that "commented on behalf of" is problematic.

webchick’s picture

AFAIK there hasn't been a resolution to that yet. But since it's a simple text change, seems like that's not really a blocker.

mgifford’s picture

As I said at the time on Dries blog post, "The true value however will come with how we aggregate this data. If we do a good job of that and feature it prominently on d.o it will have a good impact on community engagement."

It's no small task to allow folks to give attribution in the git commit logs, or for that matter to give proper attribution on issue queue pages. However, we need to do more to highlight those organizations and individuals who are contributing. We need this data, so we can know how people are contributing, but it will only be a motivator for companies when aggregations of these contributions get featured in prominent locations on Drupal.org.

ianthomas_uk’s picture

I like "Attribute contribution to Joe Bloggs", but we need to get the agency and client in there too.

How about "Attribute contribution to {name} of {agency} for {client} [edit]"
(obviously "of" and "for" would disappear when not required).

mgifford’s picture

Issue tags: +driesnote, +maintain

This idea is mentioned in @dries Amsterdam keynote https://www.youtube.com/watch?v=4NN5EM4CYVE&feature=youtu.be&t=35m

marvil07’s picture

Legal question: if this end up in git logs, how copyright is affected? i.e. does organizations and customers also get copyright?
By default her in d.o all is GPLv2, so license is not the problem, but it would be great if someone can actually clarify this legal aspect before we decide to implement it.

holly.ross.drupal’s picture

Responding to #57 above, I am pretty certain that EVERYONE ends up as a copyright owner. This article does a great job explaining how copyright and licenses intersect:

http://www.majordojo.com/2010/07/license-vs-copyright.php

joshuami’s picture

drumm’s picture

If in my spare time, I help build a site for a friend's organization, are they my customer? I suppose they are. The word gets a bit awkward, but I can't think of an improvement like the "company → organization" change.

jhodgdon’s picture

If your friend's organization you are working for pro bono expects you to credit them, then they are your customer. In this case though I think I would personally not credit them, since they are not really sponsoring the work in any way... up to each individual though, right? I think "customer" works fine.

webchick’s picture

Issue summary: View changes

Updating issue summary with a bit more info on overall goals/rationale/approach.

drumm’s picture

Issue tags: +d.o issue workflow
jhodgdon’s picture

Given the issue title here, which is not specific about what "contribute to Drupal" means, I'm wondering if we would also want to give credit to people who do contribute their time by making Drupal.org documentation edits? Could we have a similar field people could fill in on a page revision? Just a thought that occurred to me. May be out of scope for this issue.

drumm’s picture

Title: [meta] Provide credit to organizations / customers who contribute to Drupal » [meta] Provide credit to organizations / customers who contribute to Drupal issues

Clarifying the title. This is very much focused on issues.

Thanks to #2416177: Use Comment fields instead of custom textarea. this is fitting nicely into nodechange's existing work on comments. Documentation pages will have to do something different, since they want to remove, not accumulate, comments. Maybe a regular field on the node with a bit of customization could cover it.

drumm’s picture

Status: Needs review » Postponed (maintainer needs more info)

The recent work on #2323715: [policy, no patch] Determine format for commit credit for individuals/organizations/customers clearly cements the organization/customer split.

Should both be multi-select? Either will of course be easier to make a more-striaghtforward UI if single select. It looks like all the mockups are multi-select, with the possible exception of #5.

Is everyone okay with customers being associated with users, #2323709: Add a "Current customer(s)" field?

David_Rothstein’s picture

This is a nice idea, but I think hardcoding "employer vs. customer" directly into the field structure would be a big mistake. @drumm's comment in #60 is one reason - this does not take into account the variety of ways people actually contribute. Here are some other problems:

  1. There is no way to indicate that a contribution was part-volunteer and part-sponsored-by-employer. Not sure about other people, but for me a significant amount of Drupal work I've done over the years falls into that category. I think it's especially common when you're working for a company that doesn't really have a strict boundary between work time and volunteer time :)
  2. There is no way to distinguish between (a) work done as a volunteer, and (b) paid work done under an NDA. Again this is pretty common (I've been in situations where 100% of my Drupal work was in one of those two categories). With the current mockups, although there is a way to distinguish between those on the editing screen, the hardcoded "employer/customer" split means it's not clear that would ever make it into the field storage in the database (and the current mockups for the comment view do not show it being distinguished there either). I think it's important that this distinction be stored somehow.
  3. It doesn't fully take into account that the same organization can be both a employer and a customer. (It's often the case that a large organization will hire some of its own Drupal developers while also farming out some work to agencies and contractors.) I suppose it's not impossible for that to work with the current proposal - nothing stops the "employer" and "customer" fields from both having the same organization as an option - but overall it seems like it would be an awkward process.... would the organization have to "register" as a customer and employer in order to be listed as an option in both fields, or...?

A better way to do this that solves the above problems while being a lot more flexible for the future would simply be to have a single multivalued "organization" field (or actually, more like a multivalued field collection, with each element containing an "organization" field and a "relationship" field). Examples below.

Standard situation with an agency hired to do work for a client:

I did this work for [Organization 1] as a [employee]
            and for [Organization 2] as a [client]

Mix of employer-sponsored and volunteer work:

I did this work for [Not specified] as a [volunteer]
            and for [Organization 1] as a [employee]

Contract work done under an NDA:

I did this work for [Not specified] as a [client]

etc.

And if you ever need to add a new kind of relationship later on (besides examples like "employee", "volunteer", "client", "contractor", etc) then it's as simple as adding a new option to the select list, rather than redoing the entire field structure and user interface.

David_Rothstein’s picture

Legal question: if this end up in git logs, how copyright is affected? i.e. does organizations and customers also get copyright?
....
Responding to #57 above, I am pretty certain that EVERYONE ends up as a copyright owner. This article does a great job explaining how copyright and licenses intersect:

http://www.majordojo.com/2010/07/license-vs-copyright.php

I read that article but don't see how it answers the question above. (Clearly the copyright on Drupal as a whole is shared between many many people, but the question was about the copyright on particular contributions and whether the organization owns some of that.)

I think it's a good question actually. My understand is that (in the U.S. at least) copyright belongs to the individual by default. An organization would only own or share in the copyright if you signed some contract with them saying that you're granting them the copyright. And I doubt that merely filling out a field in the user interface of Drupal.org that "attributes" your post to an organization would count as giving up copyright...

But I am definitely not a copyright lawyer, and I have even less of an idea how it works outside the U.S. :) So I think this is worth clarifying.

drumm’s picture

FileSize
79.14 KB

Mockup

I've been running with the assumption that multiple organizations and customers can be selected. Here is a mockup of a potential UI, that would go above the comment textarea. Depending on how the size works out, we might even be able to nestle it to the right of the HTML tag buttons on desktop sizes.

I don't think this belongs in issue metadata; for commenters, this is set per-comment. Future work on the Credit & Committing UI will let maintainers collapse this into per-issue credit as it is fixed.

My main goal was to lighten up the UI. Modals can be obtrusive. Replacing with a bubble provides enough screen real-estate for a little UI on each element, and keeps you in-context.

The attribution when viewing the comment should match, omitting some words:

drumm at Drupal Association for Acquia, Chapter 3 commented 12 days ago

drumm’s picture

#2323715-56: [policy, no patch] Determine format for commit credit for individuals/organizations/customers is probably the best recent explanation of the organization/customer split:

Study how the community works, by studying the relationships between customers, agencies, and volunteer contributions and how and where the money is flowing.

At this point, I think we should try it out and see if people do credit their customers. Whatever we end up with will simplify the relationships to fields somehow.

drumm’s picture

Status: Postponed (maintainer needs more info) » Active

#69 is now implemented at #2340363: Add issue comment attribution.

I never got an answer to #66:

Should both be multi-select? Either will of course be easier to make a more-striaghtforward UI if single select. It looks like all the mockups are multi-select, with the possible exception of #5.

Oh well, I'm running with multi-select for both.

Bojhan’s picture

I think at the moment it must be a multi select right? Assuming it can often be multiple.

drumm’s picture

Issue summary: View changes
drumm’s picture

Issue summary: View changes
joshuami’s picture

If you have not taken a look at the comment UI, you should at #2340363: Add issue comment attribution

Should we embed that demo gif in this issue summary? That is a very creative way to get feedback on UI functionality before completely coding the back end.

joshuami’s picture

@David_Rothstein, we have time to work out the specifics of how we write to the commit message, but this issue is focused on collecting organizational attribution for work on an issue. We are storing the intent on the comments in the issue and can store per issue credits at the time of closing an issue. Because each comment is attributed, you could change your settings on a per comment basis to go from doing work on your own as a volunteer to doing work for your company as an employee to doing work for a customer directly or through a company. It is flexible intentionally as many issues remain open for long enough for someone to transition several times.

You make a good point about work done under an NDA. You would not be able to disclose that work, so we would not see a customer accordingly. It would be interesting to hear from @webchick or @Dries. Do we want contributors to have the option to specify that work is being influenced by undisclosed organizations? It seems like that would create unintended tension and it would be better to simply not attribute a customer at all.

As for copyright, organizations getting attribution for enabling the work does not change the fundamentals of how copyright works for an opensource project. All contributors to the project have copyrights to their contributions. It is part of why a project with many contributors is virtually guaranteed to remain open source. This is a clear benefit to all the contributors. In this case the copyright would still be held by the individual rather than the organization that is being credited. (We do not allow organization accounts to contribute code per our terms of service.)

David_Rothstein’s picture

Thanks for the feedback, @joshuami.

My points in #67 were only referring to the comment attribution, not commit messages. Even if you can do different attributions for different comments, writing and uploading a patch just takes one comment but often involves a lot of work that may be split between volunteer and employer time. That's the problem.

That concern (#67.1) was definitely my main one, though it does occur to me that it could be partially addressed just with some wording changes => When you click "Drupal Association" in the example, perhaps the text should be "Attribute this contribution to myself, Drupal Association" rather than just "Attribute this comment to Drupal Association". I'll leave a note about that in the implementation issue.

That would make things better, but it still leaves out so much useful data. If you want to be able to answer questions like "what percentage of Drupal contributions are volunteer vs. paid" or any other similar questions, storing things like in #67 makes that possible but otherwise the data simply isn't there. I'd certainly love to be able to see the answers to those kinds of questions. What do others think?

drumm’s picture

Issue summary: View changes
drumm’s picture

Documentation to update as parts of this are rolled out: https://www.drupal.org/node/2451283

joshuami’s picture

@drumm, excellent work. On a thread this long, it does not stand out too much.

webchick’s picture

For those who missed the memo, #2340363: Add issue comment attribution just got deployed. :) Yeah!!

drumm’s picture

Novitsh’s picture

#2506223: Commits percentage per Author & Author organisation members vs community members Talks more in dept about the statistics and a way of displaying for/to businesses.

tvn’s picture

Category: Feature request » Plan
Issue tags: -D.o UX, -driesnote, -maintain
YesCT’s picture

mlncn’s picture

It seems credit given in the beleaguered Project Application review queue is not being included on profiles or anywhere else, so i've opened #2810485: Allow more maintainers to grant credit to address that.

drumm’s picture

Status: Active » Fixed

Looks like the most important parts of this are done. The remaining child issues are nice to have improvements.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.