2022-04-13 Meeting notes

Date

13 Apr 2022

Attendees

Discussion items

Time	Item	Who	Notes
1 min	Scribe	All	Marc Johnson
5 min	Review outstanding action items	All	Zak Burke reported that the RFC(s) for internationalization is in progress (action marked as complete) Zak Burke checked the existing Stripes documentation and it states that all modules should describe their interface dependencies. This covers plugins because plugins are modules. And suggests it could be more useful for us to spend our time checking whether modules are compliant Zak Burke will check each of the (dozen or so) plugins for interface dependencies
10-15 min	TCR Board Review	All
10-15 min	Technical Council Sub Groups Updates	All	Chulin Meng reminds the TC that the Technical Evaluation Process Subgroup is not only about the internationalization RFC(s), it is about how the general process provides folks with feedback. Although it is important that the internationalization RFC(s) provide a good example Marc Johnson asked what this means in practice? Chulin Meng The internationalization RFC(s) should not be about the specific approval of that and more about what we can learn about the process. That the TC is about helping rather than as a gatekeeper. And more broadly, how it can help librarians and developers work more closely together Marc Johnson suggested that he didn't understand how the RFC process will help developers and librarians working more closely together Zak Burke suggested that the RFC should be more about consensus building (around how to technically provide the feature) rather than approval Craig McNally raised concerns that this relies on features proposals not already including technical details Ian Walls suggests that the PC is responsible for defining the features they want and the TC should be responsible for how the feature should work technically Radhakrishnan Gopalakrishnan states that we want the community to contribute more, thus we want to guide RFC towards being more likely to achieve success Marc Johnson asked whether the sub-group has provided that feedback on the RFC? Radhakrishnan Gopalakrishnan advised that the sub-group does not have the technical understanding to provide feedback on the current direction of the RFC Craig McNally suggested that we need to separate feedback on the process and feedback on the RFC specifics Radhakrishnan Gopalakrishnan suggested that the process does not allow for intermediate / early feedback Craig McNally suggests that this suggests that there is gap in the process and the sub-group could use that feedback to change the RFC process proposal Jeremy Huff suggested that we discussed an iterative process based upon the pull request process Craig McNally suggested that we may need to iterative on the initial scope of the RFC Jeremy Huff suggested that the first draft pull request could be the opportunity to provide that scope feedback Radhakrishnan Gopalakrishnan provided an example of how we pass the accept-language header through the sequence of API requests. And suggested options about how to achieve that within the module implementation. And that requires work to explore the options Marc Johnson suggested that this example could be great for the sub-group to think about an Radhakrishnan Gopalakrishnan suggests that this really needs to be implementable by the developers, otherwise we get variation in implementations, which is undesirable Craig McNally suggested that this comes back to the applicability of the RFC process to different technical decisions e.g. the architectural decision vs. the implementation decision Jeremy Huff acknowledged that consistency of implementation is important, yet we also need to leave folks a degree of implementation flexibility e.g. RMB / vert.x vs. Spring Way. And that the granularity of an RFC should be at the protocol level Ian Walls suggested that a module should be considered a black box, and that as long as it responds properly it should be acceptable. This should be separate to the challenge of protecting the existing teams from picking up maintenance for modules that they are unfamiliar with the tooling for. Peter Murray advised that he has refined the AWS costs management scope based upon Marc Johnson comments
5-10 min	WOLF Con Planning	Philip Robinson / All	Craig McNally asked how we want to address the feedback provided on Slack since the last meeting? Philip Robinson stated that he was going to take this feedback into the next planning meeting. And that the owner of the session does not necessarily need to be at WOLFCon itself and might not be the facilitator. Jeremy Huff Thinks that the jq and new module workshops can be coordinated by the TC, yet run by a developer. He would like to be involved in the blueprint meeting, yet are unsure as to whether he will be there in person. And that Zak Burke pointed out that planning is affected by upcoming TC elections. Tod Olson is interested in the architectural blueprint and technical debt sessions, however is unsure they can volunteer. He suggested that the facilitator does not Mark Veksler suggested that he is surprised that there is no session about release testing (manual, automated, performance and upgrade) Craig McNally will reach out to Anton Emelianov (Deactivated) for his thought on WOLFCon testing sessions Marc Johnson asked which parts of testing would the TC be responsible for? Craig McNally suggested we defer that till after talking to Anton Mark Veksler suggested that the TC might be interested in the impact on environments on performance testing and other topics
5 min	Updates from PC and CC?	Tod Olson Jeremy Huff Marc Johnson	Jeremy Huff suggested that he won't be available to attend the Community Council (CC) Marc Johnson will attend the next CC meeting after Easter. Ian Walls confirmed that will be the week after next Tod Olson advised that the Product Council (PC) won't be meeting for the next couple of weeks

Action Items

Zak Burke will check each of the (dozen or so) plugins for interface dependencies
Technical decision making process sub-group to discuss the feedback from Radhakrishnan Gopalakrishnan about needing early feedback about the scope of RFCs
Craig McNally will reach out to Anton Emelianov (Deactivated) for his thought on WOLFCon testing sessions