• Timeline 
    • What is the proposed timeline to complete? 
      • Tentative: August 22nd (MG release - public) 
      • Need to inform developers, etc. 
  • Team - Recommendations on where team members should be assigned 
    • BE: TAMU (dev) [MJ's recommendation: core-platform] , Kyle (GVSU) [Vega with focus patron/rtac?]
    • FE: Michal (recommend Sif to focus on boundwidths for Nolana/Orchid but will continue to work on stripes related.) 
      • Address boundwidths 
      • Address ui-inventory/ui-users issues 
    • Dev lead:  MarcJ - TBD 
    • POs: Charlotte/Patty/KG - 
  • Is there a list of backlog of user stories/defects
  • Is there a list of features 
  • Any critical features/work needed or underway? 
  • What is the availability of Charlotte and Marc to help teams with knowledge sharing [MarcJ will allocate time.]
  • Morning Glory hotfix handling - Can Prokopovych development be available to address hotfix issues?  [MarcJ will allocate time.]
  • A list of Proposed Nolana features (Inventory) - Prokopovych:
  • A list of Proposed Nolana features (non-Inventory) - Prokopovych:
  • Nolana release support: Should we consider that current team members are responsible or help with releasing modules? [MarcJ will allocate time.]
  • Test cases reassignment
  • RTL/JEST
  • Karate
  • e2e 
Backend modulesThoughts regarding on team to reassign 
mod-usersVery few recent changes.  Core-platform / Thor? Most recent changes made by Julian and ID folks.
mod-users-bl

Should likely go with mod-users, assuming we want vertical alignment (without, more coordination is needed).

Much recent development is being made by Steve in the Core Platform team relating to login. I don't know if Steve might be moving teams. He is also likely to make more changes relating to shrinking the minimal platform.

(arguably should eventually be merged with mod-users now folks don't seem to support the storage / business logic split anymore)

mod-inventory

Has responsibilities that cross boundaries: inventory and data import.

Data import makes up much of the code of the module and is a primary reason for change. This would suggest Folijet.

mod-inventory-storage

Could go with mod-inventory (to keep vertical alignment), although this is hard due to the responsibilities 

Otherwise, probably Core Platform as they made most of the recent changes.

mod-rtac/edge-rtac

EBSCO built these and were only recently inherited by Prokopovych.

Vega?

mod-patron/edge-patron

EBSCO built these and were only recently inherited by Prokopovych.

Vega?

mod-codex-inventory

Should go with mod-inventory-storage.

(Might be worth proposing deprecation, I don't know if Codex is used anymore)

Frontend modulesThoughts regarding on team to reassign 
ui-users

no obvious choices - Anna Melnyk worked on this and ui-inventory a bit. She is part of Vega

There is value in keeping these in a vertical with the back end, however that might be hard to achieve

The features in this module are somewhat split, it allows for searching and editing users, which is aligned with mod-users, however the presentation of permissions, loans, requests etc are all aligned with other teams

ui-inventory

no obvious choices, maybe Thor / SIF due to bound-withs etc. Anna Melnyk worked on both this and ui-users a bit. She is part of Vega

There is value in keeping these in a vertical with the back end, however that might be hard to achieve.

The features in this module are somewhat split between teams as it stands. Search is mostly dependent upon Spitfire (for mod-search), viewing and editing is Prokopovych and QuickMarc is another team

ui-plugin-create-inventory-recordsShould go with ui-inventory.
ui-service-pointsThis crosses boundaries again. Service points are implemented in inventory, and related to locations and users.
  • No labels

2 Comments

  1. Jakub Skoczen

    Khalilah Gambrell Marc Johnson CP cannot pick up modules from Prokopovych unless more developers are added to the team. Also, I think the table misrepresents the actual state of these repositories, e.g mod-users has many commits (https://github.com/folio-org/mod-users/commits/master) and these are not from CP.

  2. Marc Johnson

    Jakub Skoczen 

    CP cannot pick up modules from Prokopovych unless more developers are added to the team.

    This is a legitimate concern. It affects many of the potential teams taking over.

    There have been some conversations about one (or maybe both) of the back end developers from Prokopovych would move to the Core Platform team.

    At the moment, the Prokopovych team with 1.5 back end developers are responsible for 9 back end modules.

    I think the table misrepresents the actual state of these repositories, e.g mod-users has many commits (https://github.com/folio-org/mod-users/commits/master) and these are not from CP.

    There is every chance that these comments are a misrepresentation. My analysis of commits was fairly rough and based upon recent commits (recent differing depending upon volume per module). It was not based upon the proportion of overall commits or the percentage of code.

    Prokopovych already took on modules where it wasn't responsible for many of the commits / didn't write much of the code.

    Taking mod-users as an example, over the last two years, once the Prokopovych developers are taken out, Julian and Adam are the majority contributors to the module and no other teams are really represented.