Provide a way for metrics projects to get data affiliation from members database
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Core Infrastructure |
Triaged
|
Medium
|
Unassigned | ||
openstack-org |
Fix Released
|
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://
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.
Changed in openstack-ci: | |
status: | New → Triaged |
importance: | Undecided → Medium |
milestone: | none → icehouse |
tags: | added: openstackid |
Changed in openstack-ci: | |
milestone: | icehouse → kilo |
no longer affects: | openstack-community |
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