Date

Call-in Information

Time: 11:00 am, Eastern Time (New York, GMT-04:00)

To join the online meeting:

Slack

Attendees

(star)  Indicating note-taker

  1. William Welling 
  2. Andrew Woods 
  3. Bruce Herbert 
  4. Ralph O'Flinn 
  5. Brian Lowe (star)
  6. Michel Héon 
  7. Don Elsborg 
  8. Huda Khan
  9. Benjamin Gross

Agenda

  1. Current community sprint outcomes?
    1. ORCID
    2. Kafka
    3. Messaging
  2. Weill Cornell testing updates - Sarbajit Dutta
  3. 1.11.2 patch release
  4. Transition from JIRA to GitHub-Issues?
  5. Working towards 1.12
    1. To be reviewed 
    2. Documentation needed
    3. 1.12 release planning
      1. Email of schedule to vivo-community 
      2. Code freeze once i18n tickets are merged into the sprint-i18n branch (Jan 20th)
      3. Sprint to test merge of sprint-18n into master: week of Jan 25th
      4. 1.12 release candidate #1: Feb 1st
        1. Two week RC-1 testing period
        2. For each subsequent RC-2 (if required), adding another two weeks to the schedule
      5. Do we want the `war` install in 1.12? -
  6. Tickets that should be close to merge
  7. Post-i18n priorities
    1. VIVO-in-a-box
    2. Messaging
    3. Moving Scholars closer to core - next steps

Future topics

  1. Vitro JMS messaging approaches - redux
    1. Which architectural pattern should we take?
    2. What should the body of the messages be?
  2. Renaming of 'master' branch? (ZDNet, BBC)
    1. Guidance from GitHub 
    2. DSpace has done it
    3. Fedora has done it
    4. Samvera is doing it
  3. Incremental development initiatives
    3. Integration test opportunities with the switch to TDB - requires startup/shutdown of external Solr ..via Maven

Tickets

  1. Status of In-Review tickets


Notes 

Attendees


  1. Andrew Woods
  2. Nicolas Dickner
  3. Michel Heon
  4. Bruce E Herbert
  5. Sacha Jerabek
  6. Ralph O’Flinn
  7. William Welling
  8. Paul Albert
  9. Sarbajit Dutta
  10. Brian Lowe
  11. Huda Khan


Notes

  1. Sacha: UQAM had internal sprint with web developer to restyle VIVO.
  2. Sprint updates: testing Kafka with ORCID - UQAM and TIB
    1. Michel: retrieved all users from ORCID; persons batch-pushed into VIVO using Kafka.
      1. Conversion from ORCID JSON to VIVO RDF; sent to Kafka channel; pushed to VIVO.
      2. TIB worked on listening to VIVO changes and sending them to Kafka channel.
      3. Next step is putting this work on Github.
      4. Will continue to develop this method of injection in December/January.
      5. Bash scripts will be converted to Java code/services.
      6. Advantage of this approach is reusable design patterns / Kafka consumers.
      7. All messages on Kafka channel are in “VIVO” format using VIVO vocabularies.
      8. Kafka workflow and ReCiter?
        1. Paul: Our VIVO is read-only, so won’t be used to syndicate content out via something like Kafka.
        2. Andrew: Kafka producer and consumer architecture can include mediation steps before being consumed by VIVO.
      9. William: Could any triple changed in VIVO be immediately streamed out via Kafka? Or would it need to buffer and batch up changes?
        1. Michel: Kafka intended to be used in real-time streaming applications using large amounts of data.  
        2. William: seems like an advantage over something like ActiveMQ.
      10. Kafka consumers/producers should be internal to VIVO; use consumer instead of SPARQL API.
      11. Ralph: next week should be a data ingest meeting with demo from TIB.  Vote for date/time on data ingest Slack channel.
      12. Messaging architecture may reduce need for or desirability of intermediate relational data stores between raw data sources and VIVO.
  3. Sarbajit: API bugfix testing
    1. Works as long as maxPostSize is also correctly set.  
  4. Site admin users unable to add new individuals
    1. Huda: has taken an initial look at things; will make some more time to stare at the code.  Huda and Andrew had looked at the options and while there are opportunities for long-term refactoring, it is probably better to release a patch that works right away and then consider a better long-term strategy.  Brian will also try to look more at the issue and add hints to the JIRA issue if they suggest themselves.
  5. Using Github issues instead of JIRA
    1. Michel: sprint planning? 
      1. Ralph: Github has features that match most of what JIRA has.
    2. Michel: Github generally seems like a big list of issues, but hard to categorize.
      1. Andrew: there are different labels to apply to issues.
    3. Tooling on top of Github issues?
      1. William: There are various projects for more elaborate Kanban or other things on top of Github issues.  Lot of work to make it happen: may not be something we want to take on at this time.
      2. William: Might be good to have trial run with Github issues before moving everything other.
      3. Andrew: have meeting with Tim Donahue of DSpace project. DSpace has already done a similar transition.  Will ask for feedback/advice.

Draft notes in Google-Doc 



Actions