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
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
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
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
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)
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