Ralph: A demo site is being put together. Ralph has some code updates for the React project. Still discussing the best way to get data aggregations to visualizations; GraphQL endpoint not (yet?) suited to this.
Andrew: Email from Julia helps clarify relationship between VIVO Scholar and rest of VIVO suite
Mike is concerned about separating the VIVO project and that we not create confusion when we discuss different development efforts.
Andrew would like to make it easier for contributions to come into the code base, e.g. from contributors like Alessandro.
Ralph: process change for approving bug fixes may be a step in that direction. Dedicated time for code review or helping others with the process might be a good idea.
Andrew largely not available until the new year (needs to use up vacation). Not available for meetings until the second half of January (week of January 20th).
Mike: Two main topics: (1) moving pull requests forward; (2) need to be able to name components (“these are the things we work on”) -- probably 8 to 10 things. Right now we have preferences for certain components; would like to make the project more open so that people are encouraged to work on the things they want to work on and where they can create value.
Andrew: Agree that we shouldn’t attempt to direct community talent and energy, but sometimes these efforts are at odds with one another. Efforts sometimes pull in opposite directions.
Mike: If we did more work on architecture, we could have better answers for these issues. (E.g. if we don’t have a clear access control architecture, someone is likely to submit a pull request we might not like.)
Ralph: Sometimes a longer-term perspective may be useful (e.g. temporarily accepting something monolithic in order to move the project forward while still being aware that the long-term goal is decoupling).
Andrew: VIVO Scholar addresses or demonstrates a pattern for a clear need in community (modern UI) but is not part of core.
Items to focus on in 2020
Getting community on to latest release
Vision for supporting decoupled components vs. more monolithic installation
Don: difficult to convince management to invest time in upgrading from 1.9 to 1.11.
Interested in why there isn’t a push to move forward?
Andrew: How can we reduce the barriers and make it easier to move forward?
Andrew: If upgrading is such a chore that people dread it, we’re doing something wrong.
Don: we have to put a lot of work into our custom harvesting work and custom Freemarker template. It’s already working as is. Other customizations may or may not have to be modified.
Hard to justify to management the merging of customizations when the current version works fine and new versions don’t necessarily introduce anything compelling
Benjamin: third tier helps, but you still have to check each modified file
Most of the work is involved in library/dependency upgrading to align with the new release
Would like to see how people are dealing with external SOLR in 1.11. Specifically thinking of how to allocate memory to SOLR versus Tomcat when they’re running on the same machine.
Clarivate’s demo site is now running 1.11 without issue.
Andrew: would be nice to have a poll of who’s using which version and encourage people to move along.
Andrew: Seems to be tension between the desire to decouple and keeping it easy for system administrators to deploy.
Talking about individual, deployable components
Ralph: should supply standard script for deploying what feels like a monolith; don’t use the script if you want the flexibility.
Andrew: Docker helps with this to some extent, but for some people Docker is a non-starter.
Sacha: resources available and overhead dealing with customizations have been main impediments to moving forward. If there is a way to upgrade an essential component by itself while leaving others alone, that would be welcome. If no compelling feature, we tend to wait. Makes sense that the community is interested in getting everyone on the same release in order to simplify the support effort, but it can be hard to justify in a particular institution. Would be good to have more feedback (survey) about impediments.
Andrew: In addition to the support issue, energy from contributors is diluted if multiple versions are in use.
Sacha: should at least push users to have the latest release in test environment so development effort
Andrei: If community is interested in VIVO Scholar it might be because of the front end -- how easy it is to develop for and the features it has. This might be a compelling reason to upgrade.
Andrew: Might argue for making VIVO Scholar more of a first-class effort instead of a community effort.
But might not necessarily be the one ideal solution; also problem of branding. Focus on core identity so that when new spinoffs are created, you have the core plus other satellite projects.
Andrew: should we consider moving some of the big pull requests forward because they do add value and help keep these institutions from splintering off?
Huda: Solr is tricky because the latest version of Solr required its own deployment, but maybe other components can be decoupled but still deployed in a way that behaves like a monolith when desired.
Indicating note-taker