Date
Call-in Information
Time: 11:00 am, Eastern Daylight Time (New York, GMT-04:00)
To join the online meeting:
- Go to: https://lyrasis.zoom.us/my/vivo1
One tap mobile:
US: +16699006833,,9358074182# or +19292056099,,9358074182#
Or Telephone:
US: +1 669 900 6833 or +1 929 205 6099 or 877 853 5257
Meeting ID: 935 807 4182
International numbers available: https://zoom.us/u/aeANHanzED
Slack
- https://vivo-project.slack.com
- Self-register at: http://bit.ly/vivo-slack
- Self-register at: http://bit.ly/vivo-slack
Attendees
Indicating note-taker
Agenda
- Announcements
- VIVO Scholars updates
- Email to vivo-community list: "More about VIVO Scholar and other VIVO applications"
- New VIVO instance from CINECA: https://expertise.unimi.it/
- Andrew holiday schedule - out until week of Jan 20th (week of Jan 6th, online but in Singapore)
- VIVO Scholars updates
- Items to be tied up for 2019
- 2019-12-06 - Special Topic - TDB vs SDB
- Managing VIVO/Vitro languages (related: https://github.com/vivo-project/VIVO-languages/pull/26)
- Dependency updates
- Bringing it home:
- Related: https://github.com/vivo-project/VIVO/tree/vivo-1.11.0-lib-updates
Migrating out of vivo-project and into vivo-community (today) - maintainers?:
- Items to focus on as we move into 2020
- In-review tickets
Tickets
Status of In-Review tickets
Notes
Link on DuraSpace Wiki:
https://wiki.duraspace.org/display/VIVO/2019-12-17+-+VIVO+Development+IG
Attendees
- Andrew Woods
- Mike Conlon
- Brian Lowe
- Ralph O’Flinn
- Huda Khan
- Sacha Jerabek
- Steven McCauley
- Andrei Tudor
- Benjamin Gross
- Don Elsborg
Notes
VIVO Scholar update
- 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.
Actions
- Organize a session on Brown's work on editing
