Historical Sub Groups

Tod Olson 

Ingolf Kuss 

Craig McNally 

VBar 

Jeremy Huff

• An RFC is created and taken through at the DRAFT REFINEMENT stage.
• Eventually, a DR is created

Mike Taylor 

Julian Ladisch 

Olamide Kolawole 

Jeremy Huff

Matt Weaver

Ingolf Kuss

Mike Taylor

Julian Ladisch

1. Gather thoughts on areas that can be improved
1. Via a retrospective
2. Ensure that multiple perspectives are included, submitters and reviewers
2. Align the template and the acceptance criteria
3. Make clarifications to the process and acceptance criteria
4. Ensure the rationale behind the TCR process has been effectively communicated
5. Investigate:
1. Is the criteria too exclusive?
2. Is the process, either in design or implementation, transparent and communicative enough?
3. Does this process allow for communication with all appropriate stakeholders?
4. Is the process sufficiently collaborative? Is it too oppositional?

Deliverables:

• Updated process documentation
• Updated acceptance criteria
• Updated review template

• Processes Documentation Update
• Criteria Updates
• Process Update Video

Goals:

• Clarify what constitutes a "breaking change"
  
  • At the module level
  • At the interface level
  • etc.
• Clarify if breaking changes can be "batched" into a single version bump.
• Figure out how operational changes and breaking changes are communicated... via semver?  release notes?  both?  something else?

Deliverables:

• RFC
• ADR

• 0003-folio-breaking-changes rfc
• DR-000036 - Breaking Changes

To draft acceptance criterion and define the technical evaluation process for FOLIO applications 

LTR document: https://docs.google.com/document/d/1Un5OlutEh7M2p3AzxE8g20NmdeEhrC0KCNkfd_QLkRw/edit

FOLIO is not ready for a long-term release point because libraries are actively installing each new release to get needed functionality.  The recommendation of the task group was to revisit the decision at the end of calendar 2022.  The document linked above contains recommendations for PC to endorse regarding back-porting of functional and security fixes until a long-term release is established.

No objections from Product Council on adopting these recommendations.

• Officially Supported Technologies
• https://github.com/folio-org/tech-council/blob/master/MODULE_ACCEPTANCE_CRITERIA.MD (updated)
• https://github.com/folio-org/tech-council/blob/master/NEW_MODULE_TECH_EVAL.MD (updated)

FOLIO Scope Criteria (cross council)

Cross-council group for new module inclusion process

Whilst this group is not a sub-group of the TC, it is here to remind us to talk about it during the regular TC meetings.

• determine sustainable and trustworthy process to evaluate functional criteria for accepting new apps/modules into FOLIO
• Should complement the technical criteria developed by TC
• Define acceptance criteria for new code to be added:
  • Consistent with community goals
  • Provides desired functionality
  • Will be appropriately supported

See Product Council Sub Groups.

Deliverables:

• Decision on where the onboarding documentation lives (docs site, dev site, wiki, etc.)
• A plan for keeping this up to date.

• FOLIO - Developer Onboarding Index
• The plan for keeping the document up-to-date is to review the page on a periodic basis (frequency TBD)

Goals:

• Review the action items identified during the ADR retrospective and make the necessary process improvements

Deliverables:

• Updated documentation, templates, etc.

• Decision Records
• Migrated decisions from DD space
• Renamed ADR → DR
• Improved / clarified process, template, organization of the decisions, etc.

Goals:

• Identify inaccuracies/discrepancies in the document as it currently stands (in particular in light of the Governance changes)
• Identify gaps and/or improvements 

Deliverables:

• Draft revision of the TC charter for review by the rest of the group

From: RFC Process

• A subgroup is formed (must-have community/TC members who are experts in the area addressed by the RFC)
• The subgroup works with the submitter to refine the RFC by providing feedback
• The submitter will be responsible for resolving all the conversations in the PR
• TC will review the draft when it is ready
• Any member of the TC will merge the PR in its current state to advance the PR to the next stage after ensuring that all conversations have been marked as resolved
• TC votes to advance the RFC to the next stage

RFC moved to the next phase (Public Review)

Communication to the community that the RFC is ready for public review and feedback. 

See:  #public-review-rfc-kafka-partitions

Scope:

• Gather feedback, e.g. from recently onboarded developers
• Ask the Documentation SIG if they'd like to be involved

Deliverables:

• Feedback is gathered and shared

Scope:

• Work with the submitter of the Java 17 RFC to refine and provide feedback

See https://github.com/folio-org/rfcs/pull/9/files

Another iteration of TCR process improvements

• Consider the items listed in recent TCRs under "TCR Process Improvements".
• Consider other feedback provided by recent TCR submitters.
• Consider process issues raised at TC meetings (hopefully in the minutes) during our recent TCR discussions.  This would include "meta-process" issues such as communication around the TCR process, timing issues, interaction with the RFC process, etc.
  • Scope includes the deeper issues raised during recent TCRs about the effectiveness of the current process, criteria for failure, etc.

Jenn Colt 

Craig McNally (part time)

Tod Olson (part time)