Versions Compared

Old Version 8

changes.mady.by.user Maccabee Levine

Saved on

compared with

New Version Current

changes.mady.by.user Marc Johnson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Initial notes

...

TimeItemWhoNotes
1 minScribeAll

Marc Johnson is next, followed by Ingolf Kuss

Reminder:  Please copy/paste the Zoom chat into the notes.  If you miss it, this is saved along with the meeting recording, but having it here has benefits.

5-10 minLiaison Updates

Maccabee Levine

Tod Olson

Jakub Skoczen

Craig McNally

Jenn Colt 

  • CC: Maccabee Levine
    • Developer Advocate offer made.  CC figuring out hiring logistics.
    • Index Data's proposal for doing system administration and CI/CD work was approved, pending budget check.
    • PC 6-month review of functional evaluation process.  Re-raised request of MOU for module contributors defining their commitment to the module.
      • Jeremy Huff asked whether the module evaluation / compliance been considered for the MOU? Maccabee Levine advised that the CC conversation was short and he couldn't recall previous conversations about the topic
  • PC: Tod Olson
    • No PC meeting due to Tri-Council meeting, see 2024-03-07 Tri-Council Meeting notes.
    • Planning for a periodic (quarterly?) meeting at an Asia-and-Austrailia-friendly time in order to be more inclusive
      • Jeremy Huff asked if this is a topic the TC should consider? Craig McNally suggested we wait for how the PC experiment goes.
    RMS
      •  Maccabee Levine suggested there could be benefits from more involvement from those folks
  • RSMG Group: Jakub Skoczen 
    • Deferred to sub-group updates later
  • Security Team: Craig McNally 
  • Tri-council Application Formalization: Jenn Colt 
5 minUpcoming MeetingsAll
  •  - Proposal to RSMG for language in the release schedule template suggesting RFCs
  •  - Regular TC meeting
  •  - Dedicated Discussion - Topic TBD
  •  - Regular TC meeting
  •  - Dedicated Discussion - Topic TBD
  •  - Regular TC meeting
  •  - Dedicated Discussion - Topic TBD
10-15 min

Technical Council Sub Groups Updates

All

Quick updates only.  If we can't find volunteers for groups, we'll need to add the topic to our backlog and address it during dedicated discussion sessions.

Go Programming Language: Some comments from Julian Ladisch Jakub Skoczen advised that is in public review

Distributed vs. Centralized: Moved to Public review. Subgroup  Craig McNally advised that is  in public review and the subgroup should be closed

TCR Process Improvements:

and Jenn Colt will talk about suggestions for the release process at the next release stakeholder meeting. Subgroup can be wrapped up then.
  • advised that license evaluation is deferred to the next cycle of improvements
  • Maccabee Levine and Jenn Colt presented the topic of raising awareness of the RFCs, particularly in relation to module evaluations, to the RSMG this morning to
    • RSMG
    .  Many questions.  Main one was about timing, would the RFC be completed in time.  RSMG wanted specifics.
  • Proposal:

This is written as if an updated to the Quesnelia schedule just to understand the timeline, even though obviously we are not editing the Q schedule at this point.

