Versions Compared

Old Version 8

changes.mady.by.user Benjamin Gross

Saved on

compared with

New Version Current

changes.mady.by.user Brian Lowe

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Paste notes

...

  1. Status of In-Review tickets

    Expand

    Jira
    serverDuraSpace JIRA
    jqlQueryfilter=14416
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


Notes

Dragan introducing himself as new tech lead!

  1. Further investigation of the mailing list issue
    1. schema.org missing authors?https://groups.google.com/g/vivo-tech/c/MAoUdgZYOwo/m/uPswpzD_AgAJ?utm_medium=email&utm_source=footer
  1. Still needs to be responded to.
  2. No new updates this week.
  • We should try to make time to investigate further.
  • Action item:  Benjamin Gross will respond to the email to solicit more details.  Doesn’t have an answer yet.
  1. The issue reported via Slack by Naveen Sadhu: "Hello..We use pypubmed harvester process to retrieve additional information for publications like subject areas, keywords. Recently we had issues : duplicate subject areas in our VIVO application. We are using pypubmed python script to check vivo(our app) data against pubmed central repository and add subjectareas if not available.  I did check python script that we are using and no issues there. Anyone faced similar issues before? Any help would be greatly appreciated."
    1. Team isn’t familiar with this particular tool.  Hard for us to respond to.  Benjamin has asked about which particular tool is being referred to in Slack.
  2. Small(er) development items for 1.13 (https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit?usp=sharing) vs decoupling UI (frontend) from backend 
    1. Dragan: Decoupling frontend from backend is important but risky and error-prone, especially because test coverage is lacking.  Moving to a new architecture will take time, and capacity is an issue.
      1. Decoupling is related to VIVO in a Box
      2. Also related to integrating Scholars Discovery into the core
      3. Request from Laurie Arp (LYRASIS) is to estimate the developer hours necessary.  Could investigate additional budget for hiring developers.
        1. DSpace has implemented front end in Angular, but took five years from original idea to production release.  Needed to hire some full-time developers to complete the project.
        2. Scholars Discovery took six months with two developers, but is read-only so less complex than a full VIVO.
        3. Should try to make an estimate that is no more than 50% off.  Will not be an easy task.
      4. William: hard to make an estimate without a scope of the decoupling.
        1. Dragan: REST API, Spring, Spring Boot.  Should try to implement React or something like that; no longer based on Freemarker.
          1. A lot of effort has been invested in the existing Freemarker UI, so could be tricky.
          2. Current university students are learning React and Angular, not things like Freemarker.
      5. Ralph: What about not using a framework?  Companies sometimes get tied into frameworks they don’t control when all they really needed was Javascript.
        1. William: this is part of the appeal of React, since it’s a library and not a framework.  But you still need to pick a templating engine.
        2. William: Angular rewrite forced everyone to rewrite their UIs; want to avoid something like that.  But also need to consider SEO.  With frameworks you can get server-side rendering out of the box.
          1. Ralph: server-side rendering is the way to go.
          2. William: Angular, React and Ember all provide for server-side rendering with Javascript is disabled.
      6. Huda:  Would be good to split the problem into two pieces.  Define a solid API for getting data out of the system.  Then decide front-end implementation.
        1. William agrees.
      7. Dragan:  Should look at the most stable solutions on the market and what libraries/frameworks other projects are using.  But we’ll need to accept that we won’t necessarily be able to make a perfect decision.
        1. Important topic for coming weeks.  Will start Google doc to summarize.
        2. Two options for proceeding: start new project and start replicating functionality, or fork existing code and modify it.
        3. Should also look at old, unused things that could possibly be removed.
        4. William:  are the reasoner, indexing, etc. still going to be part of the same application, or split into separate applications?
          1. Could simplify pulling out legacy/dead code or features that are no longer used.
          2. Dragan: I like idea of decomposing.  But could introduce performance challenges.  Should become more clear in the coming weeks.
        5. What will happen in the meantime?
          1. 1.13 (and maybe 1.14) should be released (with bug fixes / other improvements for the customer) while 2.0 is being developed.
          2. William: exposing a REST endpoint immediately gives benefits to the end user.  There’s more to sell in 2.0 than just better architecture / better maintainability.
          3. Dragan: If we outsource development, first phase might be just to rewrite existing application in new architecture.
          4. William: hard to think about trying to upgrade Vitro and VIVO to a modern architecture.  Rewrite would take less time than iterative upgrading.  But iterative upgrading might give you more intermediate releases with new functionality.
          5. Dragan will be looking for input from the developer group in shaping the Google doc / estimates.
          6. Benjamin: momentum is there for major changes.  Not sure if we’ve seen commitment to time/money from the institutions involved in leadership.
          7. William: VIVO in a Box has no interest in the long-term redesign.  It wants a fast path to a simple, turnkey VIVO with harvesting. 
            1. Benjamin:  has been conflict/disconnect between this stated goal and the technologies that have been identified.
          8. Dragan: Maybe can meet main goal of VIVO in a Box by decoupling in main VIVO.
          9. A&M will be contributing more to VIVO development once they are past their Folio implementation.
    2. What do we do for 1.13?
      1. Should we define what to release next while waiting for leadership decisions.
      2. Need to add additional columns to feature spreadsheet to assess whether feature impedes decoupling and whether it introduces or perpetuates technical debt that harms maintainability.
  3. JIRA vs GitHub issues
    1. "Andrew: have meeting with Tim Donahue of DSpace project. DSpace has already done a similar transition.  Will ask for feedback/advice."2020-12-08 - VIVO Development IG
  4. Merging developers and committers calls? 
    1. Dragan: would be good to have just one regular meeting per week.
    2. Ralph and Benjamin still see a use for a separate committers’ call, but maybe not as frequently.
      1. Ralph: this question might actually be better suited to a committers’ call.
      2. Benjamin: can also assess where 1.12.1 is on a call this week.
    3. Will have a Thursday committers’ call this week, and then assess from there whether the schedule should be reduced.

Draft notes on Google Drive


Task List

...