...

1. Status of In-Review tickets

   Expand
   Jira server DuraSpace JIRA jqlQuery filter=14416 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

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 

...