Provide a way for metrics projects to get data affiliation from members database

Bug #1260140 reported by Stefano Maffulli on 2013-12-12
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Core Infrastructure
Triaged
Medium
Unassigned
openstack-org
Undecided
Unassigned

Bug Description

Currently the data about affiliation of a person working on OpenStack is stored in the Foundation Members database. This database is only accessed privately by wikidsmart which uses it to build the pages like http://activity.openstack.org/data/display/OPNSTK2/Organizations, the personal pages of individuals and companies as confluence pages. This approach, while it may work for one project, doesn't scale well because exposing the database directly to more users would increase dramatically the risk of privacy breach.

Also the straight use of the database has shown limits because data entered by users cannot be trusted 100%. We've seen various mis-spelled company names and various ways to spell out the name of the same company (HP vs H-P vs Hewlett-Packard and many more permutations). We also see duplication of users in the database itself.

This probably means that we should have a service built on top of the Members database that can provide data about affiliation, company names normalized according to rules, duplicate names merged, and protects the privacy of the users while still allows for stackalytics, bitergia's tools and wikidsmart to match actors on gerrit, git, launchpad, mailing list, etc and Members.

Jimmy McArthur (jimmy-l) wrote :

This is primarily what we're implementing oAuth for. You can limit/expose whatever user data you want, via an API, amongst your various web properties via auth requests, assuming the user is authenticated via OpenID. If you're pinging the db directly, you get rid of a lot of the dupe user entries and dupe org names as the data is more normalized than it is through Wikidsmart, based on the demo I saw.

Once you implement your API, you can expose it to Wikidsmart, Stackalytics, etc.. so you're all dealing with the same data. If this is the direction you want to head, let's spec it out and go from there.

Thanks!
Jimmy

Jimmy McArthur (jimmy-l) wrote :

This is currently added to our to-do list.

Changed in openstack-org:
assignee: nobody → Jimmy McArthur (jimmy-l)
status: New → In Progress
Jimmy McArthur (jimmy-l) wrote :

Apologies - added comment to wrong ticket.

Changed in openstack-org:
assignee: Jimmy McArthur (jimmy-l) → nobody
status: In Progress → New
Jeremy Stanley (fungi) on 2014-02-04
Changed in openstack-ci:
status: New → Triaged
importance: Undecided → Medium
milestone: none → icehouse
tags: added: openstackid
Jimmy McArthur (jimmy-l) wrote :

We have now committed a CCLA/ICLA management tool to the OpenStack Foundation Member database. It has been QA'd in production, but not yet rolled out to the relevant companies for them to begin adding ICLA members to their CCLA team. Once completed, the check should be three-fold to ensure members have a launchpad account, have signed the CLA, and are registered as Foundation Members.

Changed in openstack-org:
status: New → In Progress
Jeremy Stanley (fungi) on 2014-10-27
Changed in openstack-ci:
milestone: icehouse → kilo
Stefano Maffulli (smaffulli) wrote :

It would be good to raise the priority of this effort. Besides the CCLA, which is out of scope for this request, we need to have a way to query openstackid service for a user (for example) and get back their current affiliation, the history of the affiliation for that user. Or query for a company and get a list of current and/or history of their affiliated users.

Changed in openstack-community:
importance: Undecided → High
Jimmy McArthur (jimmy-l) wrote :

I can finally close this! We have now implemented this and delivered to Infra :)

Changed in openstack-org:
status: In Progress → Fix Released
no longer affects: openstack-community
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers