2019-04-29 Reporting SIG Meeting notes

UPDATE: 

Who is attending: Sharon Beltaine, Nassib Nassar, Scott Perry (there but some other commitments), Angela Zoss, Kevin Walker, Holly Mistlebauer, Tod Olson (there but many other commitments), Steve Bischof (does OLAF reports, 5 Colleges, implementers data warehouse), Anne Highsmith (there but many other commitments)? 

Others? Questions?

-------------------

FOLIO Face-to-Face meeting plans:

Goals:

• Settle on what groups/individual should plan to attend

• Discuss and decide on meeting times/organization

• Identify any significant gaps in the program

-June 17-19 in DC, $100 registration fee

-120 attendees is the target

-hotel registration must be done by May 11

-Location of June meeting: DoubleTree by Hilton Hotel Washington DC - Crystal City,

300 Army Navy Drive, Arlington, VA 22202

-large WolfCon Conference is planned for January 2020

Working document for the Face to Face meeting:

https://docs.google.com/spreadsheets/d/1JELsHTfu_xYA1yTsyRCorZzEVofd8Njsg1Lo32rm_3s/edit#gid=1359585528

-------------------

Notes:

• Reporting SIG is going
• A few people have already said they can go
• Any others? Sharon is trying to plan sessions and would like to know everyone who is going, even if you're going to be pretty busy

Holly will walk us through the updates to the FOLIO JIRA system that she has created for reporting tickets to accommodate the data captured for each report requirement documented in the Report SIG Master Spreasheet. The Reporting SIG Master Spreadsheet will be kept for historical reference only, having been frozen and set to "View Only" at this point. 

Holly will also demonstrate how to enter any new reporting requirements into the JIRA system. 

-------------------

Notes:

