From Koha Wiki
This page describes the minimum responsibilities of various named roles in the Koha project.
The release manager is the man (woman) at the top. Their job is to manage all the code going into the current development release and be a guiding figure for the release team during their cycle in tenure.
Manage the Passed QA queue (which includes)
- Review patch for guidelines
- Test patches (following test plans)
- If needed do DBrev updates and remove the atomic update
- Pushing patches to master
- Lead by example, encouraging good code and following guidelines
- Strive to improve procedures and processes
- Help guide the final decision on contentious issues and don't stand on the sidelines
- Listen to those around you and alleviate concerns
- Encourage joined up thinking and work closely with the release maintainers and quality assurance team
- Should clearly communicate timings on release (like slush and/or freeze)
- Try to attend as many meetings as possible (IRC)
- At minimum aim to release a monthly RM newsletter of what's going on
- Be available for people to approach with questions.
ASK for help! Lots of patches - lots of code - sometimes thing are missed ;)
See release management for more detailed guidance regarding the tasks above
Release manager assistants
Sometimes a release manager may require a bit of assistance and they want to have a 'go to' person to delegate tasks to. This role can involve any of the above duties but on a less full-time basis, perhaps covering the release manager when they're on annual leave for example.
This is also a great way to shadow a release manager if you're hoping to stand for that role yourself at some point in the future.
Release maintainers do the task of keeping the stable releases maintained, applying all appropriate bugfixes and making regular releases.
Manage the 'Pushed to X' queue (which includes)
- Watching the branch above you and making the decision of whether to backport a fix to your branch or not
- Updating the status of bugs on Bugzilla to inform the community of your progress
- Making regular maintenance releases with those bugfixes
- Orchestrating security releases if they are required
- Bug wrangling bugs that are reported against your version
- Should clearly communicate timings on release (string freeze and release)
- Try to attend as many meetings as possible (you have a standing slot in the meetings to give updates)
- Be available for people to approach with questions.
ASK for help! Lots of patches - lots of code - sometimes thing are missed, sometimes things are not trivial to backport.
See release maintanence for more detailed guidance regarding the tasks above
Release maintainer assistants
Sometimes a release maintainer may require a bit of assistance and they want to have a 'go to' person to delegate tasks to. This role can involve any of the above duties but on a less full-time basis, perhaps covering the release maintainer when they're on annual leave for example.
This is also a great way to shadow a release maintainer if you're hoping to stand for that role yourself at some point in the future.
The quality assurance manager is a really important role in the Koha community; this person helps to coordinate the quality assurance of every piece of code that eventually makes its way into the codebase.
Manage the queues (which includes)
- Keeping an eye on the NSO, NQA and PQA numbers and directing effort as required to keep the numbers manageable
- Identify bugs that need attention and draw team members attention to them (slow moving, dwindling discussion, blocked bugs etc)
- Identify and highlight high profile bugs (security bugs, bugs that fix Jenkins failures)
- Coordinate efforts on bugs with large dependency trees
- Lead by example, your also a central member of the QA Team, so keep QAing.
- Strive to improve quality assurance procedures, suggesting improvements and removing roadblocks wherever possible
- Strive to improve documentation of quality assurance procedures and coding guidelines
- Strive to improve automated quality assurance tools wherever possible
- Maintain a close relationship with the release manager and release maintainers and help them in achieving their respective goals and responsibilities.
- Attempt to foresee and prevent burn out of individual team members
- Identify prospective QA team recruits and encourage them to join the team next cycle
- Support and train new QA team members
- Try to regularly attend meetings and update the community on progress
- Bring focus to the quality assurance team and drive certain area's forward
- Encourage quality assurance team members to be vigilant and draw attention to new or existing guidelines they appear to be missing (translation etc)
- Encourage full participation of the QA Team throughout the cycle, focusing on motivation.
QA team member
This vitally important team is always looking for new recruits! If you've got an eye for detail, or you're a tester who likes rolling up their sleeves a little bit and looking at how a piece of code works, then we'd love to hear from you.
Help manage the SO queue (which includes)
- Quality Assuring Bugs
- Keeping and eye on the SO queue and picking bugs to QA
- Listening to the quality assurance manager and taking on bugs when requested
Don't be afraid to ask for a second opinion.
Failing a bug is always OK, but try to be constructive about it. It's better to fail a bug with a good reason than to quietly leave it for someone else, as a failure is a step forwards towards a future pass.
Do you know one particular area of koha better than the rest? Are you the 'go to' guy (or gal) for SIP2, EDI, Acquisitions or another area of Koha? We'd like to hear from you too.
Be the formal 'go to' person for an area of the koha
- A sign-off by you in your area of expertise will carry more weight when it comes to the QA team looking at the bug
- Strive to drive an area of koha forward
- Be open to communications regarding your subject area, whether it be guiding new coders or answering questions the qa team ask after submission
- Be open to the opportunity to quality assure bugs if/when asked.
We can always do with more bug wranglers! A bug wrangler loves to keep things tidy and Bugzilla is their outlet: They help manage the list, identifying duplicates, promoting bugs to specialists and finding people to do signoffs and testing.
Regularly reviewing Bugzilla (looking out for)
- Duplicate bugs (mark them as such)
- Slow moving bugs (highlighting them and encouraging signoff, qa or discussion)
- Occasional cleaning (marking bugs resolved if required)
- Gathering proposals for enhancements (including encouraging people to write RFC's)
- Fixing patch submissions when names or comments do not match rules.
- Close invalid bugs and test validity of very old bugs.
- Review patches and ask for automated testing whenever possible.
- Try to attend meetings and highlight things you've found whilst doing the above.
- Use the newsletter to showcase progress, highlight what's being worked up and draw attention to issues of interest.
- Help organize and encourage people to participate in Global bug squashing days
Everyone is invited to this party, we need you!
Manage the manual
- Regularly check the release notes and add the new features and enhancements as tasks in the the Taiga project for the team members
- Coordinate the team members, this is especially important when the release date gets nearer
- Review and merge the commits sent by your team on Gitlab
- Lead by example, strive to write quality documentation
- Strive to improve editing procedures, suggesting improvements and removing roadblocks wherever possible
- Motivate and support your team members, focusing on the expertise of each person
- Identify prospective documentation team recruits and encourage them to join the team next cycle
- Support and train new documentation team members
- To the extent possible, the documentation manager is expected to be at documentation IRC meetings and chair them
- Check the docs mailing list and answer questions whenever possible
- Support your team members, answer their questions
Documentation team member
The documentation team is in charge of keeping the manual up-to-date with all the new features and enhancements the developers add to Koha.
Document all the things!
- Try out new features or enhancements and write step-by-step instructions for end-users (library staff)
- Fix typos and spelling
- Update screenshots
- Validate that sections of the manual are still accurate
- Try to attend the documentation meetings on IRC (meetings are monthly)
- Inform other team members of manual sections that need love and attention, add them as tasks in Taiga
The Koha packaging manager is responsible for the following tasks:
- Creating Debian packages for stable Koha releases and uploading them to debian.koha-community.org
- Reviewing bug reports related to packaging
The Koha packaging manager shares, along with other interested Koha developers, responsibility for:
- Advising other Koha developers on packaging and dependency issues
- Improving the Koha instance management scripts
The Koha packaging manager may also, but is not obligated to:
- Create packages for new Koha dependencies and submit them to the Debian project. However, creating such packages and shepherding them through the Debian process is primarily the responsibility of the developer who proposes to add a new dependency. Furthermore, such packages must meet Debian's licensing requirements.
- Generate and upload packages of unstable Koha releases
This role never really took off and has majority been replaced by 'Topic Experts' below.
Lots of ideas were discussed over here but in reality, we never reached a consensus as to what extent a module maintainer contributed to efforts.