Context/Background: From Maccabee Levine in #tc-internal: The TCR Process Improvements subgroup would like dibs on the Wednesday 1/31 meeting to discuss our draft PR and related recommendations. We'll share it with TC well before that so people can review async ahead of the meeting.
Pull Request: https://github.com/folio-org/tech-council/pull/55 Notes: comment thread only in one document
summary of the major changes new_module_tech_eval document - a new section "Before Development"
- supplemented by a communications plan
- a note about the itethe iterative nature; a positive process to make it easier
- after the evaluation, the rest of the TC members need to approve it. The evaluator makes a recommendation.
- a couple of options what the TC can do when not all criteria are met:
- if for architectural changes: make an RFC first → deferring
- minor things, not controversial → provisionally accepted
- criterion is wrong, TC needs to update the criteria
criteria document - general scope expanded from "just new modules" to also "existing modules"
- some criteria might not extend to existing modules
- criteria also apply for frontend shared libraries, backend also for edge modules.
- allowing for sonar cube exceptions
template document - refering to the release of Stripes
- a new section of criteria: "administrative" : Listed by the Product Council. ... owners must submit to the PC , while TC evaluates
- a naming conventions template
------------------------------------- Discussion: - define what is "controversial" → TC and submitter unanimously agree
- the process is a chain in which the TC has gone last. The PC also has to approve it. There does not need to be a sequence. Both things need to be done.
Presenter notes:
Input from: - many comments from Matt Weaver after the lists round of TCRs - many discussions since at TC - Jenn, Tod, Craig and Maccabee on the subgroup Summary of the PR: - lots of big stuff and little stuff - criteria and template are parallel docs. tried to make the change in both places but have the comment thread only in one. not consistent on which. - work planned after PR, i.e. to wiki pages. listed on subgroup page Today: - summarize major changes ~ 10-15m - discuss whatever - if there is time, talk through smaller changes - see where we are at the end of the hour Eval doc:
- Before Development section. read criteria first. do a RFC if needed. comm plan in progress. - iteration encouraged. - keeping separation between objective evaluation results, and TC decision. evaluator in practice can recommend a decision but that's separate from the evaluation. - Adding two alternatives to rejection - deferral, if major changes needed, i.e. RFC. - provisional acceptance, if TC and submitter unanimously agree on changes to resolve any failures, with timeline. for really obvious stuff that should not hold up acceptance. - acceptance, if the problem is ours. - justification required Criteria doc:
- existing modules incoprorated. no process defined for that, intentionally. didn't want to get ahead of formalization. follow-up work to determine if all criteria are relevent or not. - FE criteria apply to shared libraries also. - BE criteria apply to shared backend libraries and edge modules also. - allowing sonarqube exceptions if they are justified - Administrative section -- criteria that PC has approved. allow us to work in parallel if we want to, but prevent TC approval if PC is still in progress. Template doc:
- refer to Stripes version on OST page as ACTIVE or ACCEPTED - reference to naming conventions document. may take extra work to update that doc.
|