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 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 referring to the release of Stripes; the "latest release of Stripes" might be too old.
- 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. .. Probably outside the scope of this group's work.
- Criteria can not be overridden. All boxes need to be checked.
- These changes are not controversial at all.
- Having more formal options is good.
- What happens after the deferral ? (PC needs to be involved in the decision)
- After provisonal acceptence, we agree upon a time line.
- Not a blocking issue.
- "active" vs. "accepted" OSTs. Should we only target "accepted" ? You can't apply ... because the Development Freeze happens after the submittance to the TC.
- if we keep "active" and "accepted" we need some guidance. There is more than one "active" and "accepted". → use the one which is tied to the target release.
- Modules which use the wrong version of Stripes will not make it into the Release.
- The language needs to include "the target release".
- Make the changes and then accept the PR.
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.
|