Another two side notes: Even if there are maintainers, if for instance there's a security issue in module X the entire PMC will be held accountable for fixing it. So for instance the maintainer being offline is no excuse for not taking care of it. "That's not my issue" is not a valid answer.
Even if there are maintainers this still means other committers continue to have a say in reviewing that modules code even if they aren't maintainers. Also make sure that what you write into the maintainer docs reflects reality and keep things updated. Otherwise you risk things falling through the cracks. Think twice or more about establishing anything that could encourage people to get in touch with maintainers directly instead of talking with the project as a whole via its mailing lists (and issues/ PRs mapped to mailing lists). Getting rid of project content from your inbox is incredibly hard once you want to be less involved with the project. From a projects perspective extracting knowledge hidden in private inboxes is neigh impossible after the fact. (I have been burnt with the above more than once, happy to share the story of anyone is interested in listening.) Stepping down from my soap box, Isabel Am 9. Januar 2018 09:05:50 MEZ schrieb Sebastian <ssc.o...@googlemail.com>: >One side note on the language used here: there are no "owners" of >packages in Apache projects, the community owns the code as a whole. >You >probably meant maintainer instead of owner. > >Best, >Sebastian > >On 09.01.2018 08:24, YiZhi Liu wrote: >> +1 for adding @CodingCat (Nan Zhu) as owner of Scala package. >> >> 2018-01-08 21:58 GMT-08:00 Mu Li <muli....@gmail.com>: >> >>> It has been a while for discussing having maintainers for individual >>> modules. A maintainer for a module will be the main person who >reviews and >>> approves PRs contributed to that module. >>> >>> Currently, some maintainers are listed in the file CODEOWNERS >>> <https://github.com/apache/incubator-mxnet/blob/master/CODEOWNERS>: >>> >>> # Owners of Apache MXNet >>> # Global owners >>> * @apache/mxnet-committers >>> # Owners of language bindings >>> R-package/* @thirdwing >>> scala-package/* @javelinjs >>> perl-package/* @sergeykolychev >>> # CMake owners >>> CMakeLists.txt @cjolivier01 >>> cmake/* @cjolivier01 >>> >>> However, this list is incomplete. This document proposes how to >partition >>> mxnet codes into modules and put tentative maintainers for each >module. >>> >>> - I tried to select the activate contributor who contributed >most to the >>> module, not the new contributor who is going to work for it. But >I may >>> be >>> outdated. >>> - Code review is not easy. So maintainers may need help at the >>> beginning. >>> - Eric (@piiswrong) did most PR reviews, so I didn't put his >name on >>> every module. >>> >>> Any suggestion is welcome. >>> FrontendPYTHON: @szha >>> >>> python/ >>> >>> R: @thirdwing @hetong007 >>> >>> R-package/ >>> >>> SCALA: @CodingCat @javelinjs >>> >>> scala-package/ >>> >>> PERL@sergeykolychev >>> >>> perl-package/ >>> >>> C++? >>> >>> cpp-package/ >>> >>> MATLAB: DEPRECATE IT? >>> >>> matlab/ >>> >>> AMALGAMATION: DEPRECATE IT? >>> >>> amalgamation/ >>> >>> Backend@reminisce @eric-haibin-lin >>> >>> include/ >>> src/ >>> >>> Build@cjolivier01 >>> >>> docker/ >>> docker_multiarch/ >>> make/ >>> Makefile >>> cmake/ >>> CMakeLists.txt >>> setup-utils/ >>> prepare_mkl.sh >>> >>> Test@marcoabreu >>> >>> tests/ >>> Jenkinsfile >>> >>> Doc & Website@kevinthesun >>> >>> docs/ >>> >>> ExamplesNot sure, since we have a lot of contributors here. We >probably >>> need to remove low quality examples and assign one maintainer for >each of >>> the rest. >>> >>> example/ >>> >>> ToolsNot sure as well, since we have a bunch of things there. >Probably need >>> to the same thing as examples >>> >>> tools/ >>> plugin/ >>> >>> AppendixLines of codes added into each folder on the last two >months: >>> Lines of codes added into example/ >>> Lines of codes added into src/ >>> >> >> >> -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
