...

 Indicating note-taker

1. Brian Lowe     
2. William Welling 
3. Huda Khan
4. Georgy Litvinov
5. Dragan Ivanovic  
6. Benjamin Gross
7. Michel Héon
8. Benjamin Kampe
9. Matthias Lühr   

Agenda

1. A brief update from VIVO leadership meeting
   1. representative of a committers' group
2. Corrections of wiki pages - https://docs.google.com/spreadsheets/d/19mSk6xSRm-ogCJisMZ6ao2X2Qi8Z9T3TxZjBzVVr8yk/edit?usp=sharing
3. A roadmap to migration from JIRA to GitHub issues - https://docs.google.com/spreadsheets/d/1Cl-aCe1he0DPwd1gScjx2Oi80lUX8W_3nE4UlzpEwI0/edit?usp=sharing
   1. Analyze available tools
      1. https://github.com/rstoyanchev/jira-to-gh-issues  ←
      2. https://github.com/susinda/github-client
      3. https://github.com/hbrands/jira-issues-importer
   2. Adopt/customize https://github.com/rstoyanchev/jira-to-gh-issues for our solution
   3. Test/validate migration - https://github.com/chenejac/VIVOTestMigrationJIRA/issues - Action needed!!!
   4. Map JIRA (https://vivo-project.atlassian.net/jira/people/search) and GitHub accounts (https://github.com/orgs/vivo-project/people). The mapping is defined here: https://docs.google.com/document/d/1SKRMuky8x8m9CgOKtxs16LWFuuVfYlQR6LkjASBEzrI/edit?usp=sharing Action needed
   5. Add labels at https://vivo-project.atlassian.net/jira/ for distinction of VIVO and VITRO issues? Do we need this? If do, an action needed
   6. Run migration into the production (https://github.com/vivo-project/VIVO).
   7. Create GitHub issues templates ( https://github.com/vivo-project/VIVO) - An action needed
4. Georgy's proposed architecture:

5. View file
   name Architecture cur and new.pdf height 250

6. Decoupling Freemarker
7. Indexing for Scholars

...

1. Status of In-Review tickets

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

   
   

Notes

1. A brief update from the VIVO leadership meeting
   1. Trying to have more of a voice from people actually implementing VIVO work
   2. Is it enough to have the technical lead there?
   1. Looks like committers have both roles: maintaining integrity and assuming innovation
   2. Not sure if the right to push new code is a requirement for promoting new innovation
   1. Current proposed LG membership changes: https://docs.google.com/document/d/1t9yNNQ5oQi3mcehmHoCdmMT-0r58n9hUvI6yegK4Dsc/edit#
   1. William: Should be the case for code that changes the application fundamentally.  Not the case for patches.  Questionable for minor changes.   
1. Discussion around expanding the leadership group to include a committer.
2. Is there interest in this group from a committer who wishes to join? Meeting is one per month (last Wednesday per month)
3. Benjamin: Discussion around if presence of a colleague from institution on leadership group will mean a committer can’t also join the group.  
4. Michel: Ensuring code we push to GitHub is clean and functional.  Another part: innovation we want to implement.  
5. Brian (from chat)
6. William: Committer’s group not actually deciding what gets implemented (or shouldn’t be).  The steering group should be making those decisions.  Committer’s group is responsible for code base.  Not necessarily deciding but their input should be part of the decision making process.
7. Brian: No formal process in place currently.  Reality: Committers do decide what goes into the code.  Pull request being approved by committers.  No official decision making process around the integration of pull requests. 
8. Michel: Discussions in committers group  involve major architectural work.  Should be open to more of the community
9. Huda: Previously, technical lead was the main translator/go-between: taking information from committers to leadership group and vice versa.  Much of the discussions in committers group really around if any direction is even possible, and less around an actual decision. 
10. Brian: Leadership group possibly less interested in architectural details, but more around which solutions may work or not.
11. William: Will they have user stories? More formal process would be good.
12. Michel: Leadership group more about product vision (e.g. alignment with semantic web).  After that, decision needs to be around how work needs to be done.  Decision making around architectural patterns/software implementation should not be limited to committer’s group but should be more expansive and include more of the community.
13. Dragan: Need to consider the spreadsheet of development priorities.  Should include more of the community in order to populate 
14. William (from chat): I think there are some architecture contingent decisions that should be decided by the steering committee. Such as; VIVO should be cloud-native or VIVO should support enterprise messaging.

Draft notes on Google Drive

ActionsActions 

•  Dragan Ivanovic to create a doodle poll with time slots options for Tuesday developers/implementers callsAll to validate result of JIRA to GitHub Issues migration tool before it is run into operation - https://github.com/chenejac/VIVOTestMigrationJIRA
•  Dragan Ivanovic to correct wiki documentation - https://docs.google.com/spreadsheets/d/19mSk6xSRm-ogCJisMZ6ao2X2Qi8Z9T3TxZjBzVVr8yk/edit?usp=sharing
•  Dragan Ivanovic to draft a roadmap (methodology) for migration from JIRA to GitHub issueswork on priorities' google sheet document

Previous Actions

•  Brian Lowe to draft initial sketch of "VIVO2" in a Google Doc
•  Huda Khan to review: 

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

•  Brian Lowe to review: 

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

•   Ralph O'Flinn to review: 

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