Tech Council Request/Backlog Page
This page is not being maintained and is not current.
This page lists the requests and/or items that the technical council is reviewing.
NEW REQUESTS may be added directly to the "Requested" table, or the requestor can ask via email to the council's mailing list. You can also reach out directly to members of the Tech Council.
Each inquiry should cover the following:
Item: In a very concise way, describe the problem that needs to be addressed.
Problem Statement/Background: Set context by describing the landscape surrounding the issue (history, technical components/versions, teams, etc.)
Interested Parties: Who will be impacted by a decision and if possible, what are their perspectives on this request.
Requested Action: What, specifically, are you asking the TC to do?
Current Items:
| Item | Problem Statement/Background | Interested Parties | Requested Action | Requested By | Request Date | Current Status | TC Lead |
|---|---|---|---|---|---|---|---|
| Definition of Done | A community project needs documented best practices and expectations, especially in the area of quality control. A clear definition of done (DoD) is an important artifact that individuals and teams can measure their progress against. We rely on shared commitment to quality and the open community | PC, TC, Community, Developers, QA, DevOps | Create a document. | TC | June 14, 2018 | As of 22-Feb-2019 - Draft exists. Several Teams have created their Definitions of Done. TC needs to review these and finalize its draft. Expect completion by June 30-2019 | Mark Veksler |
| Repo management | There are a few unmaintained or deprecated repos. Would like to regularly review and end of life those repos that are not longer maintained . Also, would like to ensure that every repo has at least one reviewer and their approval before a PR can be merged. | TC, Community |
| Mark Veksler | June 27, 2018 | Starting Review Peter to update this item with appropriate JIRA tickets. Still need to decide if #2 will be adopted/mandated. | |
| Edge APIs | The TC debated 2 approaches to APIs as outlined in these meeting minutes, and couldn't come to agreement on the long term direction. | TC, Community | Determine long term direction for Edge APIs and their interaction/reliance with Okapi | TC | January 23, 2019 | Need to determine when to discuss. To be Discussed at June '19 meeting | |
| AES/PubSub | This doc explains how these two message queue approaches relate. | TC, Community | Need to document discussion and decision for the community. | TC | 16-January-2018 | Mike Gorrell has action to write this up for TC Review/approval. Writeup to be delivered to TC by May 22, 2019. | |
| Security Audit | Based on the OTS Report and TC Analysis, the TC will define a scope for a security audit and solicit quotes from vendors. Once these quotes are available the FOLIO Stakeholders will be asked to fund the engagement that the TC recommends. | PC, TC, Community | Define scope, solicit quotes from vendors, make recommendation and get approval from FOLIO Stakeholders for a Security Audit for FOLIO. | TC | February 20, 2019 | Approval requested of FOLIO Stakeholders in April 2019. Expect response by May 22, 2019. | |
| Technical Debt | TC to compile an initial list of Technical Debt issues to be prioritized and scheduled alongside FOLIO feature work. TC to establish a regular cadence for compiling/reviewing this list - Annually? | PC, TC, Community | Refine this list, prioritize it and make recommendations to PC on how urgently items should be addressed. | TC | March 2019 | Jakub Skoczen committed to creating and structuring the list, to be discussed at TC May 15, 2019. Goal is to have list in shape for final discussions at June FOLIO Meetup. Will include process issues as part of Technical Debt. | |
| Code Reviews | Define who does Code Reviews, how do we set aside time to make sure they are done promptly, and what the code review should cover/entail. | PC, TC, Community | Create a document. | Marc Johnson | May 2019 | Starting investigation/discussions | |
| Preview Capability for PR's | As described in FOLIO-1933 - it is desirable to allow a PO or others review a feature/story before it's merged into the master branch. This requires several coordinated efforts. | PC, Community | Complete the several JIRA issues as described in the umbrella issue FOLIO-1933 | POs | May 2019 | Effort is ongoing. Expect progress in Q2 and Q3 2019 | |
| FOLIO integration with an orchestration toolset | Allow FOLIO to be deployed and administered using an orchestration toolset. | Community | Complete a list of items as described on this page: Folio integration with an orchestration toolset which will allow FOLIO to be deployed and administered using a set of tools that can be automated and well orchestrated. | Sys-Ops | May 2019 | Effort is ongoing. Expect progress in Q2 and Q3 | Jakub Skoczen |
Requested:
| Item | Problem Statement/Background | Interested Parties | Requested Action | Requested By | Request Date | Current Status |
|---|---|---|---|---|---|---|
| Stripes Testing | to be determined | June 24, 2018 | waiting more info | |||
| CI Builds: Travis vs Jenkins | to be determined | June 24, 2018 | waiting more info | |||
| JSON:API vs RAML | Some teams have introduced the usage of JSON:API (not RAML). Is that OK? | Mark Veksler | June 24, 2018 | Investigating request | ||
| API Changes can break dependent modules | Anton Emelianov (Deactivated)'s 3rd observation was that there is no mechanism in place to guarantee API contracts aren't broken during upgrades/new builds. | Community, TC, PC |
| July 18, 2018 | TC to discuss | |
| Policy making about providing descriptions in JSON and RAML | Data Migration has encountered the need for more documentation on fields in the storage modules, and would like a FOLIO data dictionary. Some modules already use the description fields in the JSON schema, but not all. This points to a larger need for consistent documentation of fields and APIs across the project. Related to OKAPI-241 Use description field in JSON schemas. Update (2018-08-29): Created FOLIO-1447. | Community, SysOps/Data Migration | Set policies about descriptions, or at least encourage teams to provide. | August 15, 2018 | Tod to create Jira Ticket - no other action required from TC. | |
| Handling automated reports of security vulnerabilities | GitHub sends automated security updates to repo admins when vulnerabilities are found. (See FOLIO-1580 - Getting issue details... STATUS for examples.) Should these be handled in a centralized way? Should we employ a tool like Snyk to support this? Is this part of Code Repository Management? | Set policy | Peter Murray | October 17, 2018 | ||
| Open Source License Compatibility Scanning | Set policy and integrate with CI | January 22, 2019 | ||||
Once the Tech Council reviews the request and has enough information, if it is accepted into its current backlog the item will be moved into the Current Items table. If for some reason the TC decides to not pursue the request the decision will be documented in the following table.
Prior/Completed Backlog:
| Item | Problem Statement/Background | Interested Parties | Requested Action | Original Request Date | Decision/Disposition | Completed Date |
|---|---|---|---|---|---|---|
| Establish process for engaging TC | The FOLIO community needs a method to engage the TC, make requests, solicit feedback, etc. | PC, Community | Create a process and document it. | June 14, 2018 | Page created. Wiki site updated. | July 9, 2018 |
| As the community evolves and other projects potentially start up, it makes sense to have a sturdy definition of what architectural aspects represent FOLIO's Platform, and which represent Core Applications. The Tech Council's role will (potentially) vary for each category, and new projects will benefit from clearly understanding what platform functionality exist and what functionality would need to be created as part of the application space. | PC, TC, Community, Future community members | Create a document. | TC | June 14, 2018 | July 18, 2018 | |
| Define an RFC Process | FOLIO needs a clearly defined RFC process that can be managed sustainably. To date key individuals and loose communication channels have been relied upon. As the project matures and the community grows, we need to establish formal processes. | PC, TC, Community | Create a document. | TC | June 14, 2018 | July 11, 2018 (pending publication of GitHub repository) |
| Path to a Workflow plan and estimates | The Product Council asked the TC to review the community's discussion and research related to Workflow and to propose a way to determine the level of resources and timeline required to enable a Workflow System for FOLIO. Our recommendation to launch a 3 sprint Proof Of Concept (PoC) was presented to the PC on 23-August-2018 and a decision will be made 30-August-2018. The PoC document is here. | PC, Community | Draft a Plan | 9-August-2018 | Document created | 23-August-2018 |
| Evaluate and improve on boarding documentation | We are expecting an increase in contributors to FOLIO and want to make sure there is solid documentation so that they can be effective with as little lead time as possible. | Community, new contributors, | Create a list of recommended changes/additions. Secondarily, make actual changes. | June 14, 2018 | Reviewed and updated Dev.folio.org | August 30, 2018 |
| Document the reporting architecture supported by FOLIO | The FOLIO Issue UXPROD-330 makes a statement that folio data and audit trail data will be fed to an external data lake and that Institutions will need to host own data lake and reporting/bi solution, but once they do, they will have access to all FOLIO data plus information about changes (e.g. who changed what and when). The TC should validate that this IS the design for the platform, and that the work that might need to be done to Okapi is understood and prioritized appropriately. Also, should Audit data be separated from Analytics data, and if so, how? | PC, TC, Community, Soon-to-be-active Developers | Document design pattern, decisions, work to be done and open issues around the Platform's reporting design. | 25 June 2018 | RFC Draft was created and debated. Generally a lack of engagement from TC Reviewers. Closing this item and will revisit the general issue in the future. | Closed (not completed) 22-Feb-2019 |
| UI Testing Spike | Review of the Stripes architecture | PC, TC, Community | Review of goals, current state, standards and processes around Stripes Architecture. | June 2018 | Frontside lead an investigation which resulted in several presentations to the TC and PC. In the end the Stripes Architecture team and now Stripes Force are addressing. See these meeting minutes for more details. | 22-February-2019 |
| Skills and Competencies Needs List. | As we review capacity plans and gaps, and as new organizations consider participating and contributing, it would help to have a list of the skills and competencies that are most in need. | Community, PC, TC | Create a document | July 2018 | Created: Technical Skills in Demand | 25-Oct-2018 |
| UI Testing Spike | Anton Emelianov (Deactivated)'s #1 observation was that there is a lack of guidelines related to UI Testing in the FOLIO project. This puts quality and productivity at risk. | Community, TC, PC | Assemble a task force to execute a spike to review testing tools, processes, etc. and to establish a set of guidelines. The outcome of this effort would be: - UI Testing Guide, including specific tools, that will enable different teams to follow best practices in building UI unit tests. | July 18, 2018 | Process and standards established and linked to on this space. | November 2018 |
| Release Planning Calendar | The community would benefit from a consolidated (quarterly) release planning calendar, outlining both dev/qa/deployment activities as well as future planning activities | Community | Create a document | August 29, 2018 | Release dates and processes continue to evolve. This page exists and links to current best set of dates. | Feb 2019 |
| UUIDs | The extensive debate in UIIN-369 - Getting issue details... STATUS and UXPROD-884 - Getting issue details... STATUS - to avoid having the UUIDs and HRIDs exist in a kind of limbo with an undefined relationship and individual users and developers using the willy-nilly, it would be good for the TC to clearly articulate best practices in the use and consumption of these IDs. Resolving the question of whether a HRID can be modified after the creation of an object is also important. At stake here is FOLIO’s ‘feel’ as a system with some consistency of behaviors and expectations across modules | PC, Community | Clearly articulate best practices in the use and consumption of these IDs. | January 2019 | TC facilitated discussion/debate and decision was made in a meeting on March 20th: Final decision was that FOLIO will standardize on HRIDs going into the 001 MARC field, and UUIDs will be going into a 9xx field. More details and actions/decisions to follow. This document details the implications/other decisions that were made | April 2019 |
| Insufficient build processes | Anton Emelianov (Deactivated)'s #2 observation was that the build process is immature and/or fragile. Issue was described in FOLIO-1266 - Getting issue details... STATUS FOLIO-1338 - Getting issue details... STATUS FOLIO-1043 - Getting issue details... STATUS | Community, TC, PC |
| July 2018 | Lots of progress made in this area incrementally over the months. | May 2019 |