| Group Name | Purpose | Date Started | Date Concluded | Owner | Members | Slack | Deliverables |
|---|
| Improve the TCR Process | - Gather thoughts on areas that can be improved
- Via a retrospective
- Ensure that multiple perspectives are included, submitters and reviewers
- Align the template and the acceptance criteria
- Make clarifications to the process and acceptance criteria
- Ensure the rationale behind the TCR process has been effectively communicated
- Investigate:
- Is the criteria too exclusive?
- Is the process, either in design or implementation, transparent and communicative enough?
- Does this process allow for communication with all appropriate stakeholders?
- Is the process sufficiently collaborative? Is it too oppositional?
Deliverables: - Updated process documentation
- Updated acceptance criteria
- Updated review template
| | | Jeremy Huff | Zak Burke Craig McNally Florian Gleixner Jenn Colt Marc Johnson | #module-tech-eval-subgroup | |
| Breaking Changes | 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: | | | | | #tc-breaking-changes | |
| Technical Evaluation Process Subgroup | Come up with one ore more proposals for a technical evaluation process and bring these proposals to the TC for review. They may borrow parts of the RFC process, etc. Here's a document outlining what the process is trying to achieve: https://docs.google.com/document/d/1UIahG77mreqTnnBN09Zpso5h4v2ZZxAOpgIZgqqqQOo/edit?usp=sharing See 2022-01-05 Meeting notes and previous meeting notes for additional context. | | | | | | Evaluation Process |
| Application Technical Evaluation Subgroup | To draft acceptance criterion and define the technical evaluation process for FOLIO applications | 2021-08-25 | | | | | See New Module Technical Evaluations |
| LTS / Versioning Subgroup | Mike Gorrell / Steffen Köhler to organize a community stance relative to the first LTS. Results of our effort were documented in product council Product Council Minutes: 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. | | January 27, 2022 |
| |
| See LTR document: | Widget Connector |
|---|
| url | https://docs.google.com/document/d/1Un5OlutEh7M2p3AzxE8g20NmdeEhrC0KCNkfd_QLkRw/edit |
|---|
|
|
| New Module Tech Evaluation (Revisions after last batch of evaluations) | - Refine the Acceptance criteria based on the feedback from retrospective (and other feedback)
- Update language to be consistent.
- Update tech eval. process to be clear about who should be creating the TCR issues.
- Provide an update to the three councils on the state of these processes (once the previous goals are completed)
| | | | | New Module Technical Evaluations | |
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. | | | | | NA | WOLFcon presentation (link TBD) which led to a lot of discussion and eventually the dissolution of the group. |
| Technical Documentation / New Developer Onboarding | Deliverables: - Decision on where the onboarding documentation lives (docs site, dev site, wiki, etc.)
- A plan for keeping this up to date.
| | | Radhakrishnan Gopalakrishnan | | NA | |
| DR process improvements | Goals: - Review the action items identified during the ADR retrospective and make the necessary process improvements
Deliverables: - Updated documentation, templates, etc.
| | | | | NA | - Decision Records
- Migrated decisions from DD space
- Renamed ADR → DR
- Improved / clarified process, template, organization of the decisions, etc.
|
| Tech Council Charter Revisions | 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
| | | | | NA | An updated, TC charter with formal approval from CC |
| Kafka Partitions RFC | 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
| | | | | NA | 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 |
| Technical Council Goals/Objectives | - Further refine the Technical Council Goals & Objectives - DRAFT document into a concise set of TC goals, initiatives, and objectives.
- Have the necessary discussions about the topics where questions were raised
- Incorporate additional elements from the Architectural Blueprint, and other places
Deliverable: - Goals, objectives, and initiatives are captured on the wiki - broken down by short/mid/long, or by quarter, or ...?
| | | Tod Olson | | NA | FOLIO Project Technical Objectives & Initiatives |
| Translations Subgroup | Describe an approach for back-end modules to handle translation of runtime values, i.e. values attached to UUIDs and persisted in storage. This may include evaluation of TCR-9, or an RFC describing that or approach or an alternative. | | | Zak Burke | | NA |
|
| Onboarding Documentation | 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
| | | Maccabee Levine |
| NA | https://folio-project.slack.com/archives/CAQ7L02PP/p1682943495526129 |
| Java 17 RFC | 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 | | NA | | | NA | This subgroup was formed to shepherd the Java 17 RFC through completion. However, the decision was made that the RFC process was too heavy weight for this. Instead a discussion was held by the TC and a decision was made & recording in the decision log. See DR-000034 - Java 17 Support |