Hi all,
At FOSDEM I attended a talk about how Easybuild simplified their contribution process[1] (recording and slides available). The short story is that they have added functionality to their tooling to integrate with Github to simplify some of the repetitive tasks for contributors and maintainers. I think some of their ideas can be adapted to RIOT, mostly the points about easing maintainer burden.
1. Have Murdock comment on PR's on (some) build failures. The goal here is to give the contributor a nudge that the build failed. Currently an inexperienced contributor might miss the small red cross indicating build failure. Having Murdock comment on the PR about the build failure and maybe even with a short explanation why the build probably failed could increase contributor responsiveness while removing the need to have maintainers poke the contributor and having to explain why the build failed.
2. Automated test uploading and reporting. The idea here is to have a script that executes a test and uploads the result to a gist and attach it with a comment to a PR/issue. This would ease test failure/success reporting. This way we can provide a default template to provide all relevant information (toolchain versions, build log, test output etc.). For a contributor it should be easier to report test failure for issues, while for maintainers it becomes easier to report test success/failures to reviewed PRs.
3. Documentation about the directory tree. This is about having documentation about what can be found where in the directory structure. Mostly to prevent new contributors from having to search around in the directory tree. Most parts of the directory tree is quite obvious, but I think it can help the inexperienced developer to have some guide for this. Not sure whether this already exists though.
4. Skeleton drivers: In my opinion it should be as easy as possible to add simple sensor drivers to RIOT. If a template-like skeleton dummy driver is added which can simply be copied and filled in for a new sensor, the contribution threshold could be lowered. Mind that this is aimed at the simple I2C/SPI drivers which can be implemented with not much more than init and get functions (something like the jc42 sensor driver).
A lot more menial tasks of reviewing can be reduced of course, for example, a scripts to check out a PR in a different directory, and as Kaspar already proposed, a script to create backport PRs[2].
What I would propose is having some script, a riot.{sh,py} to handle the maintainer automation together with point number 2. Point 4 could relative simple be added as a driver with tests. Number 1 probably requires Murdock to be extended, but could be valuable to have. Number 3 would have to be added to the Doxygen together with a link in the readme.
Regards, Koen
[1]: https://fosdem.org/2018/schedule/event/contributor_automation/ [2]: https://github.com/RIOT-OS/RIOT/issues/8523