Improve contribution statistics on user and organization profiles

Thanks for making this meta issue. Is very helpful overview.

Some of these have issues linked from the parent profile meta I think.

"Issues followed" I'm guessing that would really be "Issues following" ? Or do you really mean Issues followed and unfollowed would still count as issues followed?

I think it's a great list. I am especially interested in these:
- Patches submitted (core/contrib) - Undecided, I am leaning towards the idea but it is easy to see this bloat.
- Camp sponsorship - Great!
- Camp organizer - Great!

One thing that'd be really cool to see not only tracked but given a big boost in the marketplace scoring for the next ~6-9 months to encourage activity is "port contrib projects to D8."

If we had that deal where we could manually add people who have not commented on an issue to the issue credit, it would be easy-peasy. Just a straight bump in issue credit amount for any contrib_tracker issue marked fixed.

In lieu of that, maybe a boost for commits made to an 8.x branch of a module/theme/distro.

This is great news! :-)

I collected a list of contribution activities as part of the first stage of my PhD research from several data sources: documentary analysis from Drupal Planet (http://www.davidrozas.com/lab/drupal_planet_archive.php), semi-structured qualitative interviews and full field notes from participant-observation. You can find the list in the working paper here: http://cress.soc.surrey.ac.uk/web/sites/default/files/publications/worki... Of course, the scope/aim was quite different.

I have been going through the list and I think everything is mostly included, but I thought this might be helpful!

Regarding issue patches, there could have been priority.

For example, those who port an entire module to drupal 8 and those who fix a single typo gets the same credit since it is a single issue. If we can rate the level of contribution, it would be great.

Also, +1 on localization submissions. My contribution to most free software projects I have contributed is localization. In my local language, I am the one who contributed most to Drupal. There should be way to highlight that in an individual as well as organization level.

A point system does make more sense. For example,

* A translation submission can be one point.
* A trivial issue can be 10 points.
* Porting of module, say 200 points.
* Drupal core can be given more weightage.

Like that. Just a suggestion

Thanks @joshuami! Let me know if I can give any other help (I couldn't think of anything else at least for the moment ;-)

This is an awesome initiative @joshuami. @drozas, great work - enjoyed your observations!

Listed out more contributions that are non code-centric/object-oriented, but more community-oriented:

1. Being a Project Manager
2. Being an Initiative Lead
3. Camp/Sprint Organizers
4. Drupal Courses in Colleges - as a Community Activity

Would be a great value to rope in more of such contributions. An option could be to have a Contributions project where users can post their contributions that don't fall under categories defined, then have those validated by other Contributors to actually acquire the credit.

Recommend Contributions stats to have 2 scores
- one a recent score that indicates participation around last year
- second an overall participation score
This will ensure continuous participation.

Stimulate participation of Users and Company with a mailer system that alerts them. Some examples could be:
- Congratulating participation - informing where they stands
- Knock on them when they haven't been around with information around activities that would of interest
- Let them know what other's in their organization, region are doing
We can be creative with the scenarios, make the Frequency and content non intrusive.

There's a huge amount of contribution that goes on in local communities that doesn't touch d.o.

Groups that use meetup.com and not GDO
and DrupalCamps around the world.

People involved in organising those camps the DA supports directly should be easy to credit in some way.

But then there's a challenge for the others.

Acknowledging events logged on G.D.O might help here?

EG - all the D8 launch parties needed to register on G.D.O to get included on the map... perhaps there's something there.

@kattekrab: That's a fair assumption. We are careful in cross-posting any event (meetup, sprint, camp) to g.d.o at least and then point to whichever page where we are collecting signups (usually meetup, but sometimes our own website for camps). Earlier, there was no incentive other than hoping that someone who is not yet on meetup would notice and signup. The recent promotions on map were further incentives and I think most places would now be used to cross-posting.

Now, if we actually credit events organized on g.d.o, there would be a further push to cross-post. I don't think there is any resistance on using g.d.o for this.

Yeah, more rep for organizing events would be nice. Camp/meetup/sprint organizers and volunteers. Also, hosts. We are giving credit to companies that support dev time now. How about those that provide their space for events? That is a big help facilitating sprints and meetups.

We do have group moderators for the regional groups on gdo, so maybe it is up to them to control who is added as part of an official organizing committee for an event? That isn't as tightly controlled, but no less so than someone in contrib giving extra points to their friends in commit credits.

This article by Jimmy Tidey, discussing this issue happening on makers communities as well, might be helpful to reflect collectively on this: http://jimmytidey.co.uk/blog/affective-labour-and-digital-collaboration/

I have found this paragraph on "how to keep the balance" especially relevant:

Perhaps collaborative websites should start measuring affective labour and making it more visible. How many meetups did someone organise, how much mentoring have they done? How often do they resolve a dispute? Could that be presented in the same way that github uses stars? For example, the Drupal community has started to discuss and analyse the ways in which these less visible activities can be tracked and recognised. At the same time, efforts to value affective labour needs to avoid being reductionist – ultimately it’s not about measurement, but the experience of the community members.

Hope this can be useful!

I can't find a doc page and way to report issues with statistics calculation.
Would be great to allow users report problems so calculations will get feedback

@joshuami - I just want to clarify something around contributing to camps.

You said

Tracking contribution at camps could be done through issue credit attribution—assuming issues were associated with the work being done at the camp.

But what I meant, was tracking the contribution around ORGANISING camps, not the commits, reviews, comments, etc made on D.O during camps.

Organisers, volunteers, speakers, mentors... this is contribution too - but we currently don't have any visibility into that. And the data simply doesn't exist on D.O.

Having some kind of form on D.O for camp organisers to report back, perhaps with a user reference field (like we do for mentors) to list team members and volunteers... and some other camp metrics around attendance, sponsors, etc? Perhaps using G.D.O's events? Or at least something to brainstorm about.

Note: We SHOULD be able to recognise SPEAKERS at DrupalCons though. Right?

Thanks @joshuami - that's useful!

And apologies, I didn't go back and review the original list.

Agreed, tracking contributions around organizing camps would be terrific. For example, I have a core group of people that meet at least once a month and put a ton of time into making the Drupalcamp Colorado event professional and excellent.

We need to move forward.

At least we need to define priority and move forward by applying/updating one by one 'Contribution Type' into the algorithm for CREDIT system.

Is there anything I can do to help make these changes a reality? I'm happy to organise surveys & interviews with people if that's useful, also writing blog posts to help spread the word. Happy to help!

I'm happy to assist in creating child issues to help break this large task into manageable pieces if anyone thinks that would be useful

Adding the suggestion to track releases created from @colan, per feedback on our recent blog post.

Came to this via Hestenet's blog – last night I was watching the DrupalCon LA 2015 talk How do we encourage repeat contributions to Drupal Core?. Some there, such as YesCT, were saying a major bottleneck was the wait for patches to be reviewed (RTBC) and that a successful metric for sprints should not only be how many patches were created but how many issues reviewed/triaged/moved along - the current core Needs Review queue suggests it's still a major concern.

It doesn't seem to me (albeit as a newcomer) there's much problem with enthusiasm for contributing to core, or getting people to open issues, report bugs, have a go at writing a patch etc., the delay is at the other end because reviewing is (imho) REALLY hard, especially if you're trying to assimilate an unfamiliar issue which has spanned several years. Very satisfying from what little I've been trying of it, from a problem solving perspective, but hard and tiring all the same. Also, many probably don't even know just how small the group of core committers is? Is there a policy of mentioning the bottlenecks / human side of this at sprints?

Anyway, I'd argue RTBC maybe deserves it's own row in the table (bit surprised no-one's specifically mentioned it here or in the blog comments.)

@wturrell: interesting perspective, thanks a lot for posting that here :)

Currently, reviewers are treated exactly the same as those who roll the patch. They both get commit & issue credit. It may make sense to split up those two (writing vs reviewing code).

But I don't think it makes sense to call out RTBC specifically. In the vast majority of Drupal core issues that I've worked on, multiple people are reviewing, and it's just that when all feedback has been addressed and there is consensus among everyone that that last patch is the right one, then it's marked RTBC. So, RTBC'ing is not a solitary thing, it's a collaborative thing.

Maybe that can be a checkbox in the "Crediting $ committing" section of the issue, to identify those that contributed to reviewing,

Drupal Answers has well quantified data - presumably the overall reputation score would be the simplest thing to use.

The API terms of use say that visible attribution is required, and this could be easy to display on a user profile. Adding a link to these terms in the issue summary table.

It's not quite in the list... Could we add:

Organizing events listed on groups.drupal.org

The event content type on g.d.o has fields for organizer and event type, so this should be easy to count.

If g.d.o also had a Sponsors field, then we could also count sponsors of such events, although unless/until g.d.o is incorporated into d.o, the sponsor companies are not listed on g.d.o so that might be difficult. Still, it would be a useful thing to want to count.

I didn't edit the issue summary (not sure what the protocol is here...)

I think this issue summary is pretty done and dusted... if you want to create new community initiatives, you can follow the normal process for that at https://www.drupal.org/core/community-initiatives. As various ideas get to the "Approved" stage, I can add them to https://www.drupal.org/core/roadmap.

Although, stuff for d.o probably doesn't belong in the core roadmap, and I'm not sure these days what's the best way to interact with them... https://www.drupal.org/drupalorg/roadmap only goes through Q2.

Drupal.org should alert submitters when someone else has already submitted the same proposed patch to an issue and alert the maintainer should the second submitter continue with their submission. Not sure how this would be done since a simple MD5 hash would fail due to git including unique commit refs in the patch itself.

But Drupal should help sort out when others get credit for patches already submitted by someone else. I've seen it happen more than once, and since tracking contributions has become a big deal and since a certain amount of profile credibility with clients is tied to how much one contributes, this would be a netiquette improvement.

#43: I've never seen that happen TBH. And as you indicate, it's trivial to make a new patch that is slightly different. Comparing and analyzing contents OTOH is very hard.

I'm not sure what d.o's policy is around abuse in this way.

I think this falls back on the maintainers, maintainers in the end grant credit, not drupalorg. If a user is uploading a patch to issues that is a clone or a very similar patch, it is worth a discussion with them and if needed escalate to Drupalorg webmasters.

Issue credit for core is defined here: https://www.drupal.org/core/maintainers/issue-credit

I don't think it happens due to abuse. It happens when a user opens a duplicate issue, the solution is bound to only have a few possible solutions, and the maintainer is overwhelmed (common):
https://www.drupal.org/project/course/issues/2826426

It would be great to help sort out and prevent duplicate threads from expanding, give credit where credit is due, and relieve some maintainer work, but, again, I don't know how you'd do it.

@mlhess, I get what you're saying, but in most cases, I don't think it rises to the point of appealing to Drupalorg webmasters to credit the commit. And if there were an automated way to prevent it or give the maintainer more information to prevent them from giving credit out of turn, then it would save everyone the headache.

I don't think it happens due to abuse. It happens when a user opens a duplicate issue, the solution is bound to only have a few possible solutions, and the maintainer is overwhelmed (common):

Oh, I understood your first comment as someone posting a new patch on the same issue. That would in theory be possible.

This clarification means that it's is across issues. That would be super hard to get right without having the file upload take several minutes. Even just loading all patches for a big project (not just core, but also panels, search api, ds, ...) would take a ton of time. Even without doing actual computing on the file contents.

Oh, I understood your first comment as someone posting a new patch on the same issue.

That's also what I understood.

It happens when a user opens a duplicate issue, the solution is bound to only have a few possible solutions, and the maintainer is overwhelmed (common):

I've never seen this happen! 😯

The problem here is that the creator of https://www.drupal.org/project/course/issues/2860902 didn't search the issue queue properly first. Your issue was far better titled, so there's really no excuse.

It's also up to the maintainer to mark issues as duplicate, give better titles, etc.

re: 2826426 - I think the blame actually goes around for myself, the maintainer, and the duplicate issue creator since we all made subtle mistakes in its handling. I'm pretty sure it's happened to me before but don't have the reference right now. I just figured it might be happening to others and if there *were* a way to identify an identical patch (which I easily see the difficulty in doing), it would nip such incidents in the bud automatically. But maybe I'm just a fluke and this is a non-issue.

Anyway, thought I'd throw it in here if someone had an idea. Thanks for listening, at least.

It'd be lovely to have a "maintainerbot" that makes these correlations on behalf of us, but alas, that's easier said than done 😅

I think it's great that we question our ways from time to time though!

I wasn't aware of Issue credit for core as defined here: https://www.drupal.org/core/maintainers/issue-credit #2649100-45: Improve contribution statistics on user and organization profiles and not even of xjm @ d98readiness @ Slack (https://drupal.slack.com/archives/CDDD98AMN/p1590496909302900?thread_ts=...)

... Basically we spoke to numerous people at Mumbai who were concerned about the "disappearing credits" since in India the profile credits are a big factor in hiring. It's like if entries disappeared off your CV/résumé after a year. ...

As a contrib maintainer this credit hunt sucks the life out of me.

Now I can use https://www.drupal.org/core/maintainers/issue-credit for motivation to not provide credits.

It would be great to have that document available into the issues workflow.

@clemens.tolboom - Please note that contribution credits do not disappear from individuals. The one year limit is only for the primary display of issue credits, but the 'View all issue credits' link will always display all the credits from even older than 1 year.

As a contrib maintainer this credit hunt sucks the life out of me.

@hestenet I wasn't concerned loosing credits :-) {edit]All those so called 'Mumbai' patches do[/edit]

Oh! I understand you now. That makes sense.

https://drupalsouth.org is an annual event happening in AU/NZ (separate to the various, smaller local Drupal camps/meetups happening regularly multiple times throughout the year). I see that the profiles have checkboxes for all US and EU DrupalCons, but not this event. Can we please have them added? (past ones as well) ...the implementation for this is already in place - we just need to add more checkboxes/options to the existing field, so shouldn't require too much effort I imagine.

Noting that the site I have linked above is home for the DrupalSouth events, but also DrupalGov, which is an event dedicated to the Australian and New Zealand government sector (also annual, minus the COVID years that threw event planning/organizing off worldwide).

I'm not 100% sure if there are other similar annual events being organized in South America, Africa, India and other Asian countries. If there are, then those should also be listed.

PS: once these are added, can we please get an announcement in the monthly newsletter, to let people know that they can update their user profiles? Thanks

PPS: @hestenet not sure which other issue you meant to cross-link back in #2649100-29: Improve contribution statistics on user and organization profiles, but you have accidentally linked #2705733: Update organization content type to better reflect types of organizations in Drupal ecosystem twice.

Anyway, removing the duplicate entry.