In short: Great proposal, Galen. +1 for module maintainers, -1 for master branch committers :) To be explained:
> 2. Experimenting with the structure of the release team to spread the work > and knowledge around. I would not favor too much experimenting here for continuity.. We should not change workflow every other release (or new RM). Instead of forming a new group of master branch committers, I think that the RM should only push patches. But he should be allowed to delegate his responsibility of checking a patch to a module maintainer. A second signoff from the module maintainer could lighten the load for QA and RM. If some module maintainers would be part of the QA team, that would be even better. Note that the workload for QA was made higher during the last release, proven by a growing signed-off-queue. Instead of more master branch committers making final decisions, the QAer could/should ask for more feedback (from fellow QAers and module maintainers) during the process when some patch raises doubts. If the RM still doubts after that, my idea should be: ask the community by mailing the dev list. (These cases should be exceptional.) Marcel _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
