Talk:What does a module maintainer do
From Koha Wiki
- By module maintainer, I mean somebody who is an expert in an area of functionatlity (e.g., reports) and who agrees to actively maintain a Git tree of vetted patches related to that module. If a module maintainer does a good job, it opens up the possiblity of the RM being able to pull it a group of branches from the maintainer's tree in one fell swoop, confident that the module maintainer has thoroughly tested it. Over time, it might be possible that a trusted module maintainer would get authorization to push patches for their module directly to master.
- Trust a team of elected Module Maintainers (at least) for critical modules maintenance. [...] Even when the RM retains the ultimate right to decide what does or does not get pushed to master, I’d encourage people from the QA team and past release managers/maintainers to become Module Maintainers. Communication would be key, and pull-requests from topic branches would be my ultimate goal for this term.
- If the MM is also part of the QA team, he could QA a patch (under the current conditions) and push it to master or another branch (as agreed by RM). But I do not think that this MM should only QA patches for his module; and in the same line another QAer should be free to QA patches for this module. (There is additional value when different QAers look at changes in one module.)
- If the MM is not part of the QA team, he should just wait until the patch has been QAed. When it reaches the PQA queue, he can pick it up.
Ideas and thoughts (Paul P)
- I think that a MM is, by nature, member of the QA team for the module he is responsible of. The RM is also a member of the QA team, so the same should apply for MM
- Maybe we could have a different workflow for new features/enhancements and bugfixes ? For example: bugfixes => the MM can push onto master / newfeatures-enhancements => the MM puch on a branch
- do we want MM for modules "only" (acquisitions, cataloguing, packaging,...) or do we want also transversal MM (templating, MySQL optimisation, ...) ?
Thoughts from Chris C
I don't see the Module maintainers as being a short cut from QA, I for one will not be pushing anything that hasn't passed QA from another QA member. I see the role as helping the RM, pushing things to help keep the passed QA queue low, not looking at items in the signed off queue.
Thoughts from Katrin F
I agree with Chris and Marcel's last thought here and think that the MMs should pick up, once the patches have gone through QA.
Answer to Chris & Katrin comments from Paul P
In this case, MM should be able to push into master. Otherwise, which responsibility does a MM really endorse ? Sounds we're just adding a step on the workflow (need signoff => signed off => QA-ed => MM-ed => pushed).
Answer to Paul P
Exactly, MM should be able to push to master, or to a branch that is merged to master, but they should not skip the QA step, just like the RM shouldn't.
needs signoff => signed off => passed qa => pushed (by RM or MM) all being different people each step, the MM are there to keep the passed qa queue low
Thoughts from Galen
I envision the role of a module maintainer as including the following. I should emphasize that this is /not/ a narrowly defined role.
- Somebody empowered to push patches to master that fall within specific areas.
- However, this is conditional - the RM has to have the right to tell an MM to not push and instead make pull requests for the RM to review.
- In other words, the MM serves at the pleasure of **both** the community and the RM.
- Somebody who acts as additional QA, similar to what I've done as RM
- Somebody who assumes responsibility for improving a module, but
- Seeking out patches
- Performing signoffs (but the usual rule about QA review applies)
- Writing bugfixes and performing janitorial work (again, the usual signoff and QA rules apply)
A successful MM doesn't have to do /all/ of that, but should view themselves as taking responsibility for a module first, not just helping the RM to clear the PQA queue.
Thoughts from Chris N
I see the role of a module maintainer as encompansing the same duties and prerogatives as the RM within the scope of a given module, with the RM having the final say as to what is/is not pushed.