Time: 1:00 pm, Eastern Daylight Time (New York, GMT-04:00)
To join the online meeting:
Introduction - Andrew Woods
About 10 years with Duraspace (before it was even Duraspace)
Technical manager/lead for FEDORA for past several years
Helping to coordinate technical work and ensuring things move forward
Discussions ongoing regarding technical lead role (in general) in VIVO leadership circles
Community development and priorities
Data Distributor https://cul-it.github.io/vivo-data-distribution-api/
VIVO-1252 - Incorporate Cornell's DataDistributor API into core Vitro. RESOLVED
Export serialization option VIVO-1409 - Support serialization options in Jena2tools and jena3tools OPEN
Ralph: Do need someone good with code and community work. Several side projects ongoing but would be useful to see this code make its way back into the core code base.
Andrew: two needs = moving code forward as contributor, also code relevant to VIVO doesn’t always make its way back into core code base
Jim: Not sure if core code contributions are the way to go. Moved Data Distribution API out of major release code in order to spark discussion.
Everything brought into the core code becomes part of the ongoing maintenance burden.
Need to consider options in general. For example, Word Press themes don’t make it into the distribution necessarily, but there is a community area where community-developed themes are available/visible.
Ralph: Need accessibility and documentation. Having a true community extensions area within VIVO space where these two are available. Want to see progress with the core code.
Andrew: Being clear of what makes it into the core code. Having a clear framework for the extensions going in
Don: Contributor community has different levels. Very few people actually committing to Java code, more people working with .n3, Freemarker etc.
Huda: What do we want VIVO to be doing? In the past, VIVO’s purpose was to take Vitro and make it into an effective researcher profiling system. Would be good for future work to take into account the entire system, not just front end. Long term view for development.
Andrew: Two main tasks right now
What needs to happen to release 1.10/2.0?
What are the needs of the community in the long term?
Andrew: Rally development around sprints for feature development. Core maintenance may fall to Duraspace because unpaid community time can’t be expected. Would be good if an institution saw value in maintaining/sustaining VIVO and was willing to allocate their own developer time. Institutional buy-in.
Jim: We need a process for determining if code worked on by an individual should be committed. Andrew: Consensus among committer group (vetting ideas + reviewing code)
Developer meeting frequency
Proposal for weekly meetings during transition period
VIVO currently has Thursdays at 1 for 4 different monthly meetings (implementation, developer, ontology, and outreach/community)
Andrew to send out Doodle poll for weekly meeting time
No existing VIVO Slack channel, we should make one. Andrew to do.
Code review/pull request protocol
Consensus approach vs. single approver. Group prefers consensus approach.
Fedora API spec process: policy is documented. Majority of +1s, no vetos, 3 business day waiting period.
Current committers: https://wiki.duraspace.org/display/VIVO/VIVO+Committers
Approval process: preference for doing it publicly on Github
Tickets created in the last 30 days:
Tickets resolved in the last 30 days: