Date

Call-in Information

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

To join the online meeting:

  • https://lyrasis.zoom.us/j/84378615572?pwd=bGUxSjlyRTdjOGl5U1B6L0Yva3RQdz09

    Meeting ID: 843 7861 5572
    Passcode: 556561
    One tap mobile
    +16699006833,,84378615572#,,,,*556561# US (San Jose)
    +19292056099,,84378615572#,,,,*556561# US (New York)

    Dial by your location
            +1 669 900 6833 US (San Jose)
            +1 929 205 6099 US (New York)
            +1 253 215 8782 US (Tacoma)
            +1 301 715 8592 US (Washington DC)
            +1 312 626 6799 US (Chicago)
            +1 346 248 7799 US (Houston)
            877 853 5257 US Toll-free
            888 475 4499 US Toll-free
    Meeting ID: 843 7861 5572
    Passcode: 556561
    Find your local number: https://lyrasis.zoom.us/u/kerqtGDrJ4

Slack

Attendees

(star)  Indicating note-taker

  1. Brian Lowe (star)
  2. Dragan Ivanovic  
  3. Georgy Litvinov 
  4. William Welling  
  5. Huda Khan  
  6. Benjamin Kampe 
  7. Matthias Lühr 
  8. Veljko Maksimovic 

Agenda

  1. Questions/Issues/Pull requests
    1. Capability map
      1. https://github.com/vivo-project/VIVO/issues/3607
    2. VIVO without SOLR - https://vivo-project.slack.com/archives/C8RL9L98A/p1638538627095900
  2. The preparation for the February sprint
    1. Roadmap for 2022-2023 sprints
      1. https://docs.google.com/document/d/1hJSWAa3ENoFOYyp0GyvDqBdehra3AmFBAD9X2dX3cSo/edit?usp=sharing 
      2. https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit#gid=0
    2. Date for the sprint
    3. Infrastructure
      1. GitHub
        1. Project board
          1. Beta - https://github.com/orgs/vivo-project/projects/2/views/1
        2. Milestone
          1. 1.13
        3. Branch 
          1. feb-2022-sprint
        4. Issues
          1. defining
          2. deduplication
          3. linking
      2. Wiki page
        1. Description of sprint / call / engagement
        2. Minutes / sprint report
        3. Sprint participants / registration
      3. Virtual meetings
        1. Zoom invitations
    4. Content for the infrastructure should be based on Georgy's document - https://docs.google.com/document/d/1vtNIVEYWdBgV11N-wiPk_UNKpiFQ4sKetJ8elJ6xy2E/edit#heading=h.k389x4cotzuw

Notes

  1. Questions/Issues/Pull requests
    1. “Map of Expertise” and “Expertise Graph” have been suggested as new names. https://github.com/vivo-project/VIVO/issues/3607
    1. Michel: Want to use text search directly in Jena using the full text search feature of Jena.  Also available in Neptune.  When we deploy a VIVO instance in AWS it is complicated to install both VIVO and Solr.  There is a solution, but it complicates the installation procedure.
    2. Dragan: should be possible to do a Jena implementation of the SearchEngine interface rather than replacing it entirely.
    1. Will not meet on the 28th of December or 4th of January.
    1. Capability Map
    2. Running VIVO without a search engine
    3. Bulk account addition has been discussed on Slack.
    4. New Slack channel has been created for SPARQL query help.
    5. Meeting schedule:
  2. Preparation for February sprint
    1. https://docs.google.com/document/d/1hJSWAa3ENoFOYyp0GyvDqBdehra3AmFBAD9X2dX3cSo/edit?usp=sharing 
    2. https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit#gid=0
    1. Dragan: Official registration?
      1. William: yes; it’s a public repository anyway.  Lists should be public so that people know whom they can collaborate with.
      1. William: Should have some kind of tentative commitment in order to effectively estimate how much to allocate to the sprint.  Backlog for sprint would need point estimates, and developers need to estimate the points they have available.
      2. Commitment should be recorded by the first of February.
      3. Dragan: Is it OK for the list to be public?
      4. Dragan: Need resources (people) and how available they are.
      5. William: Could use Google Forms if we want to gather more detailed information.  Would produce a spreadsheet on which we could do analytics.
      6. William: How much do we want to adhere to the common Scrum/Agile sprint process?  Includes a suite of meetings before and after the sprint.
      7. Dragan: Need meetings before the sprint, plus short regular daily meetings during the sprint.  Difficulty is that we are located in different timezones.
      8. William: My teams typically do Slack-only standup meetings  two or three days a week, with actual meetings on the other days.
      9. William: I like demos as part of the process, because they’re the last chance to confirm that everything is working as intended and approved by the product owner.  Also retrospectives after the sprint.
      10. Dragan: Not sure about the demo, since we’re only the technical team.  Don’t have regular meetings with project management.
      11. William: The Leadership Group is supposed to be involved in the demo and picking what should be done.  Since we’re picking the work to be done, that does make demos sort of pointless.  One key point of a demo, however, is to ensure that everything works in integration.
      12. Michel:  The demo is interesting for making documentation and recording what happened.  You have to focus in order to make a demo.  You might have two weeks of development followed by a week of preparing the demo.  Important for having a real conclusion to what happened in the sprint.  With the demo you have a real result.  The demo is an occasion to see what the others have done, since we’re geographically distributed.
      13. William:  There are many reasons to have the demo.  Agree with Michel:  you have to script the demo, and the script forms the basis for QA testing.
      14. Dragan:  Should organize the demo either after the sprint or perhaps and the end of the third week.
      15. William:  Main branch could get ahead of sprint branch if a high-priority bugfix comes in during the sprint.  A separate staging branch into which the sprint branches are merged avoids conflicts at the end of the sprint.  Additionally, all feature branches should be isolated as much as possible.  Should features be squash-merged, or merged with all commits?  Squash-merge increases conflict headaches; should have a procedure there.
    1. SHACL for validation
    2. How to properly collect parameters?
    3. Everyone is invited to comment on the document
    4. How to handle authentication?
      1. Dragan: Good to use tokens.
      2. Georgy: As we decouple, we should think of providing the data in formats that would also be useful in Freemarker.
    5. For deleting triples, we could fully refresh the cache in the first implementation and optimize later.
    6. William: Is the dynamic API going to be built in Vitro or a separate project?
      1. Georgy: Thought about using Vitro.
      2. William: If we’re going to be developing in Vitro, we have to use Vitro’s current architecture.  We could be compounding technical debt if we just build in Vitro.
      3. Georgy: Current Vitro configuration (populating Java objects via RDF and method annotations) can be heavily reused for this project.
      4. William: Application configuration doesn’t have to be semantic, even if it’s a semantic application.
      5. Georgy: Should plan to have decoupled components so as not to exacerbate problems, but there are good parts that can be reused and these should be better documented.
      6. William: If we apply very good encapsulation of what we create, we should be safe.
    1. Roadmap for 2022-2023 sprints
    2. Block the weeks of February 20th - March 11th on your calendar.
    3. Will use GitHub project board (likely spreadsheet style rather than Kanban style, but there may be less automation available).
    4. Next release should be planned for April.
    5. Need GitHub issues in place, and need to create wiki pages describing the sprint.
    6. Dynamic API proposal additions (Georgy) https://docs.google.com/document/d/1vtNIVEYWdBgV11N-wiPk_UNKpiFQ4sKetJ8elJ6xy2E/edit#heading=h.k389x4cotzuw:

Draft notes on Google Drive

Task List



  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.