Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch from "Top companies all time" to "Top companies last 30 days"? #53

Open
webchick opened this issue Feb 24, 2014 · 6 comments
Open

Comments

@webchick
Copy link

The new page at http://ericduran.github.io/drupalcores/companies.html is super awesome. However, when I tweeted about it there was some criticism about the validity of the data (which, granted, is also spelled out at the top of the table). Namely, that due to a lack of historical tracking of contributors' employers on d.o (there's an issue for that at https://drupal.org/node/1968480), when a contributor from company A switches to company B, all of a sudden company B gets credited with not only all of the contributor's current contributions, but also all other contributions they've ever made on Drupal.org! This causes e.g. ZivTech to be way down proportionately from where they should be, and in a way encourages businesses not to let their employees have D8 time, because they'll end up juicing up the competition's contributions if their employee ever leaves. :\

Given that, it might be better to replace the "ranked" company list with a time-limited one instead, say, "Top companies whose employees contributed in the past 30 days." And make the list of all 732 companies who contributed to D8 just a list (maybe randomized order, for fairness) with no specific metrics behind it, apart from maybe # of contributors overall which hopefully only goes up.

@catch56
Copy link

catch56 commented Feb 25, 2014

There's two metrics here:

  1. Which companies are historically prolific contributors working for.
  2. Which companies employ contributors who were profilic in the past 30 days.

Both of those are valid metrics, in both cases the contributions aren't necessarily down to the company at all.

@greggles
Copy link

I agree this is a problem that would be great to solve. Another solution that keeps more history would be to parse and store the organization data along with commits so that it can evolve over time.

@davereid
Copy link

Also just because I work for a company does not necessarily mean my core work is associated either. Yes, stuff I do during the day should be credited, and I do a lot of that. But wouldn't I be working on core and contrib late at night when I'm not "on the clock" regardless of who I'm working for?

@timplunkett
Copy link
Collaborator

I don't see how it is possible to fix both problems:

  • Commits were worked on "off the clock", and shouldn't be attributed to an employer
  • Commits were worked on for a previous employer
    Keep historical tracking of users' employers would help with the first point, but unless we all agree to start explicitly tracking which issues we work on at what time of day, I don't know how to address the second problem.

Stanford has supported me here and there, but less than 1% of my commits should count toward them. Yet they are prominently listed 3rd. My best guess would be 20% of my commits were sponsored by Zivtech, which would bump them from 77th to top 20, even higher if every other contributors numbers were adjusted similarly.

However, I did enjoy looking through this list when it was posted, because it was interesting to find out some people were coworkers that I didn't know about. I like the idea of listing companies by the number of contributors they employ, but it being a part of the D8 contributors list makes it seem more important that it is.

@greggles
Copy link

Yeah, we have to take these things with a grain of salt. There's also the major point that commits are not 100% correlated to value created nor effort spent. So, we can just try to get as accurate as possible (showing the most recent 30 days or calculating the values over time would both get us more accurate than we are now) and call that good enough at some point.

@chx
Copy link
Contributor

chx commented Mar 6, 2014

It also affects MongoDB which have sponsored my D8 work for close to two years now.

miteshmap pushed a commit to miteshmap/drupalcores that referenced this issue Sep 29, 2016
…reverts

Improve targeting of reverted commits
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants