Abstract: Beginning in 2015, Opus will be the information system of record for faculty activities at the University of California, Los Angeles (UCLA). Opus will serve as both a profile system, storing data about faculty work, and as a workflow and approval engine for the promotion and tenure process. Opus leverages institutional master data wherever possible to collect data about faculty activity. However, re-purposing institutional data collected for purposes not related to academic review necessitates allowing data subjects (UCLA faculty), to contextualize and reframe the data for the review process. Collecting, displaying and storing these augmented records (master data with manually added metadata from faculty) has forced the project team to grapple with questions regarding fairness and transparency to both data subjects and to data consumers. How can we hold to “good design” and usability practices, while faithfully representing the inherent “messiness” of the data? How does the context in which the data was collected impact re-purposing the data for academic review? What does it mean to “own” faculty data? This paper outlines our attempts to address these questions, noting the trade-offs and limitations of the selected solutions.
This topic was presented at the 2015 iConference on March 26, 2015 in Newport Beach, CA. Since 2005, the iConference series has provided forums in which information scholars, researchers and professionals share their insights on critical information issues in contemporary society. An openness to new ideas and research fields in information science is a primary characteristics of the event.
Who Owns Faculty Data?: Fairness and transparency in UCLA's new academic HR system
1. Who Owns Faculty Data?
Fairness &Transparency in
UCLA’s New Academic HR System
CHLOE REYNOLDS & HEATHER SMALL
UCLA, IT SERVICES
ICONFERENCE
3.26.15
2. Topics
History
of
the
project
Issues
a) Data
Ownership
b) Data
Access/Privacy
c) Data
&
Truth
d) Data
Representa@on
Q
&
A
3. Opus History
Our
Role
◦ Role
–
analysts
on
IT
team
building
a
new
faculty
informa@on
system
(Opus)
System
Features
◦ Academic
Personnel
(AP)
workflow,
Curriculum
Vitae
data,
Repor@ng
History
◦ Faculty
have
called
for
improvements
to
the
AP
review
process
since
1988.
◦ The
AP
process
has
been
es@mated
at
$10M/year
and
takes
up
to
300
days.
◦ In
2010
a
joint
Academic
Senate/Administra@on
taskforce
report,
provided
the
impetus
to
build
an
electronic
academic
review
system.
◦ Beta
release
in
Dec.
2014;
mul@ple
major
releases
over
the
next
year.
5. Data Ownership
Problem
◦ The
value
of
the
Opus
data
depends
on
a
consistent
set
of
expecta@ons
about
data
fidelity,
security,
and
access.
Mi@ga@on
◦ Iden@fy
data
stewards
for
each
data
element
◦ Display
data
steward
informa@on
to
Opus
users.
◦ Error
correc@on
begins
with
the
authorita@ve
source.
7. But defining ownership is hard
A
tale
of
two
salaries…
…And
what
about
publica@ons,
degrees,
community
service
ac@vi@es?
8. Lesson # 1
In
aggrega@ng
data
from
various
sources,
you need to
understand the story of the data in each context
Who is “authoritative” is context-specific,
rather
than
enterprise-‐specific
All of this needs to be factored in
for every single data element.
10. Access & Use
Problem
◦ Balancing
the
business
needs
of
the
organiza@on,
the
public’s
right
to
know,
and
faculty
privacy
&
security.
Mi@ga@on
◦ Granular
visibility
sedngs
&
transparency
about
usage
◦ Public
visibility
for
minimal
set
of
data
◦ Private
visibility
for
data
about
works
in
progress
◦ Access
to
detailed
data
limited
to
those
with
a
business
need
◦ Review
process
for
reques@ng
data
for
new
uses
11. PrioriCzing access & use
…when
does
faculty
privacy
trump
the
public’s
right
to
know?
…when
does
business
need
trump
faculty
privacy?
What
does
the
public
have
the
right
to
know?
13. Lesson #2
Fear of change occurs at every level of
projects and organizations
Pudng
things
‘under
the
microscope’
and
scrutinizing
practices and data can create a sense of
exposure and vulnerability.
Stakeholders often have overlapping and/or
competing interests and incentives
around
how
data
are
collected,
used,
and
interpreted
(Borgman,
2013).
16. Data Sources
Data
will
come
from
many
sources
◦ Internal
(campus)
systems
◦ External
systems
◦ Data
entry
For
example
◦ From
the
student
registrar
system:
course
level,
course
@tle,
number
of
instructors,
term,
enrollment
17. MulCple NarraCves
Problem:
Mul@ple
narra@ves
◦ Data
elements
comes
in
from
different
sources
◦ Updated
and
augmented
by
different
par@es
◦ Viewed
by
various
user
groups
◦ Viewed
for
different
purposes
than
they
were
collected
for
Mi@ga@on:
Transparency,
Annota@ons,
Educa@on
◦ Data
provenance
transparency,
annota@ons,
data
literacy
educa@on
Example
◦ Enrollment:
as
indicator
of
level
of
faculty
work,
as
a
financial
metric,
as
a
measure
of
student
body
size
21. RepresentaCon Issues
Problem:
Reducing
Informa@on
to
Data
points
◦ Workload
reduced
to
course
size,
student
evalua@on
ra@ngs,
number
of
publica@ons,
amount
of
grant
money,
etc.
Mi@ga@on:
How
to
represent
mul@ple
truths
◦ Annota@on
and
descrip@ons
◦ Data
literacy
educa@on
Examples
◦ Enrollment
-‐
co-‐teaching/seniority,
cross-‐lis@ng,
exchange
&
extension
students,
theater
◦ Publica@ons
-‐
publica@on
pakern
variance
by
discipline,
early-‐cited
ar@cles
emphasis,
etc.
◦ Gray
lines
disadvantage
the
modest,
but
seem
“fair”
22. RepresentaCon Issues
Categories
◦ Publica@on
Types
◦ Obituaries,
Interviews
(about
me,
by
me,
or
of
me)
◦ Degree
Types
◦ translate?,
when
to
merge,
maintenance,
crosswalks
Terminology
◦ Awards,
etc.
23.
Lesson # 3
SemanCcs maRer
Seman@cs
are
@ed
to
iden@ty
and
cultural
associa@on
Who
decides
what
things
are
called?
How
do
you
come
to
a
compromise
when
stakeholders
disagree?
25. Lesson # 4
Data projects can expose &
exacerbate
…policy
gaps,
inconsistencies
in
prac@ce,
long-‐standing
disagreements,
old
habits.
One
of
the
main
reasons
this
project
was
ini@ated
was
because
campus
iden@fied
the
AP
process
to
be
in
need
of
re-‐engineering.
We
were
akemp@ng
to
resolve
transac@onal
inefficiencies,
but
those
proved
to
be
a
symptom
of
larger,
more
complex
issues.
26. “Can’t you just go build the system?”
Why
do
technologists
find
themselves
wrangling
with
what
are
essen@ally
policy/legal/ideological
issues?
It’s
incumbent
on
the
technical
team
to
educate
stakeholders
about
the
complexity.
27. Q & A
Live
System
h"ps://opus.ucla.edu
Opus
FAQ
h"ps://opus.ucla.edu/public/FAQ.shtml
Opus
Privacy
h"ps://opus.ucla.edu/public/privacy.shtml
Original
Charge
h"ps://www.apo.ucla.edu/ini<a<ves/opus/charge
Heather
Small
hsmall@it.ucla.edu
.
Chloe
Reynolds
creynolds@it.ucla.edu
