Indicating note-taker
Time: 11:00 am, Eastern Daylight Time (New York, GMT-04:00)
To join the online meeting:
Indicating note-taker
Mike: had two pull requests merged. Yahoo! Thank you all for reviews and merging and everything else. Comments I got were really good and really improved the pull requests.
Andrew: Glad to hear that was a positive experience.
Tickets discussed last week.
Andrew: 1409 and 1459 were reviewed and merged.
Review of process: two committers; one should be a committer. Committer would be in a position to commit the change.
In these two pull requests, did two reviews and at least one was from a committer. But for whatever reason those pull requests were not merged after crossing the threshold of two reviewer thumbs up. Wasn’t clear why; I ended up doing the merge in both of those cases.
Was there a reason for not merging?
Mike: Wasn’t clear to me that if the committer was the second reviewer that the committer could go ahead and commit.
Andrew: I would suggest that that be the case. I don’t see a reason not to go ahead and move it forward.
For 1459, Brian hadn’t seen that the second approval had occurred before Andrew’s merge happened.
Kitio still has one pull request awaiting further changes.
Benjamin: Huda brought up that there were some changes made that weren’t directly addressing the issue. Agree that they should be separated out and addressed via a separate pull request.
With some of these changes, you have to know that the language translations repository exists and needs to be updated as well. Can’t leave their various string fields blank.
Christian: not a fan of using Google Translate to fill in new fields. English would probably be better than Google Translate.
Mike. The es-GO is probably Google Translate, but I believe the Portuguese is actually done by native speaker collaborators.
Andrew: Something we can do to make it more clear that the language translations repository exists? A README addition?
Mike: README is good, but reviewers of language properties are probably also likely to notice.
2. Experience with steps involved in closing JIRA tickets / squashed commitBy default, commit message is a concatenation of the individual commit messages. Cleaned up the messages a bit.
Added a link to the JIRA ticket to the commit comment so there is traceability between the commit and the JIRA ticket.
After committed in Github, went over to JIRA ticket to close issue -- changed to ‘fixed’ and added a link to the commit in the JIRA comment.
Release field: what release this will end up in. For Jena tools, simply created a new 0.1 release.
Don’t need to be the committer who did the review of a pull request; any committer can move it forward if there are two thumbs up.
3. waiting for Jim
4. Andrew: Strategy meeting last week.
One outcome was creation of five task forces. All clearly relevant to everyone here, but 4a - Product Evolution Taskforce - Google doc is probably of most interest. Product Evolution task force
Number of ideas floating around
Can revisit this document and its implications
Initial musings plus existing are sources for what we want to be focusing on for the sprints that are coming up.
Benjamin: I was there and Alex Viggio was there as well in person. Had 1-½ hour discussion on things that were our priorities and things that we though the community as a whole would be interested in. Doc created by Paul summarizes some of the discussion we had during this time. Wanted to create an action plan: still blank. Don’t think that document should have been created with just five of us in the room anyway. People on this call can contribute to that.
Document should be open to comments from everyone. Feel free to make comments.
Mike: I was at the meeting. Not at the product evolution breakout. The highest-level idea here is, perhaps, that the project wants to make progress and had significant concern about the progress that had been made over the last several years. These five topics emerged as things that needed to be addressed. Five volunteers stepped forward to organized events related to these areas.
Goal is to create action plans that can be executed over the next twelve months. Will be various report-back opportunities over the year to see the progress made in these five areas.
Other general direction is think creatively. Absolutely an opportunity to do what needs to be done, to start doing what needs to be done to put us in a better place. That is certainly the general direction for all the groups including Product Evolution.
Javed: in Google doc, lists of nominees.
Mike: only from the people in the meeting, just for facilitating the breakout session. Will be calls for participation in all of these groups.
Huda: Do you want to talk about the difference between vision and product evolution?
Mike: You’re right: vision is broader. Product is about building a piece of software. Vision people are on a short timeline (6-8 weeks) and have plenty to work from. Not sure how much vision tweaking they’re going to do.
Dovetails into a product concept, which is that the world has changed a lot since VIVO was first conceived in 2003, since the grant began in 2009. What can we give away? I.e., are there things in the world that we should use. New and exciting data sources and related efforts. E.g., ORCID did not exist when we started; open APIs didn’t exist. Vision people will be doing some of that along with the product people. Vision people will be broader and finish first.
Don: Will linked data and semantic technology still be pillars of the technical product?
Mike: Yes. An interest in VIVO’s being a semantic product. Absolutely. Semantics is a central principle. Need not be the method by which data are presented or analyzed.
Don: Driving for having it be the interface. Delivering JSON to other consumers. Is the goal of VIVO’s product to be able to deliver that semantic representation of the data so we can leverage linked open data?
Mike: Two issues. 1. Delivering data to the world: semantics are fundamental. 2. Within an organization, want to deliver data in whatever context makes sense. Technology should be optimized for the use cases. Semantics as the foundation and local delivery methods to optimize delivery in various contexts.
A lot to be done to optimize the presentation layer.
Ralph: I’m working on and have gotten quite far with a Bootstrap version of a VIVO theme that works seamlessly on 1.9 and beta 1.10 snapshot version. Got a thumbs-up from our communications department. Responds correctly on mobile devices. Includes all the front-end visual parts of VIVO; still working on the backend. Looks and works correctly. Still cleaning up the libraries and some weirdness that had been in there previously. Posting it on Github for everyone to start looking at. Purpose to be a generic Bootstrap template that anyone can take and run with. Out-of-the-box replacement for Wilma. Would be a quick way to get a quick win for us.
Mike: Is there a ticket for this? I would like to follow the work and make comments.
Ralph: Was related to the JIRA ticket to take the Symplectic template and create a generic template from that. Think is got closed and some point.
Some screenshots and links on Slack channel
Andrew: Reopen ticket or create a new one.
Any comments you put on Slack will eventually go away until we have a paid version. Free version only retains last 10,000 messages.
Ralph: I will fix it later today.
Benjamin: Ticket for responsive template here: https://jira.duraspace.org/browse/VIVO-114
Christian: Presentation is also reporting to research administration.
Mike: I think you’ll find a lot of comments in the Google doc and would encourage everyone to read through and make more comments.
Andrew: Task forces that came out of strategy meeting. Thinking about communication. Mike does a great job putting out a weekly blurb, but it’s vitally important that whoever is interested here be involved -- specifically in the Product Evolution Task Force -- or get a flow of information so that we all move in the same direction. Don’t want task force and developers to move in different directions.
Mike: First approach is to participate. Product Evolution Task Force should be everyone on this call.
Action plan group will be producing notes and process. Calls this week; will share as soon as there is something I can share.
Fixing lack of notes from 1 March meeting as soon as I can.
Andrew: Sprints
Please add your name to the participants list on the development sprints link in Slack https://wiki.duraspace.org/display/VIVO/Development+Sprints
Starting to decide on the topics and focus of sprints. Will be a bit of a challenge
If it would be helpful for me or Mike to talk to someone at your institution to advocate for your participation, we can do that.
Not crystal clear what needs to be focused on.
Would suggest that just getting a release out and starting from a clean slate would be useful: doing what we need for 1.10.
But clearly there are other things that would be beneficial.
Don: chicken and egg position: can’t commit to sprint until I know what will be in the sprint.
Incorporating Elastic might be compelling for our business case, for example, but other things might be harder to justify
Mike: Would like to work on the build process: may be difficult to justify at an individual institution, but have gotten a lot of feedback that it could be done a different way.
Andrew: Get additional topics on the table so they’re available as topics of conversation.
Benjamin: I can definitely participate in one of the sprints, but agree with Don that the time commitment would be dependent on the topic addressed. Elasticsearch would also be of interest to us here.
Authentication system is another possible topic.
Christian: A bit shy about dedicating time to the sprint, because the developers are not yet hired.
Ralph: The password thing might be a good one to start with. Good view into the system but not overly complex.
I would work on the sprint; also generally advocating the topic.
Don: can share a slide I did with Jim Blake on the benefits of Elastic. When you incorporate it you get pretty deep into the VIVO code. Would be a great opportunity to get not only another index but also to help us create documentation and to allow the rest of us to get under the hood into the layer that’s not that accessible.
Andrew: Yes, ideally these sprints would help expand capacity.
Andrew: Please do whatever you can to slice off time and indicate that time on the wiki.
Don: Andrew, is there a document out there where we can get ideas for sprints?
Under agenda item 5, relatively comprehensive document Mike put together: https://docs.google.com/document/d/1dddA9sPsJMAvfd6vS7tx5dsVYzBKWIqU8MUkRbIMClk/edit?usp=sharing . Commenting on the document is one relatively effective way to indicate interest. Could also translate it into a poll.
Huda: would suggest that we have a separate document for the sprint topics. Technical initiatives doc is probably too broad: in a sprint we will only do a portion of what is listed in that doc. As long as we link back to the technical initiatives document and say what initiative this is further breaking out, should be clear. But otherwise, the granularity won’t match up.
Andrew: Were a bunch of unmerged pull requests stuck in review. Reopened tickets and put them in the In Review state. Maybe there are others. Please do a review of tickets you are associated with to make sure they aren’t inappropriately closed or to do the review if in review.
6. Cloning / backing up / restoring a VIVO instance
Wiki pages lacking sufficient detail to do it successfully. Can take it to Slack: would be great to flesh out the details so someone can actually do this.
Tickets created in the last 30 days:
|
Tickets resolved in the last 30 days:
|
Bugs
 |