Test major Koha Wiki changes or bug fixes here without fear of breaking the production wiki.
For the current Koha Wiki, visit https://wiki.koha-community.org .Proposal for RM 22 11 tcohen
This is my proposal to serve as Release Manager for the Koha 22.11 cycle.
TL;DR
Have an awesome cycle where we all accomplish our goals. And be happy :-D
Overview
The Koha community has a well established workflow for test-driven development. I’d like to see our team continue with this solid approach of cooperative development, finding out where the bottlenecks are and providing a workaround where needed. My main goals if elected would be:
- Promote the adoption of (yet more) coding guidelines and improve our onboarding docs for new developers.
- Heavily rely on module maintainers.
- We are getting into speed with the codebase modernization: the API is getting interesting, code is being actively moved to our OO namespace with good results in terms of maintainability and is well tested now.
- Discuss ways to attract new developers, with new POV, specially now we have started the transition into using new tools like Vue.js.
Release management: a team
There's a lot of people in the QA team, and that's exciting. I will count on the QA team manager for prioritizing work, and will try to have direct contact with support providers so they also prioritize bug fixes more consistently.
Major goals
- On the 22.05 release, and notably during the hackfest, a bunch of devs put our grips on the great background jobs infrastructure Jonathan added (kudos for Joubu). I would like to encourage more work in the area so we entirely remove the *need* for CGI tasks. There's still some work to be done on parallel excecution.
- Vue.js integration. Will keep a close look at the work being done on ERM and organize meetings to discuss technical decisions and their consequences. I'd like someone to pick on the main admin page to move it into using Vue.js as well.
- There's an open bug for merging reserves and old_reserves. I'd like to see that pushed early next cycle, along with the issues/old_issues counterpart.
Timeline
- I’d keep the current 6-month timeline for the release