Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

...

TimeItemWhoNotes
1 minScribeAll

 Ingolf Kuss is next, followed by Maccabee Levine 

Reminder:  Please copy/paste the Zoom chat into the notes.  If you miss it, this is saved along with the meeting recording, but having it here has benefits. 

*TCR Process ImprovementsAll

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

  • 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 templateMake the changes and then accept the PR.

-------------------------------------

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.


NAZoom Chat


...