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 
  2. Dragan Ivanovic  
  3. Georgy Litvinov (star)
  4. Dominik Feldschnieders  
  5. William Welling 
  6. Mattias Luhr
  7. Naveen Sadhu
  8. Veljko Maksimovic 
  9. Benjamin Kampe 
  10. Andreas Czerniak

Agenda

  1. Announcement
    1. The 5th VIVO Workshop 2021, Germany -2021 - 5. VIVO-Workshop (DE)  
  2. Discussion about organizing sprints and publishing time-based minor releases
    1. https://docs.google.com/document/d/1hJSWAa3ENoFOYyp0GyvDqBdehra3AmFBAD9X2dX3cSo/edit?usp=sharing
  3. Discussion about priorities for further development of VIVO - https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit?usp=sharing
    1. The topic will be i18n
      1. Move i18n properties from resource bundles to ontology / (editable) RDF
      2. Find solution for syntax differences between languages that does not require template customization per language 
    2. Data ingest

Notes

  1. Announcement
  • 2. Discussion about organizing sprints and publishing time-based minor releases
    • 1. https://docs.google.com/document/d/1hJSWAa3ENoFOYyp0GyvDqBdehra3AmFBAD9X2dX3cSo/edit?usp=sharing
      Let's discuss months of sprints and then other details about the meeting.
       I am not sure August will be popular. Maybe we could have 3 productive sprints and used the fourth (August) for testing and updating documentation. Of course all developed features before integration should be tested, and after integration documented, but a lot of projects are struggling with lack of docs. The August sprint might be used for updating documentation for features developed in previous year.
    • Sprints should be organized in February, May, August and November. These months sound ok for you? December and January are not good months to organize sprints.
      What are your first thoughts about it?
      William: There's a lot to resolve. We just need to set it in schedule and determine by amount of activity on the go.
      Dragan: What dates should be skipped for sure in the USA?
      William: No particular dates.
      Dragan: Let's that set February, May, August, and November for organizing sprints.
      Dragan: How long meetings should be? Should we try 3 weeks to see if it is working or not?
      William: Those who are responsible for maintaining it should be active all 3 weeks. I prefer the 2 week spring. One week before, one after. Still having not a lot of contributors 3 weeks will be ok. 2 Week sprint – grab and work, all planning should be done before.
      Planning is for preparing the sprint. Afterwards there should be a retrospective and demonstration. 3 weeks is ok for me.
      Dragan: We should decide whether it will be two or three weeks. Lets try 3 weeks. Maybe 3 weeks including planning, analyzing and implementation? And in the end someone should do review, comments, tests. Is this should be after sprint or should be within sprint. PRs should be reviewed?
      William: That depends on availability. This should be done throughout the process. In the end it should be merged to the sprint staging branch. It should be verified that it has all new features. It also gives the opportunity to review this sprint and analyse all the code in that sprint.
      Dragan: How should we synchronize? With Slack? Should we organize online meetings or should we discuss that in regular meetings?
      William: We should do stand-ups every day. We definitely want stand-ups to have good expectancy of work to be done. Participants not participating in the sprints should be informed about the sprint at regular VIVO developers IG meetings.
      William: If anybody oppose to have everyday stand-ups? I like Slack stand-ups, but enjoy more meeting stand-ups.
      Dragan: We don’t have people fully participated in this. We should think of that cases. This preparation for sprints is very important. It should be considered well before the sprint.
      William: Participation will be coerced by sprint targets. If we don’t have plan it could reduce involvement in sprints. We should have plan.
      Dragan: Right after we define the topic we should.
       William: We pick the technologies. Advertise their incorporation in VIVO to attract more coders.
      Dragan: We would have 2 months around sprints. We are going to select a topic for the next sprint, but we can’t be sure the next topic will be completed within a sprint. We can use some Tuesday meetings to discuss that. We should define how to attract people. If the previous topic is not over we will continue this topic (at the next sprint). We are going to discuss topics in the list and order it by priority. With a selected topic we should work on the preparation, categorize issues, set priorities, find overlap issues, define dependencies between issues. Now in GitHub we define templates to report issues. But there is still no guarantee we will have detailed description of an issue. Especially if one issue is blocking we should carefully work with issue dependencies. We need to make a plan. Is it too private to ask people about their availability? At this point (sprint preparation) we might speak about assignments with issues. We can also discuss that during the sprints. There is always a risk of last minute cancelation.
      We Also need wiki for sprints, and branches, project boards on GitHub.
       Milestones too, but milestones not strictly related to sprints.
       I will also prepare Zoom meeting invitations for that.
      William: It is pretty close to what we did before. There was more lack of participation. Not related to sprints directly, but we need to make a decision about where are we going. There should be a point when we say that we should go in 1.X and 2.X by scale and requirements. There are a lot of internationalization bugs. Should they be fixed in 1.X or 2.X. We anticipate 2.X all dynamics change. There are two common approaches: re-architect or shim things. I feel like we are just spinning in circles.
      Dragan: We have 2 months. We should be aware of people using this product, but at some point there would be a block. We need to be aware of emerging technologies to be in time and provide modern features.
      Is there a request for scalability?
      William: It is not the only needed for a massive amount of data. There are a lot of benefits to having scalable applications. It is hard to say how many organizations need that, probably not a lot.
  • Discussion about topics
    • Dragan: Should we start discussing the topics or go to the next agenda item?
      We might need big topics and then discuss minor topics? I think that data ingestion is one of the most valuable topics, but we have an ingest group for that and we will always need to input data from various systems. Could Briand explain decoupling vivo ontology from VIVO? If you add one property to VIVO Ontology it will be available to users. Mike complained that there is no way to change VIVO ontology and the platform will be working as expected. Ontology is coupled with source code.
      Brian: For a while there is confusion about adding things in ontology. There is a general thing before VIVO didn’t have custom views and other ontology things that coupled with VIVO code. Now almost everything requires extra things like document modifiers, custom list views. We need this to make ontology useful. There are a lot of them and these pieces could go in one cohesive subgraph that makes sense to display. Fundamentally it is a pretty big issue.
       Dragan: Do you think this issue could be resolved in one sprint?
      Brian: That certainly will be a longer task.
      Dragan: Could you think of those topics and share some more ideas?
    • Georgy: Trying to define ontology for dynamic api could solve a lot of problems.
    • Dragan: Will we be able to finish it in one sprint?
    • Georgy: There is a need to investigate deeper, but in general I guess no

 

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.