2022-08-11 - OA SIG meeting

Meeting time: 8:30 AM (US Eastern Time) / 1:30 PM (BST) / 2:30 PM (CEST)

Meeting URL: https://openlibraryfoundation.zoom.us/j/82643780981 (Password required)

OA Working Group Wiki: Open Access SIG Home

Google Drive Folder: https://drive.google.com/drive/folders/1HR1JyDkUeRE0kL1eBKcu6uIvcNcnn352?usp=sharing

Slack channel: #open-access-management

Mailing list: folio-rm-oa@ole-lists.openlibraryfoundation.org (Subscribe here selecting 'folio-rm-oa' list)

Housekeeping and major community updates

• Outstanding topics, please add any topics that have not yet been discussed, or those that you feel need more discussion to fully understand the issues
  • https://docs.google.com/document/d/1BTlDlHhaAX35PAQDpz0VvdiObOC3-b1zD5fPl4pgSLU/edit
• All: Please add yourself to the SIG member list at Open Access SIG Home. This is optional but gives the larger community a sense of involved institutions and SIG expertise

Agenda items

• Discussion - Recording faculty/institute for authors and requests

Minutes

Owen invited users to test the new Checklist functionality and to give feedback in the Slack channel. 

Owen is on leave for a few weeks and will then be at Wolfcon. Gill and Jack will pick up any feedback in the Slack channel.

There is no release date for the app yet. The major piece of work remaining is reporting. There are some other smaller pieces of work like the recording of Faculty/Institute (today's topic). Will aim for release in Alana late November early December.

Homework - Recording faculty/institute for authors and requests

Owen outlined the idea in the document for recording faculty/institution. Will be able to have two related fields 
1. "Top level" - pick list. Values can be up to 255 chars
2. "Second level" - free text

Both fields would be optional on a "Person" record (but see later discussion) and exist separately on the Person and Request records.

Discussed the possibility of using a pick list in the second field, to help keep the data entered consistent, but this would then be too restrictive for some institutions.

The second field could make suggestions as the user types to help keep some control over the values entered into the field.

Owen demonstrated how the picklist values entered in the top level could represent more than one level in the hierarchy. 

The variation in organizational structure across institutions is evident in previous feedback from users. 

A nice-to-have requirement, possibly for the future, is for institutions to be able to create their own hierarchies to reflect their organizational structure. So that, for example, the information could be reused in local repositories.

Discussed  :- as well as being able to record the two level fields on a Person record it will be possible to add this information to the Request. The information will be copied and editable. The process will be:
1. Set Level 1 and 2 fields on the Person record
2. Create a Request
3. Lookup the person and attach to the request. 
This will copy the Level 1 and 2 fields onto the request, with the values copied from the Person record. 
4. Edit the two fields on the request. 

Now the values of these fields are different.

Does this make sense to users?
- Consensus is that this is the right approach.

Discussed whether it should be possible to record more than one set of Levels on the Request and/or on the Person records.
- Consensus is that it is not necessary on either record.

Discussed whether the First level field should be required or optional. 
- Consensus is that the first level should be mandatory.

Discussed whether the fields should only be present for a Corresponding author.
- The consensus is yes.

Owen mentioned that it might not be possible to make the first level field mandatory if the fields are only needed on the CA. To be discussed by the tech team.

Owen asked whether the Status field should be a bit cleverer than it is.
- Do we need a second field e.g. options to manage the reason for closure.

This will be discussed in a future session.

From the chat

Attendees