Announcements /
Reminders | Angela | Documentation for Lotus is Live! https://lotus.docs.folio.org/docs/ Thanks, documentation team! Request for feedback: take a look at the reporting pages and let E Pennington know if you have suggestions!
WOLFCon 2022 - Aug 31-Sep 2; Hamburg, Germany
- Registration Open
- Early registration for in person is a $50 savings, extended to June 3
- Virtual attendance: $15, already open
- Current planned sessions
- Two reporting-related sessions planned:
- SIG organized: Reporting Lessons from Implementers (Panel, Standard (50 min), Hall (up to 250 people), Live presentation)
- LDP/Nassib organized:
How to find our latest recordings - Separate folders right now: January/February recordings, recordings from March and onward
- New problem with recordings: now need a password. Use the same password from our Zoom meetings. If you enter the password and it just takes you to the password screen again, refresh the browser page and the recording should show up.
(Always) Recruiting New Query Developers - The Reporting SIG is always on the look-out for new query developers. Please let us know if you are interested in doing query development or if there are others at your institution who might be a good fit.
|
| Proposal for Tracking New Report Requirements |
| - Use GitHub only, no JIRA
- use Discussion Board on folio-analytics to collect report requirements for new reports institutions are requesting
- if we do establish GitHub as a place for feature requests, we could publicize that in the docs.folio.org documentation
- when we have issues that impact our reports but are tied to applications, FOLIO uses JIRA, so not sure how to track that (e.g., you're waiting for a data element before you can create the report, or there is a new feature that you are waiting for); how to track that? how will people respond?
- is there a reason for staying out of JIRA? especially with those dependencies to other JIRA issues?
- even if we did it all in GitHub, why use the discussion board instead of an issue? seems like this is similar to a feature request. in TC have been looking at how we make decisions and how we document that, so thinking about how we communicate here with that lens.
- JIRA issue - in talking about tracking in JIRA, what usually comes up is that there is a lot of overhead. we could get around that by trying to make it simpler. and there have only been a few issues that have been helped by JIRA. does the rest of FOLIO really care about our rankings? we can set those rankings in our report development team meetings. I've been able to escalate issues using JIRA at Cornell, but not sure I need JIRA to do that. a lot of people start in JIRA but then let it slip because there is too much overhead. The trick is to keep a small set of requirements, keep it current, JIRA isn't great at that.
- we also have a lot of reports now. discussions might be nice because we could make sure that the requests are new and where people could feel free to bring something up and discuss it and prioritize it before it becomes an issue.
- discussions can be broader; maybe someone is unfamiliar with what currently exists. in discussions we can track and close. if there is a feature request, we can switch it from discussion to issue.
- sounds like there's two phases - exploratory (discussions, "is there a need for this thing") and then formal request (issues, specific requirements)
- conversation started with, where do people initially bring up the questions? sometimes slack, but you have to be a member in the right Slack to see/submit those, whereas GitHub is open and that's also where we are doing the work
- GitHub workflow is leaner than JIRA; JIRA more designed for development workflows in FOLIO in general; our positions, we don't have a PO who is so into JIRA that they are JIRA ninjas, so that's a barrier, GitHub is more accessible. JIRA, have to assign to people, but GitHub can stay in one tool.
- one thing we might need is an issue (in GitHub or JIRA) to point to, for each release, these things are creating problems for us, or we need these things from the FOLIO project application developers; one thing JIRA helps us with is escalating barriers or problems; maybe create a JIRA that summarizes the reports we're working on for a particular release, and then we can link that to other feature requests so we can help escalate that work
- part of what TC has been thinking about is that there is the decision itself and then also all the context around it; TC's solution is to have RFCs that have the details and the context (when necessary) but also have an architectural decision record (this is the decision); that speaks to the need for a report, the need for data that feeds that report, but also the context for the report; one of the things that is important to capture, especially when you're asking for a change to FOLIO apps or data model, is that this feature is not currently available for reporting regardless of reporting platform, so it's a feature request for all possible reporting systems (that is going to be important to capture)
- our development is somewhat governed by both FOLIO and the LDP project, so we're trying to stay visible to multiple communities
- when we talk about reports, we're almost always talking about presenting data to someone to drive a decision or for supporting some kind of operational process; this is nice, because those things are pretty clear; when we talk about needs, maybe those are the things to highlight, those can drive what needs to be recorded; those needs are core to any report and can be the driver for any changes we're asking for
- what about the backlog?
- RM is working on clearing out the backlog (and should they be written for LDP, Metadb, or both?); there are still report requests that are blocked by missing features
- ERM is same, trying to work through backlog
- MM one of our big blockers has been SRS/MARC; SRS has developed over the past year, data elements have changed; with Metadb might actually be able to get to the remaining queries
- not sure if it's a blocker or not, but people implement their metadata differently enough that general reports don't necessarily make sense in MM; pressure to create vanilla reports but no one really likes them; it's challenging
- RM agrees, but just sometimes make a decision and go forward with it; one way around it is a kitchen soup query (lots of elements)
- could encourage more public institutional query repositories so we can point people to examples from different institutions
- this is one of the points that make the decision interesting; what data might be needed and refining the requirements to see if it is possible to have this report or is it more a discussion where the reporting SIG gives advice on how to produce a report
- this could also come to us via Slack, need people to be monitoring both
- how to decide when we create a report or when we just give advice?
- maybe use generality as our guide
- create/publicize some kind of explanation of how we decide what queries to work on
- if we do everything outside FOLIO JIRA and there is no connection, don't know that that is the best path
- maybe we can create a page in the wiki where we write down the workflow - how people can create requests, how we work on the requests; transparent workflow for the community; how we check the request, how we communicate with the members who sent the requests; I think wiki makes sense because it's the first place people look for this; link from main SIG page, maybe also from GitHub?
- have heard that tenants don't know how to create an issue for reporting, they need to know how to submit these requests
- Next steps:
- continue discussion in Thursday SIG meeting
- draft new workflow in a wiki page
- ask for feedback, first from SIG, then from rest of FOLIO community
|
| Updates and Query Demonstrations from Various Reporting Related Groups and Efforts | Community & Coordination, Reporting Subgroup Leads | Project updates Reporting development is using small subgroups to address priorities and complete work on report queries. Each week, these groups will share reports/queries with the Reporting SIG. Reporting development team leads are encouraged to enter a summary of their work group activities below. RA/UM Working Group - Meetings have become more of a lab session, working through specific problems
- Angela has been attending RA SIG meetings to open the lines of communication, now once a month
- Contact Angela if you would like to join these meetings; second Wednesdays at 1pm Eastern
- Context
MM Working Group - Meetings are 1st Tuesday of the month, 12-1pm ET via zoom using the usual FOLIO password. Our lab sessions are open to everyone. Please bring your questions, examples, and comments about reporting and metadata.
- We are still looking for reviewers. Please contact MM reports working group.
- We have completed pull requests for all but 1 derived table for metadb.
ERM Working Group - ERM Prototype and Query Development Status
- Currently working on fixes that came with the data schema changes
- We will add comments to the columns in the derived tables with Folio Analytics version 1.5
- Axel gave a tutorial on how to create agreements, orders and invoices in the UI (recording is available)
- Topics for the future
- Meetings are bi-weekly on tuesdays 11am ET alternating with RM Working Group
RM Working Group
Reporting SIG Documentation Subgroup - Honeysuckle documentation is live on https://docs.folio.org/docs/
- Iris documentation is in progress, due December 15
- Additional Context
- The Reporting SIG has representation on the Documentation Working Group, which is building end-user documentation for https://docs.folio.org/docs/ (mostly linking to existing documentation over on GitHub)
External Statistics Working Group - no updates currently
- new organizational/tracking scheme for JIRA, with pointers to queries in folio-analytics repository
- New organizational structure for External Statistics reports
- external statistics reports (e.g., ACRL) typically require running queries from different functional reporting areas
- these reports will be captured in JIRA under one UXPROD-XXXX report cluster issue, then the descriptions will point to each of the queries required to run them on the folio-analytics repository
- institutions will need to rank each of these 8 new UXPROD-XXXX report cluster issues
- each reporting development team will take responsibility for the queries in their area for the external statistics clusters
Product Council
For all recent work on FOLIO Reporting SQL development:
|