Closed Bug 810321 Opened 12 years ago Closed 8 years ago

Need credentials & access to MoCo Phonebook

Categories

(Privacy Graveyard :: Product Review, task, P3)

Product:
Privacy Graveyard
Component:
Product Review
Platform:
All
Other
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: aelliott, Assigned: sstorey)

Details

Metrics is tasked with creating a leverage calculation for community, for which we need the phonebook info on a monthly basis.

Please provide credentials & access to the database sufficient to dump to the metrics DWH on a monthly basis. 

For reference: https://projects.mozilla.org/browse/METRICS-1129
Ingest/update Staff Phonebook monthly to enable community leverage calculations
This probably need sign off from legal and privacy at the minimum. I'm not sure who's point on making that happen, CC'ing Corey and Jabba as well as Dave, who I think is our (IT's) liason with Privacy. CC'ing Liz from Legal to point us to the right people to work with on Legal.

There's also a draft data policy - https://mana.mozilla.org/wiki/display/SECURITY/Draft+-+Data+Protection+Policy so CC'ing opsec too :)

Finally, moving this to Jabba as his team will probably work on this, once you have all the approvals.
Assignee: server-ops → server-ops-infra
Component: Server Operations → Server Operations: Infrastructure
QA Contact: shyam → jdow
going to ask :joes to advise what needs approved and from whom.
I don't understand what this project is, but if it involves sharing, or making less secure, employee personal information, then several reviews are needed. There is a new project kick-off form for such projects. We haven't announced it yet because we're still testing, but its available for use. If this project has privacy and/or security implications, please go to https://bugzilla.mozilla.org/form.moz.project.review and complete it. This will create the necessary bugs.
What extent of the information is needed from phonebook? Phonebook is simply a frontend to our LDAP database that displays a subset of information. If you can give me a list of attributes needed, I can work up a script, once the various folks sign off on this project.

Looking at the JIRA project, it looks like all that is needed is: e-mail address, name, manager and employee type? If that is all, this is a relatively easy LDAP query and just needs a bind user with permission to see those 4 attributes, which I can provide along with a script to dump this data into an .ldif file.

I'll await approvals before moving forward.
Assignee: server-ops-infra → jdow
We are to calculate leverage for david boswell. We only need enough info from the org chart to determine who works in what "department." For instance, developers, legal, support, webdev, qa, metrics, others. I've cc:ed David Boswell, as he will have a better idea of the buckets he needs counts for.

