@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
@Vijay 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?
@Vijay 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
@Vijay 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
@Vijay 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
@Vijay 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