...
- 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 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 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.