We certainly do not need ANY contact info. Just names, department, possibly geo area.
(In reply to Annie Elliott from comment #5)
> I've cc:ed David Boswell, as he will have a better idea of the buckets he needs
> counts for.

In terms of the buckets, we'd like to know which contributors in a given functional area are employees.  This will allow us to calculate a leverage ratio (a standard metric used by orgs that have volunteers).  

For instance, we've manually looked at SUMO contributor activity recently and calculated that for every 1 SUMO employee there are around 20 SUMO volunteers.

The mapping of employees to functional areas is probably more straight-forward in some areas vs. others.  For instance, the SUMO team maps to the support functional area, but for other functional areas, like coding, I imagine that would cover a range of different teams.
(In reply to Shyam Mani [:fox2mike] from comment #1)
> This probably need sign off from legal and privacy at the minimum.

For reference, this sort of leverage calculation has already gone through PR, privacy and security reviews as part of the review process for the coding patch dashboards.

http://www.arewegrowingyet.com/codingmap

http://www.arewegrowingyet.com/codingtrends

If you check out the patch contributors dashboard you'll see that there's a column that lists contributors as either Staff or Volunteers.  To get the leverage ratio, you just compare the totals of the two types of contributors.

The determination here is based on someone's email address -- if you use @mozilla.com you're tagged as an employee.  This isn't ideal because not all employees interact with our systems using their Mozilla addresses so the information isn't as accurate as it could be.

Checking employee status by looking at the internal phonebook should give us better information, but it's not doing something brand new in terms of the data we're reporting on.
(In reply to Annie Elliott from comment #5)
> We are to calculate leverage for david boswell. We only need enough info
> from the org chart to determine who works in what "department." For
> instance, developers, legal, support, webdev, qa, metrics, others. I've
> cc:ed David Boswell, as he will have a better idea of the buckets he needs
> counts for.

All of those entries in LDAP are self-manageable and arbitrary.  I can arbitrarily change my geography or title or "department".  

The most authoritative source is really Workday, not LDAP.  Can you pull from there instead?
:mrz That would be infinitely preferable if it is at all possible. Who do we talk to to get credentials? Can they be cc:ed here to approve?
I'm unclear who owns Workday - can you ping your HR rep?
Annie, you can contact Sylvie Brossard about Workday.
David - In comment 7 you said "this sort of leverage calculation has already gone through PR, privacy and security reviews as part of the review process for the coding patch dashboards." Nevertheless, I'm adding Tom from Privacy, Jishnu from Legal, and Michael Coates from Security to confirm they don't need to do another review. I don't think anyone completed the project kick-off form as I suggested in comment 3. To whom would the information collected for this project be available?
(In reply to Liz Compton from comment #12)
> David - In comment 7 you said "this sort of leverage calculation has already
> gone through PR, privacy and security reviews as part of the review process
> for the coding patch dashboards." Nevertheless, I'm adding Tom from Privacy,
> Jishnu from Legal, and Michael Coates from Security to confirm they don't
> need to do another review. I don't think anyone completed the project
> kick-off form as I suggested in comment 3. To whom would the information
> collected for this project be available?

Liz - Staff data would be collected into the metrics data warehouse with a minimal number of fields as suggested, and available only to folks with metrics team credentials. From there, it would be transformed into an anonymous count of people by department by month.

Once that rollup is done, that count (the anonymous number) would be used internally as the denominator in a calculation. 

The numerator of that calculation is the number of (no names, just an aggregated number) of contributors in a similar area/department by month. The resulting calculation (numerator / denominator) is the "leverage." 

The leverage itself (and no the data used to calculate it) would be made available
to MoCo folk, and community leaders.
This looks like it probably implicates safe harbor, since it's about employee PII. Stacy has the expertise there, so I'm handing the privacy check here off to her. Stacy, if this bug feels a little cramped, feel free to fork a blocking privacy bug if you need to.
Flags: needinfo?(smartin)
Based on comments 8 and 9, I think I'm not the right owner of this bug. Pushing to privacy for now. I agree that workday would have the information desired, where phonebook/ldap would take a lot of deriving and assuming about the data that is already non-canonical.
Group: infra
Component: Server Operations: Infrastructure → Privacy Review
Product: mozilla.org → Privacy
QA Contact: jdow → afowler
Version: other → unspecified
Stephanie or Sylvie, do you have any thoughts on how Annie can get this information from Workday?
We could provide a report to Annie on a regular basis with employee names, cost center and location. We would not be able to give her access to the information on a permanent basis at this point. What frequency would she want the report ?
This is also information that I require for my work as a coding steward investigating metrics about commits and bugzilla accounts.
(In reply to sylvie from comment #17)
> We could provide a report to Annie on a regular basis with employee names,
> cost center and location. We would not be able to give her access to the
> information on a permanent basis at this point. What frequency would she
> want the report ?

Monthly.

Sylvie, it would not actually be me physically logging in, rather an ETL job doing a very specific query on a regular (monthly) basis.
Can someone clarify why we would need names? Could it work to get a count of the number of people in each department?
Flags: needinfo?(smartin)
Please see comment 5. If you do the calculating part on your end, we need no names. Just a count per department.
Thanks!  Sylvie, would WorkDay provide a monthly report of count per department?
Please note that this will be used to tie to contributorship data within a given month, and would really need to be monthly.

It would be great if, as a one off, we could also get a "backfill" to fill out 2012 by month.

Meaning, something like:

MONTH  DEPTA_COUNT   DEPTB_COUNT   DEPTC_COUNT ... DEPTN_COUNT
January  5  25  20  ... 4

...

November 6  24  21  ... 7
I require names for my work to be able to determine whether a given committer is a volunteer or not.
Just to make sure we are clear : we do not have any contributor information currently in Workday.It is something we are working towards but not happening yet. Only paid staff.
At this point we can provide you with reports but I do not expect we can provide you with any integrated or integrable type of data (as in feeding your system directly). It is again something we are working on for the next quarter or so, in a more gneral approach of contributor data and systems integration.
Hi Josh - how are you currently making your determinations?
(In reply to Stacy Martin [:stacy] from comment #26)
> Hi Josh - how are you currently making your determinations?

Currently I take the list of committers and categorize them by email addresses such as mozilla.com and codeaurora.org, but that leaves out a large number of paid staff who use non-MoCo email addresses. Accordingly, I need to match them by name instead.
I've confirmed with our outside counsel that this is not an issue for our Safe Harbor certification.  That's because it's covered in our new, soon-to-be-released, Employee Privacy Policy in the "uses" section, as " performing workforce analysis and planning. "  Both of these uses would fit this category, so we are OK from a Safe Harbor perspective.
Assignee: jdow → smartin
Hi all - Does this still need resolution?
Absolutely. Being able to associate names with employment status would be exceedingly valuable to me.
Stacy, what can I do to push this further along? Ideally I'd like to have a monthly report of names of employees and all known associated email addresses, and at this point I would be willing to have that sit behind an employee-only LDAP authorization if that will expedite the process.
Flags: needinfo?(smartin)
Scott, redirecting to you. This is information I'd like, and I'm not sure how to proceed from here.
Assignee: smartin → sstorey
Flags: needinfo?(smartin)
Stacy sent me this bug but I'm not sure exactly what's going on since this bug was opened a year ago.

I fully support Josh getting access to Workday data, including names, so we know who's contributing to the project. He clearly needs it from comment 27, there is no other technical workaround that I can think of. I don't know who owns Workday.
Hi Monica: I've been in touch with Josh and am working with Workday on configuring the permissions to fulfill this request.
Thank you to both of you!  Is there also a need to get volunteer info (not in WorkDay)?
(In reply to Stacy Martin [:stacy] from comment #35)
> Thank you to both of you!  Is there also a need to get volunteer info (not
> in WorkDay)?

If the point of this exercise is to measure the ratio of employee commits/non-employee commits, then I don't think so, unless I am missing something.

Of course there are many more way to contribute than committing code (wiki edits? irc traffic?), not sure if Josh was interested in these as well.
(In reply to Stacy Martin [:stacy] from comment #35)
> Thank you to both of you!  Is there also a need to get volunteer info (not
> in WorkDay)?

It is a goal to be able to measure the leverage we are getting around community building for projects, so that would mean we need to identify who is an employee and who is not.
If we have a way to identify employees by key data such as name, email address(es), irc nick, etc., then from my point of view we can infer volunteer status by lack of employee data.
privacy council triage: Is this bug still valid or needed?
Flags: needinfo?(aelliott)
Priority: -- → P3
David - now that we can get to Workday data, is this bug still valid or needed?
Flags: needinfo?(aelliott) → needinfo?(dboswell)
(In reply to Annie Elliott from comment #40)
> David - now that we can get to Workday data, is this bug still valid or
> needed?

This is a question for Pierros, so I'm adding him to the bug.  Pierros, is this bug still relevant or is this no longer needed with the current contributor activity metrics plan?
Flags: needinfo?(dboswell)
Closing for inactivity, but the Workday data has proven to be both sufficient and useful in the past year.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.