Page Comparison

5 min

Announcements

all

Council elections in June!

15 min

Introducing FOLIO Developer Advocate

Jeremy Huff Patrick Pace (Unlicensed) Alexis Manheim Kristin Martin

Patrick Pace was hired as the first FOLIO Developer Advocate and started in this new position on 4/15/24. Onboarding in progress with training/guidance from Jeremy Huff of the TC.
Welcome Patrick! The PC meets every Thursday at 10am EST. The council is 11 members. Everyone is welcome. PC deals with the FOLIO product, is responsible for the roadmap, review new incoming functionality being developed, and responsible for the SIGs. We coordinate SIG work, ask SIGs for monthly reports, and make sure SIGs are talking to each other and have their needs meet. SIGs typically work with a Product Owner rather than directly with developers.

Patrick started April 15 and has a list of tasks working on:

• Ingesting as much information on FOLIO as possible

• Reading documentation and documents to gain as much technical knowledge

• Reviewing slack channels, confluence spaces, issues

• Learning confluence and jira

• Trying to understand and develop the vision for the Developer Advocate position. What are the definitions of the position?

• Tested service boards that help keep track of issues

• Developing an index of documents that seem the most useful

• Weekly meetings with Jeremy and TC meetings

• Answered first developer adjacent question and interacted with one of the POs to get a through answer to go to the next steps. The person was hoping to send EDIFACT data to FOLIO.

• Thinking and taking notes on developer documentation cleanup

• Created a developer documentation subgroup

• Thinking about other roles such as mentoring for new developers and idea for a host team to help new development teams

Once certain decisions have been made, Jeremy Huff will announce this to the community. The developer documentation group will soon have its kickoff session. If you have a developer that can provide an information session for Patrick, please contact Jeremy Huff.

Development Documentation Working Group: The group has technical expertise and knowledge of FOLIO. This is a beneficial working group as it will consolidate documentation and enhance it. TC is a place to make decisions about this documentation. Would it be helpful to have visits to the teams to see how they are working? Will you look at docs.folio.org in addition to the wiki? Patrick will not focus on the docs.folio.org which is geared towards the end user. For complex documents on the wiki, this will be reviewed. Another area are the release notes for each flower. We strive to make these clear but it is difficult. These release notes are read carefully. Developers often read release notes for instructions.

30 min

Data in FOLIO Snapshot & FOLIO Snapshot-2

Charlotte Whitt Yogesh Kumar

More and varied data is needed in FOLIO Snapshot and FOLIO Snapshot-2 for early testing, pre-bugfest.

Link to slidedeck

Charlotte and Yogesh are here to discuss our sample data in FOLIO snapshot and snapshot-2. The idea is how can we as a community help to do better testing earlier. We need to add more realistic data that still allows the quick turnaround time to build or restart the environment. The goal is having a better quality data, with more data types, more newer functionality. The Product Owners can take the lead and SMEs will help.

People agree that having a larger more comprehensive set is helpful. Getting it from one library would help making connections. But how one library does something isn’t necessary what others do. There could be privacy concerns for certain types of data. Could we anonymize data? Kristin can take this back to Chicago IT to look at this. How big is too big too? A small set is needed for these environments so that these can be built quickly every 24 hours.

If we ask libraries to share data, then we can decide what data we need. SIGs and SMEs need to review the data rather than using the data as is. We need to make sure all use cases are being covered.

Would it be helpful to have SIGs and SMEs define what a good sample would look like? Then from this, definitions could be created and you can find the records. We need to get SIGs and SMEs input.

This could help improve with identifying bugs earlier for less CSPs.

Is there a way to make this data more plug and play? There are 2 sets of use cases. There are our new customers and having a place to test functionality. The other are upgrading to new flower release and can test snapshot for new functionality.

2 different tasks: There are the sample data. Then there is the action of setting up the reference environments. There needs to be a maintenance policy.

Would a sub group be appropriate? This might be appropriate for SMEs to come together.

Next steps:

Create a sub group for a short period of time or one that meets once or twice a year. Charlotte and Yogesh will put a call out.

5 min

Future topics

all