• We're moving away from the Reporting SIG master spreadsheet - it is now locked down (or should be), so no further edits are allowed (let Sharon know if you can still edit, that's an error)
• Holly shows the new JIRA
• over the weekend, Holly loaded metadata from the master spreadsheet that wasn't already in JIRA
• when we first loaded reports, we only loaded a few fields and were relying on the spreadsheet for details
• now we're going to just use JIRA for everything, and each report now has all of the info from the spreadsheet
• for example, you can see the rankings in the results list
• any details already in JIRA were maintained
• if Holly was listed as "reporter" in JIRA issue, she changed it to the first contact from the spreadsheet; feel free to edit that if it needs to be changed
• REP-9 as example: frequency is "As needed"; that field might have multiple values, and all should have been transferred from spreadsheet
• for Import/export tab, added a label of import or export
• anything in "notes" was included and marked as notes (in comments?), but for some reason it's backdated to the report creation date
• REP-133 as example: has an institution ID, marked as yearly, has link to report sample; note: we want to attach reports from now on instead of linking to them, so that is the correct practice moving forward
• REP-201 as example: has multiple frequencies (yearly but also as needed)
• if you want to change the priority, functional area, etc. (things that don't show up on the summary page for easy editing), just click the "edit" button
• "Components": we needed a way for institutions to pull all of their own reports, and we weren't using Components for anything, so you can add your institution as a Component
• To search by institution: run a search for reporting, under "More" select component, then check just the institution you want
• Originally when we prioritized reports, we used P1 to P5; now we're using rankings: "go-live," "1st quarter after go-live"... matched P1 to go-live, P2/P3 to 1st quarter, and P4/P5 to within a year after go-live
• looking at all rankings, set the priority to be the highest ranking; if anyone said "go-live," it gets a P1; this is not automatic, so if you add a "go-live," please also change to P1.
• There were also issues that weren't in spreadsheet and things in spreadsheet that weren't in JIRA yet; you may have new issues where you're the reporter
• Adding a report now: no longer two-step, everything is in JIRA
• Checking for existing reports: do a search for the functional area (under "More"), then add a keyword to filter down more and read the reports that already exist
• If it's similar to an existing report, you can update it to add some other details (e.g., "I also need to be able to sort by X")
• If you need to create a new issue, check out Adding a new report to JIRA
• Note from Sharon: for prototype development, purpose of report is really important; please be as clear as possible so we can build reports that meet needs
• For multiple select fields like frequency, hold down ctrl key while you select
• Each institution has a separate ranking field; if you go into JIRA and don't see one for your institution, tell Holly
• if the report is possibly an in-app report, tell Holly, but she will also be on the lookout
• Some comments might have gotten cut off; Holly will be checking on that
• if the ranking needs to change for your institution, go ahead! just make sure you check that the priority is correct afterward; we'll probably have to audit this periodically because it's easy to forget
• Holly will update documentation with explanation of match between ranking levels and priority levels

Data Privacy for the LDP Data Warehouse

-need to form a subgroup (minimum 3 people) of the Reporting SIG to work on Data Privacy for Reporting

-capture "Reporting Data Privacy" requirements and issues in the Reporting SIG wiki

-what data should be removed from extraction as we build the LDP Reporting Data Warehouse?

-request that Reporting SIG make a set recommendations on approach to anonymizing data

-European standard for GDPR

-capture in JIRA as an LDP feature?

-build survey about current practices

-may need interaction with UM and Privacy SIGs

-may need to bring to Product Council

-------------------

Notes:

• Btw, having the reports entirely in JIRA is great for organizing and linking to development work, will be very helpful
• have known for sometime we need to address this - e.g., de-identifying data that gets extracted into LDP - but we've gotten to a point where we have a sense of how the database will be structured and used, so good time to start looking at this question
• we need a few volunteers interested in and willing to research a bit; think about the question and make some recommendations (for reporting in general but specifically for the LDP; basically a data warehouse model); we may want to de-identify the data (a likely recommendation), but we need someone to really think about it and contribute to the decision making about that
• any interest in forming a small subgroup?
• this feels like a short-term, small workgroup; would recommend noting the important outcomes of the discussion, making a page in the wiki
• in the FOLIO apps, data privacy would be in the purview of the individual apps, so this is generally scoped to just the LDP
• would be great to have someone with GDPR experience
• Privacy SIG hasn't been active, but could interface with other apps
• could share a proposal with Product Council
• Sharon isn't really available for this; looking for 3 folks willing to have some separate meetings, put together recommendations, things to consider, etc., maybe put together a survey of current practices
• at the very least, need to organize the issues a bit, help the SIG think clearly about the issues, pull in subject matter experts and software/database people as needed
• please think about it, contact Sharon if you are interested (she will email the list)
• probably just needs maybe 5 meetings, may need to work with conveners of other groups, probably User Management (they are already discussing, maybe talk with Maura Byrne), maybe also SysOps, Data Migration subgroup

UPDATE: Quick review of the Reporting Features for Ranking spreadsheet  (an extract of only the reporting epics).

It is still important for reporting representatives from each institution to rank the issues under Epics UXPROD-1319 (LDP Data Warehouse reports) and UXPROD-867 (In-App reports).

--------

Holly will review a spreadsheet that shows what reporting features need to be ranked by each institution. Please use this template at your institution to complete your analysis, then submit it to your Product Council representative for the Gap Analysis. The Gap Analysis must be completed by April 30, 2019; check with your institution on specific deadlines for submitting your feature rankings.

Please download and use the Reporting Features for Ranking spreadsheet to rank reporting features for your institution.  (Note:  The full Gap Analysis and Feature Ranking spreadsheet includes instructions.  The Reporting Features for Ranking spreadsheet is an extract of only the reporting epics.)

Today, we will continue the process of reviewing the priority level of data warehouse reports in each of the functional areas to determine which should be passed along to the Report Prototype Working Group to prototype in the LDP data warehouse. 

• Today's focus will be Metadata Management reports

• A proposal to simplify the "in-app vs. LDP report" question: LDP vs. In-App Reporting
• A vestigial question: "What data elements will be included?"

-------------------

Notes:

• have heard feedback from outside Reporting SIG, lack of insight about some of the reporting directions
• people are confused about what gets promoted to an in-app report; seems arbitrary to others, so created another wiki page (know there is another page like this, but the previous discussions were based on surface features, and wanted to try to simplify the questions, not sure if it has succeeded but wanted to try a different approach)
• might want to merge the pages later
• in the past there have been lists of criteria, maybe as many as 8; this page is more conceptual, what is the difference, why is there a distinction
• in many other ILSs, reporting was done against the operational database (or a copy), and FOLIO will be different
• LDP is basically a data warehouse; a specialized database that is designed to support certain kinds of questions, like "strategic decisions" of the library and "predictive modeling", as opposed to functions of the day-to-day business operations; designed for flexible analytics, updated intermittently (traditionally overnight, once a day, but should be able to do it more frequently to approach more real-time data)
• there is potentially a third category - you could write a script that connects to a FOLIO module via the API, just like in-app reports do, to retrieve operational data; could be outside of an app, and would work like writing a SQL query against the LDP, but the script would be trickier because you would have to join the data yourself and use the API documentation to find the fields you want, but it is an option if you want operational data and have the resources to script like this
• please think about this and either discuss now or send feedback to Nassib
• second piece of feedback Nassib has gotten is about the data elements we're included - have heard that library staff want all fields; this is a question that always comes up, but it has gotten new life because now we're prioritizing reports in order to choose data elements to model. because we're creating a data warehouse, we don't just have all data elements by default, so we do have to be active about it. In principle, we are going to get to all elements, so don't think this question is valid, but we have to model in some order.
• there seems to be an urgency because people who are used to having access to everything know how to report against that, and not knowing what won't be available is hard to imagine
• we can't say when everything will be modeled, but we can say that not everything will be done by go-live, so we do have to keep that in mind
• other parts of FOLIO have been going for 2+ years, and we've just had a few months
• can always share the backdoor idea (using the API to access the operational data) to have access to data elements that aren't in LDP yet
• each FOLIO module has a versioned API, and the versioning is going to be carefully controlled, but the databases on the backend of each modules is different and versioned separately, so all interactions have to go through the standard interface
• maybe time to do some outreach? plenary at June meeting, webinar? will have to coordinate with product owners before publishing anything though

Review and update Topics for Future Reporting SIG Meetings