...

1. Don Elsborg 
2. Andrew Woods
3. Huda Khan
4. Ralph O'Flinn
5. Steven McCauley 
6. Benjamin Gross 
7. Mike Conlon 
8. Alexander (Sacha) Jerabek  
9. Rachid Belkouch
10. Michel Héon
11. Brian Lowe

Agenda

1. Sprint planning - i18n
   
   1. Sprint dates: Apr 6th - 17th
   2. Sprint prerequisites
      1. https://github.com/UQAM-VIVO
      2. Vivo i18n M2 http://vivo-i18n.dev.uqam.ca:8080/vivo_i18n_M2 (Reference source for testing)
         
      3. ETV Dev Tool https://github.com/UQAM-VIVO/Vivo-Traduction-Ecosysteme
   3. Pre-sprint planning meeting: Mar 25th @10am ET (https://uqam.zoom.us/j/996861901)
      1. 2020-03-25 - i18n Editing pre-sprint meeting
2. Who is working on what?

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1756

   2. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1755

   3. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1443

   4. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1753

3. Using community questions to lift the entire team

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1749

   2. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1750

4. Vitro JMS messaging approaches
5. Incremental development initiatives

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1688

   2. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1751

   3. Integration test opportunities with the switch to TDB - requires startup/shutdown of external Solr ..via Maven
6. Vitro pull-requests

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1658

       - looks good

...

Draft notes in Google-Doc

1. Please fill in placeholder page for sprint planning.
1. Integration of code into the core.  How will this be done?
2. Snapshot https://github.com/uqam-vivo  Running version here http://vivo-i18n.dev.uqam.ca:8080/vivo_i18n_M2 
3. Primary goal for the sprint is to get the UQAM code into the core code base.  One method is to create a branch of all VIVO codes, then add the UQAM code, then should be ready for pull requests.  This should be done before the sprint as sprint preparation.
2. https://github.com/UQAM-VIVO/Vivo-Traduction-Ecosysteme a pre-configuration of all the environments needed for VIVO.  A complete maven build and run. Installs everything needed. Specially designed for non-full programmers, for people who want to work on translations -- ftl, ontology.  For windows. Useful for translators, librarians. Non-developers. UQAM trained 15 people on the environment.
3. 1756 looks good to go.  Need to test/review
4. 1755.  Turning off the reasoner defeats the admin panel.  Now the admin panel can be loaded. Abox reasoner is separate from tbox.  There is a visual notification if the reasoner is not running. mostSpecificType is the most likely thing from the reasoner to be missed by people with inferencer turned off.  mostSpecificType is commonly used in listViews to get the right things into lists and interfaces.
5. 1443.  Has been a concern for years.  Goal is to create a WAR file. Full separation of build and install.  One benefit is that a release can include a WAR file and you can just drop it in.  vivo home files are packaged into WAR. At start-up it looks to see if you have one, otherwise, boom, it makes one.  If you have a vanilla Solr, then perhaps API calls can be made to configure it for Solr. Goal might be to install vanilla tomcat, solr, tdb and then drop a VIVO WAR file in tomcat and everything gets configure, vivo home gets built, all at first time start up.
6. A VIVO archive repo has been created.  https://github.com/vivo-archive  What might be saved?  Little? More?
7. 1688 would put the ontology into its own repository.  Ontologists could then move forward on major and minor changes.
8. Test framework?
9. What can be our general approach to reducing the dependence of the code on the ontology?  The Scholar architecture, for example, isolates ontological change in its mapper, and creates an elastic search index with no references to ontological elements, optimized for presentation purposes.

Actions