...
- Mike- we don't want to spend a lot. We have a template. PLease Please provide comments.
- Julia - Anna offered to have her designer work on the report.
- Violeta - offers to help with the text.
...
- Andrew: Calls happen on Tuesdays at 11 am ET. It's not set in stone but good to have a consistent time.
- We talk about tickets/work in progress, posts to the listserv, encourage people to respond, sometimes we talk about special topics or have short presentations.
- Central point of communication for VIVO software development.
- Product evolution group is a separate effort.
- We're not seeing the new committers attend these calls.
- Julia: makes sense. I'm wondering what the difference is between ongoing development and sprints. I understand during sprints it's a focused effort with more people but there is other development that goes on between sprints.
- Andrew: ideally both of these types of dev happen. Ongoing, low level development is in line with strategic direction of the project. From VIVO leaders/steering there is a general commitment in ongoing dev to VIVO. Keeping a breast of development, bugs that exist, raising the need for features and saying we'll work on it but keep community in the loop. Sprints supplement that. Low level effort isn't normally sufficient to get features out the door that are priorities. Sprints rally support to meet goals and deadlines. Ongoing dev is more up keep.
- Mike: When I think about software and how it is created it sounds like these meetinsg meetings are operational. There are other processes attempted by VIVO over the course of the year. At the top level we have . strategy. What kind of software we want. Leads to statement of direction. We have that. Then we have architectural meetings, we're planning that. When we talk about features - they need to be designed. Features are coming forward that haven't been socialized. They're coming as completed work instead of a community designed effort. Same with product evolution. Their design work is unknown to the general dev group. TIB and Cornel are doing work privately. How do we have this process a community design process?
- Andrew - you're right. The design element is missing in the way things are structured now. There is also a bi-weekly call of VIVO committers. We have come closer to design on those calls. A bit more strategy.
- Mike - I think that's right. Maybe committers can be more proactive about engaging groups that are designing features.
- Julia – we don't want to create barriers to the committers. They have been boostrapping bootstraping themselves. We appreciate it but need more collaboration.
- Andrew: There is opportunity to dedicate a meeting a month for design. It might be as simple as encouraging people to participate in this. There are cases where features are showing up as finished products and no opportunity for community input. In those cases we could ask for anyone in that situation. There's case of priority features in sprints on a timeline.
- Erin - Islandora example - they created a policy that 3 implementers need to use a feature before it can be committed to core.
- Mike: I think this is a good problem. We know these people. We can talk to them. We don't need to create new documentation requirements. We want to reap the benefit of their thinking ahead of code review.
- Julia - I also wanted to talk about how to get new developers involved in those calls. One more question, what does it mean to become a contributor, officially?
- Andrew - there was some sorting out to do around what it meant actually. Fundamentally where we landed on this is there is a Github organization and VIVO committers are responsible for it and getting releases out from it. Also need to be helpful participant, attending meetings, responding to posts on listserv. The process to become a committer is getting involved in calls and showing commitment. If I were to ask those who attend the calls, 'who will be the next committer?' I think everyone would have the same response. Ralph was a near unanimous choice. He helps with testing and release. He's a community builder.
- Mike - knowledgeable of OSS projects, insightful.
- Julia - we need to grant rights?
- Andrew - yes. Those rights are granted by me or Mike.
VIVO Debt
- Julia: This document is a summary of the financials from 2013-2017. 2018 isn't closed yet. We need to talk about the debt that VIVO incurred over the years. In general, the debt has come from our membership goals. We set them for ourselves and with DuraSpace. They've been too high for us. We want to talk about this in the Leadership Group meeting on January 4. The DuraSpace board is going to talk about this as well - about how to settle up the debt. Does anyone have any questions.
- Mike: My take has already been expressed to the DS board at an official meeting. A month the board treasurer asked that we discuss this. In 2018 we are projecting more than 90k in net income. Prior to this year we did not have control of our budget. I saw it happen but did not have control. Once we had financial control we did a good job. The notion of settling the debt is offensive to me. I don't think it should be discussed. That's my view of it. But the question has been raised and we are discussing it. This is why I stepped away from DuraSpace and this is why we have the MOU.
- Julia: We would really like to find a way to deal with this and facilitate a good discussion so we can move on. My intension in this meeting is to ask if steerers have questions about the spreadsheet and we can compile them and send them to Val and present the answers in the Jan 4 meeting.
- Alex - I'm not a member. So I don't think I can talk about this.
- Julia - not necessary if you have questions. The document was emailed ahead of this meeting. I will resend it. Please email me your questions.
- Andrew - it seems that what you're suggesting, Mike, we start fresh in 2018. And call it a wash before. That's my understand of what you're saying. I would also say that there were expenses and revenue from 2013-2017 and that expenses were unmanaged. Presumably that some were valid and some were invalid. Is there value in trying to tease apart the two. For example, the former tech lead worked on the project and was paid.
- Mike - I think that's right. Tech lead and my time and we had a travel budget that we controlled. But other expenditures were uncontrolled. We said we would do we did. That's the way the project runs.
- Erin - how budgets are approved would be good context for leaders and steerers.
- ACTION - Julia will email the debt document to the group.