Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.(Note: Ideally this would NOT be a Drupal.org customization, but we would leverage some generic way to do this, but I'm not aware of any just now.)
Coming from #1966218: Infrastructure to support organization accounts and paraphrasing from the issue summary:
When a contributor leaves Company A for Company B, and thus switches their "Current company or organization" field to a different value, suddenly all of their contributions for the past N years get associated with Company B. So while it's certainly technically possible to create something like a "leaderboard" of companies who give back a lot to Drupal in the form of code, documentation, code review, etc. to help motivate them to to do so, it's terribly inaccurate for providing any kind of historical timeline.
We should somehow augment Profile module's data about current employer with a way to track changes to it historically.
Ideas:
- Some kind of table with company, start date, end date that's populated on hook_user_save() upon that field changing (unless there's another contrib module that does this already).
- Expose start/end dates to users (kind of like the employment and school fields on a linkedin profile) since although a reasonable default, most of the time the actual dates are going to be different than when you finally remember to update your d.o profile.
Comments
Comment #1
dwwI suggested the exposed start/end date thing (the 2nd choice in the summary here is pasted from my comment) so +1 to that. ;)
I don't know of any existing contrib that does this. A little over a year ago, merlinofchaos and I were working on a project together that needed this, didn't find anything then, and we basically clicked it together with a multi-valued field_collection attached to each user. The field collection entities had start date, end date, and a few fields for the employer (name, I think even address, etc). The user could leave it blank, or create 1 or more employment "records" in this field. Seemed to work pretty well for what they needed. We didn't go on and build fancy stuff to process this data, so I'm not sure this is going to work well for us (especially at the scale of d.o) but a) I don't really see why not and b) we didn't have to write any code for this (other than fixing some bugs in field_collection at the time). We had a nearly identical field collection for education history, too.
I'm not set on that particular approach, but I wanted to share it for consideration. d.o is already going to be using field_collection in D7, so it wouldn't even be a new module to deploy.
Comment #2
webchickNice! That might work really well.
Out of curiosity, does field_collection expose relationships and whatnot properly to Views so we could pull off stuff like "Show all commits related to employees of this organization node" and/or "Show a list of organization nodes by the aggregates of their employees' commits, descending"? We can always those types of queries via raw SQL either way, so not really that important, but just curious if you know.
Comment #3
dwwIt definitely exposes relationships to views, yes, although I'm not immediately sure how to do exactly what you're asking for. It's probably pretty obvious, I just haven't thought about it in a while. ;) timplunkett could probably help with anything really wonky we'd be trying to do...
Comment #4
tim.plunkettTL;DR Field Collection will not be the hard part here.
---
Field Collection does have full integration with Views, but I'm not 100% sure that Views can even do that sort of query right now:
SELECT $table1.* from $table1 JOIN $table2 on $table1.foo=$table2.foo where $table1.$field1 < $table2.$field2;
I worked at Zivtech 2.5 years, and 90% of all my commits were during that time. How do we associate when my commits match with that date range, and not give my new employer "credit" for those?
It might take some tricky contextual filters, or even #357082: Pull filter value from an argument?, or damiankloip thinks views_field_view might help...
Comment #5
webchickWell raw SQL always work, too. Was just curious if it could be made to do with views. :)
Comment #6
drummSee also #968994: Multiple Values for listings of current companies and organizations. Both "Current company or organization" and "Companies worked for" should move from profile module to fields when we are on D7. (And all other profile module stuff before D8, but that's a separate issue.) Combining the two fields makes a lot of sense, so leaving a company is updating the end date or unchecking "current". Either this issue or that one needs to be marked as a duplicate.
Comment #7
Crell CreditAttribution: Crell commentedAnother factor to consider here: Just because someone works at a given company doesn't mean the company should get "credit" for that person's work. A lot of Drupalers do a ton of work in their own time, and it's not fair for their employers to be able to get credit for that when they didn't fund it.
How we differentiate between commits made by someone on company time vs. their own time I don't know, but it is something we should seriously think about. (That would also help to incentivize companies to allow people to contribute back "on the clock", since then they get credit/marketing value out of it.)
Comment #8
dwwBig +1 to #7 -- very good points. No suggestions on the right way to implement that, but definitely requires more thought before we make too many assumptions.
Thanks,
-Derek
Comment #9
mgiffordComment #10
mgiffordI think putting in issue level granularity as to whether one of many employers (or none) paid for work on an issue would be very cumbersome.
On the other hand having a sliding scale that allows a user to claim that their employee pays for 0 - 100% of their community work would be interesting.
So what are the steps to moving this to fields so we can start leverage D7 properly?
Would be nice to be able to leverage history so that one could tie contribution to an issue queue #2177459: Highlight Supporting Organizations in the Issue Queue.
Comment #11
mgiffordIt would be good if there could be some defaults available from a users account profile that could be used in helping to populate the more complex relationship of at least individuals & agencies in the profile. Adding issue relationship #2288727: [meta] Provide credit to organizations / customers who contribute to Drupal issues as being able to mark that in the commits will certainly help.
Also pointing to the place in @dries keynote where he talks about tracking individual/agency relationship and the transition of individuals between agencies. http://youtu.be/4NN5EM4CYVE?t=38m30s
Comment #12
drummWe should stick to strategies like #2288727: [meta] Provide credit to organizations / customers who contribute to Drupal issues, explicitly setting credit for the contribution.
We do now have a field collection for each user's organization, with a checkbox to mark which is current. It would be doable to add the start/end dates, but we shouldn't give users more fields to fill out if we don't use them.