Proposal for RM 17.11 joubu

From Koha Wiki
Jump to navigation Jump to search

I (Jonathan Druart aka Joubu) propose to serve as Release Manager for the development cycle of the version 17.11 of Koha.

To me, the success of a release depends strongly on the involvement of everybody. I want to create a strong dynamic based on coordination, collaboration and communication.

Who am I?

I've worked as a developer for the Koha project since 2011 (5 years in the BibLibre team and now as an independent entity).

For the last 18 months, my community work has been sponsored by 3 partners: BibLibre, ByWater Solutions and PTFS Europe. This community work represents (a lot of) QA, (a bit of) community support (mailing lists and IRC), bug fixes and code improvement/maintenance.

I want to make it clear that these partners respect my independence and impartiality, and that they acknowledge my application as RM.

Task Force

The community

My first action will be to contact all the companies that provide support for Koha as well as the librarians that are involved on the mailing lists, bug tracker, IRC.

I want to motivate people that do not dare or know how to help. I want them to understand that it is important to be involved in the community. Both contributors and users will benefit from this dedication.

I will ask all the contributors how much time they are ready to dedicate to the project for documentation, bug fixes, signoff and wiki maintenance. Even a couple of hours per month dedicated to the projet is a huge help.

From a list of newbies that are willing to join and experienced people wishing to help, we will coordinate teams and dispatch work.

The Release Management team

A release manager cannot achieve much alone. They need a team around them to move the patches forward.

  • A strong and reliable QA team is essential to support the RM in their daily tasks.
  • Testers, obviously
  • RM assistants from another timezone will be a plus to offer a continuous support in case of urgent matters. They will also be in charge of pushing enhancements signed-off or QAed by the RM. Alex Sassmannshausen and Martin Renvoize are going to apply for this position.

Responsibilities

I would like people to shoulder responsibility for their contributions in the community, at the level at which they are capable of doing so.

  • If you are a developer or a librarian involved in one way or another in the Koha development process: you really should read the "What's on in koha-devel" email sent out regularly to the koha and the koha-devel mailing lists. These emails are a great way to keep with what is currently going on and what has been achieved recently. If you have only 10 minutes per month to dedicate to the project, please just read these emails. Their aim is to inform you about the important tasks and questions raised on our bug tracker.
  • Patch submitters are expected to follow their patch and assist testers/QAers by:
    • providing further information if requested
    • rebasing their patches in a reasonable time period - reactivity is the key for good communication and to a quick integration
    • taking care of possible fall-out resulting from the integration of their patches (e.g. fixing tests & providing quick bugfixes in case of regressions)
  • Regular contributors are expected to review and signoff patches from their pairs.
  • The QA team is responsible for a healthy QA queue. If you join the team, please make sure you will have time to dedicate to this job. The RM needs a reactive and reliable team behind them.
  • The responsibilities of the Release Manager are:
    • To create a vibrant dynamic around the project at every level
    • To coordinate the various tasks
    • To assign tasks - Examples of situations in which it would be very valuable to explicitly ask for feedback or to assign a task might be:
      • If a developer is an expert on a given topic the RM will ask them to review or give their opinions
      • If a regression is introduced, the author will file a new bug report and fix it. Without action from the author the patch might be reverted!

Goals

Goals will be defined with and depending on the people involved. Their needs, wishes, competences and, of course, dedication will permit us to know what we can accomplish. That is why it is important to see people with diverse competences involved.

Examples:

  • Stabilise and improve elastic search features
  • Get rid of CGI emulation and move to a Plack app
  • Refactoring - continue the work that is going on. Still a lot to do
  • Remove all the SQL queries to become DBMS agnosticism
  • Cache more things to improve performance
  • Make our tests suite even more robust
  • FRBR, BibFrame - How to move in the right direction?
  • REST API
  • Finish what has been deprecated earlier (non-XSLT view, GRS-1)
  • Further improve our already great documentation
  • etc.

Personally, in addition to the RM duties, I plan to continue what I have been doing: Enforcement of our coding guidelines, consolidation of our testing suite, rewriting of our legacy code (maintenance of our codebase), speed improvements, etc. And I am willing to help on anything else that needs more hands.

Workflow process

As everybody knows we lack of help for bug fixes and signoff. We need to make the workflow of our integration process more fluid and focus on bottlenecks. Going out of the QA team will give me more time to maintain our three biggest queues:

  • Needs Signoff - Give early feedback to contributors, to avoid patches that do not follow the guidelines
  • In discussion - Revive patches that need to be moved out of the discussion status
  • Failed QA - Rebase and/or fix QA failures for patches that need to be re-injected into the testing process

I also propose to bypass the QA step for:

  • small patches
  • critical (and small) bugs, if the community is not reactive enough

I hope it will make the job easier for regular reactive contributors to keep their motivation and energy at the highest level possible.

Communication / Motivation

Over the last 6 months we got ~20 different authors per month when we used to have ~30. We must help new contributors, and re-motivate/understand those who do no longer contribute. Giving early feedback to new contributors will ease their patches' integration and, hopefully, reduce the time the patches wait for reviews. The lack of reactivity leads to demotivation and endless rebases.

Here we could imagine several ways to "reward" testers (numbers of signoffs per releases on the about page, etc.) if it can be considered as motivating.

We could also make better use of social media (e.g. twitter) to announce meetings, upcoming features, news, etc.

Timeline

Koha 17.11 will be released end of November, if it is considered stable enough for release (i.e. if it has been thoroughly enough tested)

Retrieved from "https://wiki.koha-community.org/w/index.php?title=Proposal_for_RM_17.11_joubu&oldid=18546"