|
Fedora technical plans - gain consensus, highlight vision for technical work and how the pieces fit together.
Scheduling a code sprint to align the current Fedora implementation with the API spec - align community implementation with API spec, need at minimum three institutions who can commit resources to the sprint, lay ground work to open up to broader community. Need to have specific dates to engage with committers on those dates. For the leaders who might be interested in the broader plan and this specific work towards API spec, we need commitments from leaders. Call for participation. Will also send a note to Fedora leaders to approach institution. Question: Do we have a sense for timeline of work? Start work after OR, July, August, and September. Amherst voiced interest, need to confirm resources and commitment. Sprint just completed with import/export succeeded because there was a diverse work team, developers, testers, documenters. The ask isn't just exclusively for developers. Question: When API goes out in June will there be a solicitation for feedback? Getting feedback will lengthen timeline. Need to review for accuracy and to confirm they meet clients' needs. Server side feed back, those implementing. Context for specification work can be found here: https://github.com/fcrepo/fcrepo-specification/wiki/Fedora-API-Specification-Charter
First public working draft June 20th. As new people come onto leaders are they invited to the channel on Slack? Several voiced this is not happening. Need to operationalize. When a request goes out to leaders, would be helpful if it was contextualized, verified.
Moving towards institutional developer commitments - In Fedora 3.x era commitment more personal, did not seem like this was written into job descriptions and responsibilities. Ppl worked on this after office hours. Contributing to single projects vs. a suite of OSS. Would be helpful if 'on the ground contributions' development/testing, also helpful to have some time allocated to Fedora and other OSS projects of value to the community. Andrew notes some institutions reserve Friday for "Open Source Day". Majority of contributors are ad hoc. Need to operationalize this at your institutions. How can we increase time contributions at your institutions? Support voiced for "Open Source Day". Each institution needs to figure how they can contribute. Northwestern mandates that each developer has to participate in at least one sprint annually, ensures long-term sustainability of projects. What are the barriers to such approaches? Harder at institutions with fewer human resources. More organizations like this than not. Have to make this an institutional priority. Public universities may have the advantage making it part of the ethos. If you are a consumer but not a contributor, limits the reach of the project. Smaller institutions - how do we get orgs that don't have developers to contribute? Who is doing testing? How do we know it's working? How can these orgs help without contributing development? QA, testing?, can we have other ppl deploy in production. Support for this voiced. Hackdoc model, consortial approach getting help with testing, documentation. Need to articulate how orgs can contribute without coding - will lead to coding. Need to clarify non-developer roles: dev ops, testing, documenting, contextualize around how to engage. Open question around tactics of how to make these roles known, communicated. Maybe add to monthly newsletter. If such clarity exists, then might be easier to allocate time (weekly/monthly) to project support. Where is development time most relevant, useful? Maybe a manager component, a campaign to ppl who manage development group. Advise managers on how to coordinate and prioritize work at their institutions? Have been some obstacles that have discouraged some of the community. Have addressed these issues and hope that community is more welcoming.
Agenda for OR2017 Fedora LG Meeting - Please have a look and provide feedback!
Membership ideas from Task Force
Vote on Fedora/Islandora/Hydra proposals for DLF!
Need to clearly define roles for contributors, new leaders should be able to see how to engage with a minimum amount of knowledge. Clarifies commitment for manager = understands and can align work with their institution's mission.