Existing: 11 Mar 2024
Ramsons R2 2024 release scope refinement deadline
POs prepare list of UXPROD features aligned with Ramsons R2 2024 team capacity. PO present prepared scope at next PO Weekly meeting at <TBD>
Add four weeks later: 08 Apr 2024
Ramsons R2 2004 RFC Consideration
Consider whether Ramsons planned development will introduce any [architectural changes or other innovations](https://github.com/folio-org/tech-council/blob/master/NEW_MODULE_TECH_EVAL.MD#before-development) that might conflict with existing TCR criteria.  If so, contact #tech-council for a recommendation on whether to conduct an RFC.
Existing: 13 Sep 2024 (existing deadline)
Deadline for acceptance of new modules by Technical Council at Ramsons (R2 2024)
    • raised questions about whether an RFC would be required or not and the timescales for submission and were concerned about additional work
    • Jeremy Huff agreed with Maccabee Levine that there are challenges with conveying the TC's intent with these changes
10 minRFCs

All

  • Public Review
    • Application Formalization RFC
    • Go Programming Language for Backend Development RFC
    • Distributed vs Centralized Configuration RFC
    - is in public Review

RFC Process Improvements:

  • We need another RFC to update the metadata retroactively to reflect the new or adjusted statuses. - Jenn Colt
  • Craig McNally asked what other channels should these RFCs be announced in?
  • Maccabee Levine asked what the timing is for the next Application Formalization RFC? Craig McNally advised that further RFCs have been deferred due to capacity constraints within EBSCO
1 minDecision LogAll

Standing agenda item... is there anything in the decision log requiring attention? 

  • ...
30minTCR Board ReviewAll, Maccabee Levine and Ingolf Kuss

Owen Stephens remarked that he was expecting the evaluations to be considered next week

TCR-40 MOD-Serials Ingolf Kuss presented the evaluation, in particular these topics which are not expected to be resolved by next week:

  • Present Evaluation
    • Technical Council Review

    • Advised that K-Int has chosen integration instead of unit tests and those should be written in Karate / Cucumber
      • Jeremy Huff asked
        • if the TC are ok with integration tests being used instead of unit tests?
        • whether integration tests need to to provide coverage (if they are used instead of unit tests)?
        • whether the integration tests have to be written in an approved technology?
      • Marc Johnson suggested that there could be a misunderstanding of the language in the evaluation criteria. And that when K-Int folks refer to integration tests, they are referring to as tests that run inside the module build, however span a larger chunk of code than what some folks would refer to as unit tests. And advised that "unit" in the evaluation criteria means that the tests run within the module build
      • Owen Stephens asked what is the aim of the unit test criteria? And suggested the language (of unit vs. integration) can get in the way
      • Jeremy Huff advised that the style of the test is not an issue, if 80% coverage is achieved
      • Tod Olson suggested that the criteria could include the reasoning for why coverage is important, to aid future conversations like this
    • Advised that Sonar does not support Groovy, so Julian Ladisch applied alternative tools and found 3 vulnerabilities and over 3% code duplication
      • Jeremy Huff suggested that the TC could consider changing the criteria from specifically Sonar to more general static code analysis

    TCR-39 UI Serials management Maccabee Levine

    :
  • Present Evaluation
    • Technical Council Review

     presented the evaluation, in particular these topics:

    • There are some incompatible licenses related to shared code that this module uses. This is likely a topic that could be included in the next process improvement review
    • The development team are working on the following:
      • sonar checks (code smells and duplication)
      • test coverage
      • accessibility requirements
    Time Permitting

    Officially Supported Technologies (OST)

    		All

    Standing agenda item to review/discuss any requested or required changes to officially supported technology lists

    • Check in on progress... does anything else require attention?
    • Next Important Milestone:  Review Ramsons (1st party dependencies) and move from ACCEPTED → ACTIVE by   
      • Maybe we should aim to start looking at this on   so we have time for discussion/adjustments
    • Other todo items: 
      • Review policies and reasoning on page with intent to vote on approval (Sunflower)

    Today:

    On the Quesnelia OST Page:

    • Comment on Groovy2 Marc Johnson Groovy version depends on Grails. This combination is not possible. Grails 6 needs Groovy 3. Switch the OST Page to Groovy 3 or just remove the version.
      • Version removed and replaced with a comment suggested by Tod Olson
    • Comment on Folio-spring-base Version. Changed.

    Same changes done on Ramsons page.

    NAZoom Chat
    00:03:18	Jenn Colt:	I am the others…
00:03:31	Huff, Jeremy T:	Reacted to "I am the others…" with 😁
00:13:40	Jenn Colt:	Agree w/Tod. In slack there is evidence of need of this on this on the product side.
00:13:48	Huff, Jeremy T:	Reacted to "Agree w/Tod. In slac..." with 👍
00:15:38	Owen Stephens:	The PoC announced by Craig last week seems very wide ranging and tbh the application formalisation seems like not the most significant part of it?
00:15:56	Craig McNally:	That's accurate Owen
00:16:07	Owen Stephens:	Reacted to "That's accurate Owen" with 👌
00:16:13	Jenn Colt:	Yeah the tri council conversation is definitely more limited
00:16:19	Owen Stephens:	Reacted to "Yeah the tri council..." with 👍
00:16:51	Tod Olson:	And if we don't have a topic for this Wednesday, we can release the time.
00:23:14	Marc Johnson:	We have a hard threshold for the serials management evaluations

Please can anything else be deferred
00:26:47	Jenn Colt:	The RFC metadata is update, I will merge after this
00:27:13	Owen Stephens:	I was expecting this next week
00:27:25	Owen Stephens:	I have to admit
00:29:17	Ingolf Kuss:	isn't it the 15th officially ?
00:30:00	Marc Johnson:	Apologies, I forgot the threshold was after today
00:37:08	Owen Stephens:	I have discussed with the development team and I they have suggested some potential tools that could be used for Groovy on Grails applications: Jacoco + codenarc
00:38:51	Owen Stephens:	That is as an alternative to SonarQube
00:39:28	Ingolf Kuss:	agreed, Marc
00:40:10	Jakub Skoczen:	Putting the type of tests and verification tools aside, is the code coverage at 80% or more?
00:40:23	Huff, Jeremy T:	Reacted to "Putting the type of ..." with 👍
00:40:32	Ingolf Kuss:	Julian had used CodeNarc
00:40:36	Huff, Jeremy T:	Replying to "Putting the type of ..."

That is most likely the more important question
00:40:50	Jakub Skoczen:	Imho, this is the core criteria we should check
00:40:59	Tod Olson:	Reacted to "Putting the type of ..." with 👍
00:41:12	Owen Stephens:	That’s correct
00:41:37	Ingolf Kuss:	Replying to "Putting the type of ..."

I don't have a figure about the code coverage.
00:46:15	Marc Johnson:	There is nothing qualitative in our criteria about the size of chunk or diagnostic ability
00:50:44	Jakub Skoczen:	We can debate the 80% target but imo the benefit of having any target is that the code must be actually run in the CI. Of course higher the better


    Topic Backlog

    Decision Log ReviewAll

    Review decisions which are in progress.  Can any of them be accepted?  rejected?

    Translation SubgroupAllSince we're having trouble finding volunteers for a subgroup, maybe we can make progress during a dedicated discussion session?
    Communicating Breaking ChangesAllSince we're having trouble finding volunteers for a subgroup, maybe we can make progress during a dedicated discussion session?
    Officially Supported Technologies - UpkeepAll

    Previous Notes:

    • A workflow for these pages. When do they transition from one state to another. Do we even need statuses at all ?

    Stripes architecture group has some questions about the Poppy release.

    Zak: A handshake between developers, dev ops and the TC. Who makes that decision and how do we pass along that knowledge ? E.g. changes in Nodes and in the UI boxes. How to communicate this ? We have a large number of teams, all have to be aware of it.  TC should be alerted that changes are happening. We have a couple of dedicated channels for that. Most dev ops have subscribed to these channels. How can dev ops folk raise issues to the next level of community awareness ? There hasn't been a specific piece of TC to move that along.

    Craig: There is a fourth group, "Capacity Planning" or "Release Planning". Slack is the de facto communication channel.  There are no objections to using Slack. An example is the Java 17 RFC. 

    Craig: The TC gets it on the agenda and we will discuss it. The TC gets the final say.

    Marc Johnson: We shouldn’t use the DevOps Channel. The dev ops folks have made it clear that it should only be used for support requests made to them.

    Jakub: Our responsibility is to avoid piling up technical debt.

    Marc: Some set of people have to actually make the call. Who lowers the chequered flag ?

    Craig: It needs to ultimately come to the TC at least for awareness. There is a missing piece. Capacity Planning needs to provide input here. 

    Marc: Stakeholders / Capacity Planning could make that decision. Who makes the decision ? Is it the government or is it some parts of the body ?

    Marc: the developers community, the dev ops community and sys ops are involved. For example the Spring Framework discussion or the Java 17 discussion. But it was completely separate to the TC decision. It is a coordination and communication effort.

    Marc: Maybe the TC needs to let go that they are the decision makers so that they be a moderating group.

    Jakub: I agree with Marc. But we are not a system operating group. Dependency management should be in the responsibility of Release management. There are structures in the project for that.

    Jason Root: I agree with Jakub and with Marc also. Policies should drive operational/release/support aspects of Folio.

    Jason Root: If the idea of “support” is that frameworks are supported, then of course the project should meet that.

    Marc Johnson
    Some group needs to inform OleksAii when a relevant policy event occurs.
    These documents effectively ARE the manifestation of the policy.

    Craig: This is a topic for the next Monday session.

    Craig to see if Oleksii Petrenko could join us to discuss the process for updating the officially supported technologies lists.


    Dev Documentation VisibilityAll

    Possible topic/activity for a Wednesday session:


    Discuss/brainstorm:

    • Ideas for the type of developer-facing documentation we think would be most helpful for new developers
    • How we might bring existing documentation up to date and ensure it's consistent 
    • etc.

    ...