...

1. Ralph O'Flinn 
2. Tim Worrall  
3. Don Elsborg 
4. Andrew Woods 
5. Huda Khan
6. Kitio Fofack  Benjamin Gross
7. Christian Hauschke
8. Aaron Collier
9. Muhammad Javed
10. Mike Conlon
11. Steven McCauley
12. Qazi Asim Ijaz Ahmad
13. Michael J. Giarlo
14. Jim Blake Brian Lowe

Agenda

1. 1.11.0 planning

2. Semantic Versioning?
3. Review policy for vivo-languages repository
4. Sept 17-28 sprint planning
   1. Add your name
   2. Add your interest
5. New tickets

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

       (Vitro pull-request)... pending follow-up from Stefan Wolff
6. Suggested updates from Michael J. Giarlo

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

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

7. Listview configs and faux properties - Don Elsborg
   1. upgrade from 1.7 to 1.9 now displays duplicated awards in organizations
      1. https://experts.colorado.edu/display/deptid_10233#honors
   2. noticed that ObjectPropertyDao.Jena.java has a query the pulls all object properties without considering the range, why is this?
   3. 
      
      

...

Draft notes in Google-Doc

Resource caching

1. Don – Want to expire static assets. How? - eg visualization.css
2. Jim – 1.10 has code to check last modified data to a static file to make it a ‘unique’ asset. This is done in freemarker.

1.11.0 planning

1. Andrew - 1.10 is out, how to release more frequently. Lower barrier to get subsequent releases out.
2. 1.11 – what is a comfortable timeframe to do this. Be driven more by timeframe then by feature set.
3. Major release once a year, minor releases more often
   1. – opinions ?
4. Christian – lot’s of development happens now, would appreciate if this gets released more frequently. So would like to see advanced role mgmt out, this will be a pull request. 
5. Mike – also expect a pull request from ontologists.
6. Kitio – what is the definition of a major vs. minor release? So the amount of work that needs to be done to upgrade. So if we’re not working that hard - do more minor releases.
7. Don – more frequent releases desired — because 1.7 to 1.9 was a big release for CU
8. Andrew – more meaning to releases
9. Mike – all upgrades are difficult. This is because of customizations. So we should discuss how to make upgrades easier. 
   1. New topic = how to make upgrades easier
10. Putting out 1.11 should be put out in 6 mo
11. Ralph - +1 to 6 mo
12. Ralph - minor release can’t be a breaking change. So just bug fixes.
13. Andrew - again any release is major because of customizations
14. Kitio – if we have something that changes with data structures, this should be major release.
15. Ralph – things that break customizations
16. Mike – things that consume from VIVO should also expect no changes to interface. Changes to interface should be major. Also changes to model should be breaking change. So problem with versioning system.
17. Andrew – can’t just be changes to data model, ui changes, etc
    1. So this should be changes that make it “easy” to upgrade.
18. Andrew – agenda 2 – versions associated with a release have meaning. So every decimal location in the version has some sort of meaning. 
19. Ralph – need a chart the describes the versions in order to give it meaning.
20. Jim – since NIH grant versioning has changed. Used to be that dot releases were bug fixes. 
21. Mike – 1.5 to 1.6 should have been a major release. Same with 1.9 to 1.10 . Problem was that there were no real visible features. So this was a “marketing” decision.
22. Don – All breaking changes should be a major release. So maven change, 1.6 change, 1.9 to 1.10 
23. Andrew – wants meaning for versions. What are the meanings for the dot locations?
24. Don – want to also use semantic versioning for 3rd tier to compare to VIVO/VITRO tiers of versioning.
25. MIke - we don’t provide file compares. To do this now is actionable. So display the files that change from a previous version.
26. Andrew – will need to come back to this, probably at the leadership level.
27. Andrew - minimize releases that provide major upgrade pain.

vivo-languages repository

1. Christian – language repo’s are maintained by various communities. He has done an import of language files in May. Nobody knows how the policy reviews should be handled. 
   1. Pull request: https://github.com/vivo-project/VIVO-languages/pull/11
2. Andrew – there is a policy for reviewing a pull request for languages( Don - missed this … ) 
3. Andrew - should we change the policy for languages.
4. Christian – committers can do a technical test to determine if a language change breaks VIVO.
5. Andrew - choices 
   1. Content review – so someone who’s not the author, but a committer, can look at the content of language updates and determine if it’s correct. And Technical review - functionality and someone from ontology group to verify properties of pull request for validity
   2. Move languages out of vivo-project: So move this to vivo community such that vivo-project doesn’t depend on this.
   3. MIddle ground: certain repos in vivo project have a variation of the standard policy such that a committer doesn’t have to play a major role in pushing the process forward.
6. So should committers be responsible for community repos? What does in mean to be in vivo-project for committers?
7. Jim: vivo-project vs vivo-archive were designed to be seperate. Jim doesn’t like the 3rd option.
8. Andrew: if we move languages from Vitro/Vivo to vivo-community, assumption is that during release process stakeholders be involved in release process to verify languages work for a release.
9. Ralph: what about idea of a base language that committers support vs additional languages? 
   1. Kitio - doesn’t agree. 
   2. Christian also doesn’t agree.
   3. Christian is fine with anything that moves project forward. 
   4. Kitio doesn’t like this being moved to community. 
   5. Huda – if languages move to community it will seem that languages aren’t really supported. But in this case we will need language experts to verify what’s going on.
   6. Christian – discussion that english should be a language like any other language. So in this case english should also move to community.
   7. Mike: this is similar to ontology pull requests. Can’t just have committers review ontology. So germans need to review german language. Need technical review for developers, and then a specialist review for specialty languages.
   8. Andrew – do we value support for languages – yes!!
   9. So language specialists handle languages, Then committer reviews pull requests. So nothing needs to change regarding process or github structure.
   10. Group agrees – didn’t hear dissenting voices
   11. Mike G. in samvera, locals were addressed by having native speakers give better translations then google translate. SO this lives along the code. Native speakers not REQUIRED to approve, but core team reached out to native speakers.
       1. So technically files need to be in place, even though the specialists are responsible for the translations. So having language specialists in place and having them review will help the project.

Sept sprint planning

1. Sprint coming in Sept, add name and interest. Looking for engagement. 

New tickets

1. Stefan Wolff needs to respond.

Contributions from Stanford/Giarlo

1. Mike has a github change regarding these 2 tickets.
2. 1502 and 1503 are similar in spirit. Both add new config values. 
   1. Specify smtp use TLS to send email. So good to add administrative accounts.
   2. Adds config that allows to specify baseURL this is important if VIVO behind proxy. 
3. So both related to account activation, and both small changes.
4. Any reactions: Ralph seem fine, silence from group.
5. Mike G, has code out there for review. Want’s help with this from Java Vivo experts before pull request.

Previous Actions

•  Don Elsborg to document "firsttime" resolution in CU BOulder wiki, circulate this doc to email list and discuss as a team how to integrate this in VIVO documentation
  •  moved initialTBoxAnnotations.n3 back to firsttime. Need to edit this to change a few labels. eg authors → "CU Boulder Authors"\
    •  eg: https://github.com/cu-boulder/vivo-cuboulder/blob/a3b7e70704264b2c4fead29ef80c5efc45a9357e/home/src/main/resources/rdf/tbox/firsttime/initialTBoxAnnotations.n3
  •  Had some changes in propertygroups.rdf, in 1.7 this was moved to firsttime. Left it there now 
    
    

...