Date
Call-in Information
Time: 11:00 am, Eastern 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
- William Welling
- Andrew Woods
- Alexander (Sacha) Jerabek
- Ralph O'Flinn
- Benjamin Gross
- Michel Héon
- Huda Khan
- Rachid Belkouch
- Don Elsborg
Agenda
- Mailing list activity
- Rescheduling of VIVO Leadership call... now conflicts with Committers meeting
- Sprint update: i18n
- Scrum board
- Three tickets remaining for merge to 'master' branch
- Beta release? community testing?
- Simplifying installation
- Moving Scholars closer to core - next steps
- SelectQueryDocumentModifier
- Entities: Collection, Concept, Document, Organization, Person, Process, and Relationship
- Configuring Solr
- Moving Data Ingest Task Force forward
- Renaming of 'master' branch?
Future topics
- Vitro JMS messaging approaches - redux
- Which architectural pattern should we take?
- What should the body of the messages be?
- Renaming of 'master' branch? (ZDNet, BBC)
- Guidance from GitHub
- DSpace has done it
- Fedora has done it
- Samvera is doing it
- Incremental development initiatives
- Integration test opportunities with the switch to TDB - requires startup/shutdown of external Solr ..via Maven
Tickets
Status of In-Review tickets
Notes
- Mailing list: everybody should be encouraged to participate and answer questions as they arise.
Bg: like that the messages are not deleted as in Slack, need to pay for messages past 10000, but Slack has more flexible conversation management
Aw: get the impression that we use Slack more
Sj: archives for mailing lists are useful for past comments, proposed solutions
Aw: so, for certain contexts we should encourage people to use mailing lists.
- Rescheduling call:
Conflict with VIVO leadership and VIVO Dev calls, now conflicts with committers meeting, looking to move to one hour earlier: 10am eastern time for now and then settle on a definitive time.
- Sprint update: things are looking pretty good for i18n
Outstanding tickets : 1848, 1867, 1918 should be resolved shortly, quite close to release of the i18n version. Dominic and Mathias contributed some helpful bug fixes, brought in by Christian.
Bg: where did the conversation about editing labels end?
Aw: latest iteration by Dominic has a regression that needs to be merged, but that aside, for updating labels the drop down option for languages is removed, if you want to add language specific labels you need to change context and then edit the label. ‘Add label’ button only appears when label is missing in a specific language context.
Bg: a question of how people will use the site, what are the use cases? Assume this will meet the requirements of those who will use the functionality.
Aw: reason for removing the dropdown next to label to add other language labels, was that whatever context you are in the appropriate language tag will be applied, this is consistent with how other areas work, so consistency across the site was the guideline, a dropdown would be asymmetrical.
Aw: any concerns about i18n? After these 3 tickets are merged into master we are ready for production.
Bg: pulled recent changes in 18n branches into a docker version
Aw: Community testing: if we get a beta release out with i18n functionality, we would need community testing to make sure it works for those who use the new functionality as well as those who don’t. So a docker here is very useful, spin up a version in AWS and make it public to demo it. Any thoughts on community testing to provide sufficient confidence to from beta to full release.
Mh: will i18n be a core feature or an add-on or separate branch?
Aw: with 1.12 no longer need to apply special configurations to pom files etc. all dependencies are already there. Deployed artifacts are already in war file.
Bg: english is now considered or treated like any other language, no preferential status.
Aw: minor piece of logic remains where no language stuff is enable, en_US is chosen as default configuration.
Aw: any ideas about promoting community participation in testing? How to pull in participation and how do we know that we have had enough testing?
De: we do not have an interest in multi-language support, but we do want to do the upgrade.
Hk: Testing office hours? Or a week where we could say we'd be available for questions? (asynchronously)
De: need to know if I get the same set of triples uploaded via harvester from 1.10 to 1.12
Rof: should be true
Mh: you will need to change language tag in triples, you will have to add en_US
Bg: suggested not required. If you have multiple languages you may see some odd behaviours, but with single language in effect should not be an issue.
Mh; but if you intend on sharing your data , best to include language tags
De: we want to remove as many blockers as possible, may add language tags later if necessary.
Mh: UQAM will test new release for sure, but also others in UQ network will test, and also some other French universities. We can broadcast a call to test new release in the Quebec network.
Rb: there are at least 3 institutions interested in VIVO so we can test both, mostly French but also English in some cases, especially since research is largely in English.
Mh: how can new institutions provide feedback?
Aw: one channel is a google form to collect feedback, more formal. Other channels are existing slack or mailing list, or a special themed call. Also, open office hours as Huda suggests is a good idea as well. A weekly email with call for feedback and summary of comments to date.
- Simplifying installation:
Aw: topic is recurrent, some efforts have been made, there are branches with approaches to this issue. One of the blockers is externalised solr that needs to be configured, if we can automate that on startup it would simplify that aspect. There is a blog post by Hector from Brown that explains how they use managed schemas via apis, this is an important piece. Anybody interested in exploring 1752
Bg: i have pasted some python code that shows what needs to be done, or what can be done. You need to have a solr config .xml file, we are creating a core programmatically via api, but pointing to existing files. Or, solr comes with a file in some cases and new installations creates a file as overlay.
Rof: you can create your core, add your fields, remap fields etc., I could take a look if nobody objects to using python.
Aw: you can use python to prove concept and then extrapolate and include into VIVO.
Bg: will this become a dependency of the VIVO build process? Can comment out if you opt for elastic search?
Aw: we can continue to explore design decisions at tomorrow’s committers call
Ww: there is a java library ‘solrj’, maybe an idea to use this as an option
Actions
