2022-03-09 Meeting notes

Owned by Craig McNally
Last updated: Mar 30, 2022

Date

Attendees 

Discussion items

TimeItemWhoNotes
1 minScribeAll

Philip Robinson is next, followed by Jakub Skoczen 

5 min

Review outstanding action itemsAll

Check-in on Zak Burke 's identification of categories of TC decisions.

10-15 minTCR Board Review

All

Approved TCR-12 (Technical Evaluation of ui-marc-authorities).
10-15 min

Technical Council Sub Groups Updates

All


  • New Module Tech Evaluations: Technical evaluations will be divided into front end-focused and back end-focused to make it easier to evaluate. Jeremy Huff  is clarifying language in the process documentation. He put in a PR for that.
  • Tech Eval Process subgroup: per Chulin Meng will recommend to TC to move forward with piloting the RFC process which the group feels is well-documented. Need guidance from the TC on which things to focus on in the details.
  • TC Goals/Objectives subgroup: per Radhakrishnan Gopalakrishnan the group is working on a vision statement within the group, and strategic objectives for the next 3-5 years.
  • Translation subgroup: not started yet.
  • Cross-Council Group for New Module Inclusion: per Marc Johnson  the group has met; the next update will be on 3/23 after their next meeting.
  • Controlling AWS Hosting Costs: 
10-15 minTechnical Decision Making ProposalChulin Meng 

Subgroup to present their proposal:  Technical Evaluation Process Sub Group and discuss next steps/goals.

  • Chulin Meng led a review of the recommendations and notes from the group so far. 
  • The group suggested 3 items it can specifically work on.
    • Pilot RFC process
      • Example: ask stakeholders to submit a formal RFC
      • Radhakrishnan Gopalakrishnan : cross-app data synchronization with Raman Auramau  could be a possibility, though need a bit more time to engage. Marc Johnson : the team will probably need 3 weeks. 
      • Craig McNally suggested Kafka as part of the FOLIO infrastructure, or other lingering topics if cross-app data sync isn't ready
      • Jeremy Huff may interested in running a proposal to use spring-way in lieu of spring-module-core through the RFC process
      • Radhakrishnan Gopalakrishnan Open telemetry could also be a topic but would need to be verified
    • Define substantial change categories
    • Tools for providing feedback before formal process
      • Jeremy Huff : the subgroup may want to consider which processes it can take on itself vs. which ones could go to other members of the community
      • Chulin Meng : given an RFC example may take some time, the subgroup could work on the feedback tools options in advance of the RFC work.
5-10 minNew Developer Onboarding

Tod Olson 

Radhakrishnan Gopalakrishnan 

Previous Notes:

From Tod:

In the PC meeting yesterday, we heard that there is a need for more/better onboarding information for developers. There was a question/suggestion that maybe TC would be able to help with that, maybe identify some people who could help pull together some onboarding. Is that something we would want to take up?

Documentation and training for new developers, such as the FOLIO developers in China and Alabama. PC/CC may need to allocate resource to do this. Tod Olson will bring our discussion back to PC/CC. Radhakrishnan Gopalakrishnan will assess the current situation of technical documentation.

Today:

  • Review where this stands and next steps
  • Radhakrishnan Gopalakrishnan shared the screen to talk through his draft: FOLIO - Developer Onboarding Index
    • It is intended to be an index / summary of useful resources that are already out there. The extant guide is incomplete and the good info is spread all over the place.
    • Marc Johnson asked whether this should belong in docs.folio.org. Also, it would be great if the documentation decisions are cohesive across the project to avoid redundancies and confusion. docs.folio.org is already 2-3 releases behind and that needs to be addressed.
    • VBar mentioned dev.folio.org as a possible home, since it is already targeted at developers.
    • Jakub Skoczen : the documentation will need an ongoing commitment to keep it updated. He echoed the sentiments of the others.
    • Zak Burke : it is difficult to manage the content of dev.folio.org, whose content lives on GitHub. Redundancy and confusion happens because some content is also on the wiki. The project needs a coordinated plan.
    • Ian Walls : the documentation contributors are working to get documentation caught up to the Lotus release. An alternative could be to roll the Dev site into the Docs site, or at least have Dev managed by the Docs group. He confirmed that the documenting group is focused on docs.folio.org as end-user documentation, and Dev is not currently on their radar.
    • Radhakrishnan Gopalakrishnan asked who maintains the Dev docu? Jakub Skoczen David Crossley does updates, so maybe reach out to David.
    • Julian Ladisch noted a contributors' site for dev.folio.org : https://github.com/folio-org/folio-org.github.io/graphs/contributors 
    • Marc Johnson : lots of dev teams don't use the Dev documentation site. Other teams have contributed various content to various places.
    • Jakub Skoczen : preference to adopt the wiki since it is easier to work with than Jekyll and GitHub for many contributors. But prevent having multiple places for the same information. Should there be a working group?
    • Zak Burke : we need a home for automatically-generated documentation which currently goes to GitHub.
    • Tod Olson : a deliberate information architecture for the documentation is paramount, regardless of the tools or locations. The information needs to be findable and maintained. Ian Walls seconded that.
    • Overall agreement that the work is beneficial. TC will need to decide where it lives and how to keep it updated.
    • Radhakrishnan Gopalakrishnan plans to wrap up his draft by next week.
    • We may want to form a working group, with Vijay's work as a prototype.


5-10 minUI Plugin Dependency Declarations

Zak Burke / Marc Johnson 

Overview:

There seems to be some inconsistency across UI plugins/modules wrt declaration of okapi interface dependencies.  Is it the responsibility of the plugin to declare these, or the "hosting" UI module?  

Discuss possible next steps: 

  • Ask the Stripes Architecture group to make a decision – I think they've made decisions like this in the past.
  • Ask the Stripes Architecture group to advise the TC on this, who will then make a decision – only necessary if the Stripes Arch. group doesn't think they have the authority to make the call
  • Get an overview from a representative of the Stripes Architecture group (e.g. Zak Burke) and have the TC make a decision

Zak Burke plans to raise the topic at the Stripes Architecture group meeting tomorrow. 

Action items

  • Zak Burke will raise the UI Plugin Dependency Declarations topic at the Stripes Architecture group meeting 3/9 and report back.