Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

Attendees

Discussion items

TimeItemWhoNotes
1 minScribeAll

Marc Johnson is next in the list, followed by Steffen Köhler 

5 min

Review outstanding action itemsAll

No changes from last meeting

5-10 minGoogle developer documentation style guideAll

From Jenn Colt :

Hi tech council - I would like to request that the inclusive documentation guidelines from the Google developer documentation style guide be followed as part of writing documentation on the FOLIO wiki. (link: https://developers.google.com/style/inclusive-documentation?hl=en )This style guide is what is used for the FOLIO docs site, but the FOLIO wiki is a very public, visible representation of the project and its values, and it is referenced much more than the docs site right now. Adding a link to the inclusive guidelines to the onboarding links could be a place to start.But the request is basically that these guidelines be a standard and that when documentation falls outside of these guidelines, requests for correction will be accepted and implemented. The assumption is that mistakes will be made but that these guidelines give us a goal to aim for. Thanks for your consideration. Let me know what else might need to be done to move this forward or to discuss it more.

Goal:  Make a formal decision on adopting the Google developer documentation style guide for all technical documentation in FOLIO, and clearly define the expectations.


Tod Olson suggested that there isn't anything surprising in it, Craig McNally  agreed that there isn't anything controversial.

Zak Burke  stated he is concerned that the guidance to offer multiple replacements for a term could dilute the specific meaning of the terms used. Craig McNally does not believe the investment in choosing specific words

Jeremy Huff Asked if this decision is specific to TC documentation or all technical documentation? And how would we approach compliance? Craig McNally  suggested that we would not actively monitor or check documents, rather we would provide feedback when examples of  are found. It is likely we are not in compliance with these guidelines.

Marc Johnson  raised that this is broader than the TC, and any decision we make might be superseded by broader documentation  Mike Gorrell  stated that this would be brought up to in the Community Council (CC) at their next meeting to decide on wider guidance.

Craig McNally asked if there is a TC to CC liaison? Mike Gorrell stated there wasn't and he intended to contact Craig McNally about it.

DECISION: (by lazy consensus), the TC has decided these documents should be used as guidance when writing technical documentation.

5-10 minTCR Board ReviewAll

Any new submissions?

No new submissions.

No documented progress on current submission. Craig McNally  will follow up with Mikhail Fokanov 

Zak Burke  asked about the status of the other planned modules for Kiwi / Lotus e.g. the translations modules? He raised concerns that modules might be getting lost in the gaps and folks might be surprised by the new process.

Craig McNally suggested it might be worth reaching out to folks, as it might prompt awareness to talk to the PC.

Marc Johnson  advised that Peter Murray is now sponsoring the translations work and that has been included in the conversations in the Product Council (PC) channel and folks are aware it needs to be evaluated. He also expressed concerns that the translations work may not fit into the module evaluation process and policy.

3 minCouncil Goals/ObjectivesAll

Previous notes:


5-10 min

New Module Technical Evaluation

Previously: "External Code Submissions"

Quick update from the sub-group?

Quick update from the cross-council group for defining the end-to-end process? 

  • No update yet, still organizing. Probably a few weeks before the first meeting.
  • Related: PC is sort of facing the same issue(s) that caused delay for TC .


Craig McNally asked if the cross-Council group had made any progress? Marc Johnson advised that a meeting has been arranged for Friday.

20 min (Depending on attendance)

Technical Decision Making Process

This is a carry-over from last week.

  • The tech leads group not being a decision making body
  • Whether it's realistic and/or desirable for the TC to make every technical decision
    • There was some overlap here with the external code submission topic

Additional Context: 

For Today:

  • We had homework to review Jakub Skoczen's document and provide feedback/questions/comments.
    • Does the RFC proposal meet the purpose outlined here in this document?
    • Are there other proposals for a decision making process (maybe that borrow parts of the RFC process)?
  • Last time discussed:  "need some feedback, will come back next week".  Skipped last week due to low attendance.

Postponing, need more feedback on document.


Jeremy Huff  asked which decisions would be covered by this topic? Craig McNally agreed that a policy on which decisions fit into this process is an important part of this topic.


Jeremy Huff suggested that we form a working group to define more detail around this topic. Craig McNally  agreed that was a good idea or alternatively, we need other proposals


Tod Olson stated that he felt the RFC process is a good fit for our needs.


Zak Burke suggested it would be good to have a workflow for what kinds of decisions need which decision making process and guidelines for expectations around our decisions. Craig McNally agreed, and acknowledged that one of the challenges with each process is deciding on it's applicability


 Zak Burke volunteered to identify categories of decisions the TC makes and suggest applicable processes

20 min

(Depending on attendance)

Participation and Attendance ExpectationsAll
  • Low attendance/participation from some members is becoming concerning - it's probably worth aligning on expectations.  
  • Use of proxies?
  • How to handle low attendance
    • Cancel the meeting?
    • Still meet and make progress on things that don't require decisions to be made, e.g. review proposals and provide feedback, at least go through the usual updates
  • ...

Discussion:

  • Strong preferences for not cancelling meetings.
  • Comments in favor of leaning on proxies, but not too much.
    • Some projects (e.g. NPM) have minimal requirements for attendance, not clear we want to formalize this.
  • Need more participation outside of meeting, there is more to be done than 1 hour per week in meeting.
  • How to set expectations about participation?
    • Probably best to set vague expectations to promote useful participation.
    • Examples of participation might be useful
    • Setting metrics is probably neither practical nor has the right tone.
  • Baseline
    • Encouragement at all meetings is encouraged, and if cannot make a meeting send a proxy
    • Happy to use half-plus-one to make decisions, and lean on lazy consensus unless there is a call for a vote
    • Homework!
  • Ideas for broad expectations:


Craig McNally asked if the TC wants to review the state of the Architectural Blueprint work?

Tod Olson  suggested that we need to decide which work is important for us to track. It could either be the Architectural Blueprint, Tech Debt or another list

Craig McNally suggested it could be useful to track working groups, who the participants are and when they meet

Jeremy Huff agrees that a central location on the wiki for the current working groups and a regular agenda item for check ins with those groups

Craig McNally suggested that folks seem. to support having a list of working groups. He asked who would volunteer to put that together? Jeremy Huff volunteered to start the page

Marc Johnson suggested that the work that is important to us should be aligned with the strategic goals and objectives. Craig McNally agreed


Craig McNally asked what folks felt about monitoring attendance? Jeremy Huff suggests that the need to elect a proxy might be sufficient to encourage participation (to avoid the admin of finding a proxy)


Marc Johnson suggested that we are only considering the attendance part of the participation aspect, rather than active participation in the meeting.

Time permitting



  • Another meeting rules thing: should we have a formal policy/discussion about attendance, discussion, and decision making when attendance is low/less than half? 

Action items

  •  All TC members will review the Council Goals and Objectives document by next meeting
  •   Craig McNally will follow up with Mikhail Fokanov about the review of mod-inventory-update
  •  Jeremy Huff to set up a wiki page for tracking TC working groups
  •  Zak Burke will identify categories of decisions the TC makes and suggest applicable processes