With the help of a few key community members, we have been hard at work creating an interface for users to attribute their work in the issue queues to a customer or employer. (#2288727: [meta] Provide credit to organizations / customers who contribute to Drupal issues)
This is an important step in beginning to collect information about the contributions that organizations make in the Drupal ecosystem. Dries has talked about this need in detail in his blog post A method for giving credit to organizations that contribute code to Open Source. Since the original vision laid out in that post, which focused on commit credits, we have expanded the scope to include any contribution in the issue queues.
There will be three parts to the release of this feature on Drupal.org.
Comment Attribution
First, we needed a way that contributors could attribute their work to an organization—either their employer, their customer or both. (#2340363: Add issue comment attribution) We would like to have feedback through the comment on the issue. Here is an animated example of the comment attribution user interface:
This new field on every issue comment lets the user attribute their work to organizations per comment. Our team is also very excited to introduce a new interface framework for inline editing of entity fields on Drupal.org. There are so many great ways we could use this for easier in place editing of metadata.
Once this comment attribution user interface is deployed, we’ll see how it is used, helping us build the next step.
Interface for Maintainers to Award Issue Credits
The next step will be a method for maintainers to award credit for the intended attribution. (#2369159: Extend crediting UI to include organizations & customers) Allowing maintainers to commit or award the credit for the issue accomplishes two important goals: we incentivise completion and we reduce gaming of the credit system.
By placing credits on issues—rather than commit mentions—we opened up the ability to recognize contributions outside of code. Patch reviews, comments on architectural decisions, wireframes and mockups, and general design feedback are all valuable contributions to the issue queues. Maintainers will now be able to reward those helpful behaviors.
Highlighting Organizations that Contribute
After a couple of months of collecting issue credit data, we will be able to begin using that data to highlight contributing organizations—giving them “trust currency” as Dries put it so well.
Issue credits are not the only contribution we will be tracking. We are already tracking how organizations give back financially through our supporting partner and membership programs. We track organizations that sponsor DrupalCons—and we’d like to start tracking how organizations help build camps.
Next Steps
If feedback goes well, our Drupal.org engineering team is planning to release the comment attribution feature on March 12th.
The user interface for maintainers to award credit should be available for comment in the coming week. Work on that issue has already started at #2369159: Extend crediting UI to include organizations & customers.
Let us know what you think!
Comments
All 3?
Is the intent for a comment to get credited to the individual, organization, *and* client, or just the latter two? I understood the intent from Amsterdam to be all 3, but the gif (LOL!) seems to suggest just the latter 2.
--
Larry Garfield
http://www.garfieldtech.com/
Thinking Functionally in PHP: https://leanpub.com/thinking-functionally-in-php
It is credit for all three.
It is credit for all three. The individual we pull from the comment itself. Work in #2369159: Extend crediting UI to include organizations & customers will show how maintainers can award the final credit to all three layers of the contribution.
And we've added the user name
And we've added the user name to the copy at #2340363: Add issue comment attribution to make this more clear.
I like it a lot. that's a lot
I like it a lot. that's a lot slicker than I was thinking.
I only have two comments:
I understand that some of that may not be possible in this iteration, I just figured I'd point out what people are going to be asking for. It might help to have some help text explaining that you can only choose a single organization and customer (unless you think that is implied).
What would sub-contractors do
Regardless of contracts, I recommend talking with your employers and/or clients before attributing them. We don't need or want the whole hierarchy for Drupal.org, simplifying it down to attributing who wants to be attributed is good.
Both organization and customer can have multiple selections.
Autocomplete?
The video shows an autocomplete field. https://www.drupal.org/node/2369159 says "entity reference". Who will be able to create organization and customer entities?
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
For organizations, if you
For organizations, if you have an organization linked from your user profile page, you are all set. #2442973: On the user profile edit for "work" show if an org has an org node or not is open to improve that UI.
For customers, any customer with an organization page will work. (Organizations do not need to be listed in the Marketplace section to have a page.)
gr8 ideas
so many of my patches for contrib modules were never credited when committed :(
when crediting a client/employer consider the statistical skew introduced by the ones that prefer to remain anonymous
not everybody "gets" Open Source and some are hesitant to make their involvement public, for many reasons
that has been my personal experience, anyway
"sponsors" by definition are on board, I think
~are you netsperienced?
♥ follow me @decibelplaces ∞
Is this going to encourage "advertising spam"?
Think it's a great idea... just worried that it might lead to a lot more short "me too" posts that are really designed to get a company's name into more search results.
Is there a plan for reporting abuse / inappropriate use and all the potential "arbitration" needs that go along with that?
--
A vast majority of stuff done in Drupal is easy...
it's finding the trick that makes it easy that takes Sooo much time.
If there are any links, they
If there are any links, they will go to organization pages on Drupal.org. Incentives are quite low. Any credit we advertise elsewhere on Drupal.org will be filtered and granted by the project maintainers as issues are fixed.
I think the usual community policing of non-valuable comments will keep this in line, they would be negative advertisements for companies if people notice them. There is this old issue, #1308176: [meta] Battle plan for stopping spam/"subscribe"/"+1"/"thank you" comments (and cleaning up old ones from the db too)..
Could attribution be limited by post characteristics?
Just wondering if a quick way to credit people how are actually "giving back" could be filtered by some sort of simple criteria:
E.g. only listed if comment/change is >X characters or paragraphs long with other conditions like issue state change or patch file submitted?
Use cases:
Allowed: Someone tests module, posts Here's a patch to fix this, adds a patch file, and changes state to Needs to be reviewed.
Disallowed: Someone just say: "The patch worked for me".
Allowed: Someone writes a 2 paragraph report on what they did to test and why it works for them.
Disallowed: Someone edit's a help doc and corrects a few spellings.
Allowed: Someone makes a dozen changes to the document.
All of these could be validated on submission and quantified a bit.
--
A vast majority of stuff done in Drupal is easy...
it's finding the trick that makes it easy that takes Sooo much time.
Logic might do an okay job of
Logic might do an okay job of figuring out comment quality, but I don't think it will be great, at least not for a few years. There is this idea kicking around too: https://groups.drupal.org/node/225824
Maybe only allow users with a certain activity level to do this?
The comment below by vinoth.3v made me think of an alternate way to make sure this isn't being abused.
Limit the ability to do this to people who have enough "karma". A lot of support sites do this by having user "ranks" based on number of correct answers and/or other items.
One such system I like is the "Thanks" method. E.g., you're a novice user until you get enough "thanks" for your answers. As you answer more questions or help solve issues with good information, you get more thanks and your "karma" (and rank/reputation) goes up.
The voting or badge system might also be used for this. E.g., you have to have one or more badges to do this.
IMHO, doing something like this would make it a "reward" for people to use any new "karma" generating things like voting, badges and the like. Basically, people do things because it helps them.. feel nice, in their work, and the like. Having extra privileges granted for helping more plays into this.
--
A vast majority of stuff done in Drupal is easy...
it's finding the trick that makes it easy that takes Sooo much time.
Just two thoughts!
Just two thoughts!
Credit can be given
1. if only a user from that campany (user to campany relationship in d.o) who is NOT one of the module maintainer submitted patch to that issue that accepted and committed to the project by module maintainer. by this way, we ensure that he company actually has a Drupaler. (money is not everything!)
2. If a company donates payments to maintainers to fix a famous #issue (more followers or it breaks enough drupal stacks (may be by a flag like 'I also has this issue' link)) .
Vinoth - வினோத்
Comments voting?
Sorry for being negative, but why voting for comments is not implemented before this? What is the point of attribution if it does not have a community value (votes)?
Founder, Software Engineer | www.drevops.com
See #42232: Help Maintainers
See #42232: Help Maintainers Manage Issue Priority by Encouraging Voting for any future progress on this.
Thanks Drumm. Much
Thanks Drumm. Much appreciated
Founder, Software Engineer | www.drevops.com
How on earth is this moving
How on earth is this moving forward before even atributted commits in core show in the user profile for non core contributors? And I've never understood the reason for that because it is working in contributed modules. I'd love to hear the technical reasons, if any, that prevent it from happening.
This work goes toward that,
This work goes toward that, see #2288727: [meta] Provide credit to organizations / customers who contribute to Drupal issues. We're a couple issues away from getting this data on user profiles, and are one issue closer.
The primary reason the current system works for contrib, but not core, is that it uses Git's one commit has one author model. So many issues for core deserve credit for multiple people, that
--authoris not used at all.Looks like a nice tool.
Looks like a nice tool.
One question I have is about defaults. It could get tedious (and therefore underused) if there aren't defaults.
Especially if there are defaults, think it would make sense to expose the individual who authored the code. 99% of the time this is the person who is authoring the comment but:
1. exposing it will make it more obvious that yes, you as the comment author will get credit
2. helps in that 1% of situations where someone is posting a patch on behalf of someone else (e.g. moving it from s.d.o to d.o, moving it from a private fork to a public patch)
--
Morris Animal Foundation
If you have commented on an
We haven't been thinking about the edge case of different authorship, this is adding organizations in addition to the individual credits.
I think it could be a good idea for some community teams and working groups to set up organization pages, and use this to speak officially. As with any organization, those teams should have a chat about what that might mean before doing it.
Default attribution behaviour is bad
> If you have commented on an issue before, it defaults to what you used in that comment.
This means that if you are following up on an old issue in which you had previously commented, and at the time of that prior comment you had no attribution configured, then the attribution is then left empty for the new comment. Or if you have changed jobs since then, the attribution is going to be incorrect.
This in turn affects the second bullet point, when posting in new issues:
> Otherwise, it defaults to what you used in your last comment on any issue.
So you can have a working default attribution that you don't need to worry about most of the time (and therefore get used to not looking at); but as soon as you make a new comment in an old thread your default gets reverted (maybe removed, maybe set to something out of date), and suddenly in new issues you are posting with that incorrect attribution, unless you manage to spot what has happened.
This is a pretty bad experience.
I realise that the current behaviour will be appropriate for some users who have more complicated working situations, but I think a very large number of users will, at any given time, be working for a single specific organisation to which they would prefer to attribute all of their comments, regardless of their prior history in any given issue; and for those users the default behaviour is kinda terrible.
That is certainly my situation, and I regularly find that I have been inadvertently been making posts with no attribution, which is really very frustrating.
It would be so much nicer to have the option of setting a default attribution in my profile, and have that be used by default whenever I'm posting a comment.
Good Idea, But,
Good Idea, But,
Also please take steps to prevent false/fake attribution. Some people might use this feature, to create new issues of their project and give credits to their own firm. So it is good Idea to allow this feature only to specific projects/developers filtered by some criteria. for example, credits attribution allowed only to drupal core issues etc something like that.
Vinoth - வினோத்
My suggestion is to hide this
My suggestion is to hide this well. Make attribution collapsible and collapsed, and don't show it prominently on user/organization page. Personally I don't want to be bothered with this, and I would like to pick my organization and client once, and for this decision to be permanent until change.
Yes
We are definitely working to limit the visual impact of the new credits in the comment thread. Too much visual noise is a bad thing.
Yes, the credit UI will remember defaults from the last time you used it.
I like this a lot. One
I like this a lot. One question: Will it be possible to edit comment credits? This would also include giving credits for comments created before introducing this whole system. On the gif I do not see a possibility for this unless the current 'edit' link would make this also possible.
Editing comments and credits
You can always edit a comment you have made, but right now the plan is to remove the ability to edit a credit after the issue credits have been given by the maintainer. That will hopefully reduce conflict and fluctuations in past credits.
Autocomplete
What happens when I type "Advomatic" in the customer autocomplete field and press enter, rather than selecting a suggestion?
What should happen is obvious, but please test this.
Customer field is an entity reference field
If you press enter without selecting a selection or putting the node ID in parenthesis after the full correctly spelled title, it will not work.
There are issues to address this in the entity reference issue queue, but it is a complex challenge. We may extend how we use this field in some follow up work, but for now, this works as it was designed.
#2375957: Autocomplete widget
#2375957: Autocomplete widget allows manual entry, but it fails and can corrupt data looks like the relevant issue.
Will this allow retroactive
Will this allow retroactive attribution? For comments and patches, etc we've made in the past?
Retroactive attribution
We are looking into this. The difficulty will be retroactive attribution on closed issues. Maintainers are giving the issue credit—and they may be reluctant to go in to review and reward credit retroactively.