New Module Tech Evaluations: Technical evaluations will be divided into front end-focused and back end-focused to make it easier to evaluate. Jeremy Huff is clarifying language in the process documentation. He put in a PR for that.
Tech Eval Process subgroup: per Chulin Meng will recommend to TC to move forward with piloting the RFC process which the group feels is well-documented. Need guidance from the TC on which things to focus on in the details.
TC Goals/Objectives subgroup: per Radhakrishnan Gopalakrishnan the group is working on a vision statement within the group, and strategic objectives for the next 3-5 years.
Translation subgroup: not started yet.
Cross-Council Group for New Module Inclusion: per Marc Johnson the group has met; the next update will be on 3/23 after their next meeting.
In the PC meeting yesterday, we heard that there is a need for more/better onboarding information for developers. There was a question/suggestion that maybe TC would be able to help with that, maybe identify some people who could help pull together some onboarding. Is that something we would want to take up?
Documentation and training for new developers, such as the FOLIO developers in China and Alabama. PC/CC may need to allocate resource to do this. Tod Olson will bring our discussion back to PC/CC. Radhakrishnan Gopalakrishnan will assess the current situation of technical documentation.
It is intended to be an index / summary of useful resources that are already out there. The extant guide is incomplete and the good info is spread all over the place.
Marc Johnson asked whether this should belong in docs.folio.org. Also, it would be great if the documentation decisions are cohesive across the project to avoid redundancies and confusion. docs.folio.org is already 2-3 releases behind and that needs to be addressed.
VBar mentioned dev.folio.org as a possible home, since it is already targeted at developers.
Jakub Skoczen : the documentation will need an ongoing commitment to keep it updated. He echoed the sentiments of the others.
Zak Burke : it is difficult to manage the content of dev.folio.org, whose content lives on GitHub. Redundancy and confusion happens because some content is also on the wiki. The project needs a coordinated plan.
Ian Walls : the documentation contributors are working to get documentation caught up to the Lotus release. An alternative could be to roll the Dev site into the Docs site, or at least have Dev managed by the Docs group. He confirmed that the documenting group is focused on docs.folio.org as end-user documentation, and Dev is not currently on their radar.
Marc Johnson : lots of dev teams don't use the Dev documentation site. Other teams have contributed various content to various places.
Jakub Skoczen : preference to adopt the wiki since it is easier to work with than Jekyll and GitHub for many contributors. But prevent having multiple places for the same information. Should there be a working group?
Zak Burke : we need a home for automatically-generated documentation which currently goes to GitHub.
Tod Olson : a deliberate information architecture for the documentation is paramount, regardless of the tools or locations. The information needs to be findable and maintained. Ian Walls seconded that.
Overall agreement that the work is beneficial. TC will need to decide where it lives and how to keep it updated.
There seems to be some inconsistency across UI plugins/modules wrt declaration of okapi interface dependencies. Is it the responsibility of the plugin to declare these, or the "hosting" UI module?
Discuss possible next steps:
Ask the Stripes Architecture group to make a decision – I think they've made decisions like this in the past.
Ask the Stripes Architecture group to advise the TC on this, who will then make a decision – only necessary if the Stripes Arch. group doesn't think they have the authority to make the call
Get an overview from a representative of the Stripes Architecture group (e.g. Zak Burke) and have the TC make a decision