Koha Test Wiki MW Canasta on Koha Portainer

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 .

Project roles

From Koha Test Wiki MW Canasta on Koha Portainer
Jump to navigation Jump to search

This page describes the minimum responsibilities of various named roles in the Koha project.

Release manager

The release manager is the person 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

Leadership

  • 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

Communication

  • 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 maintainer

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

Communication

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

QA team

QA manager

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

Leadership

  • 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

Communication

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

Topic expert

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.

Accessibility advocate

Do you have an understanding of web accessibility or a special interest in making Koha the most accessible library system for the modern world? This role is for you...

Raise awareness of accessibility in the wider community

  • Advocate for new accessibility guidelines to ensure our development process keeps up with the changing world of accessible media
  • Advertise and promote the importance of accessibility at meetings and events
  • Help identify and report accessibility-related bugs
  • Help to arrange regular accessibility audits
  • Help to group together contributors with similar accessibility interests to ensure the highest chance of success when working on accessability bugs.

New proposed role for 21.05. Please see Accessibility advocate proposal

Bug wrangler

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.

Communication

  • 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!

Documentation team

Documentation manager

Manage the manual

  • Regularly check the release notes/patches pushed and add the new features and enhancements to the list of documentation changes required in Bugzilla (separate task for each release)
  • Review and respond to new documentation tasks added to Bugzilla
  • Coordinate the team members, this is especially important when the release date gets nearer
  • Communicate priorities
  • Review and merge the commits sent by your team on GitLab

Leadership

  • 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

Communication

  • 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
  • Provide regular updates (weekly) to the documentation team
  • Provide regular updates (monthly) to the Koha Community

See documentation management for more detailed guidance regarding the tasks above

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)
    • Learn how to edit the manual here: Editing_the_Koha_Manual
    • Check the documentation to-do on Bugzilla for suggestions on what to write about and ideas of where users are having trouble
    • Check the list of documentation changes required for the release and assign yourself tasks
  • Fix typos and spelling
  • Update screenshots
  • Validate that sections of the manual are still accurate

Communication

  • 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 Bugzilla

Website maintainer

koha-community.org is our front page to the world and should be well maintained. This role isn't necessarily about maintaining the website yourself, but it is about keeping an eye on it and contacting the relevant parties when you spot issues and suggesting fixes.

Wiki curator

These gentle people are responsible for the following tasks:

  • Keeping the wiki content organised and correct

IRC meeting facilitator

The community has general and development IRC meetings respectively every 1 month and 2 weeks. The goal of this new role (from 21.11 development cycle) would be to:

  • Prepare in advance
  • Chair
  • Keep track of the actions for the next meeting and ping individual to know the progress
  • Make a resume of the progress of the roadmap
  • Anticipate with the next meeting date (watch out the timezones)
  • Run the meeting script

Translation manager

translate.koha-community.org is the communities translation homepage and it needs to be well maintained. It is the job of the translation manager to ensure that this important area of Koha continues to work uninterrupted and that the workflows for undertaking translation and incorporating translations into the community projects are being undertaken and continue to function optimally. The translation manager may also choose to improve the status quo by enhancing workflows or adding components that can be translated by our toolchains. It is not their responsibility to undertake translation, merely to ensure the tools are as simple to use as possible for those doing so.

See translation server for more detailed guidance regarding managing the tasks above.

Packaging manager

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

Continuous integration infrastructure maintainer

Module maintainer

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

Wiki team

Wiki manager

The Koha wiki manager is responsible for the following tasks:

  • General administration of the wiki
  • Upgrading wiki software when required
  • Delegating tasks to other members of the wiki team

Wiki team member

The Wiki team members are responsible for the following tasks:

  • Helping the wiki manager with delegated tasks