Hi,

On Fri, Jan 31, 2020 at 03:55:08PM +0100, Koen Zandberg wrote:
> For those of us attending FOSDEM this year, I plan to grab a BoF room
> time slot to have a small RIOT meet-up.

I've taken some notes on this:

After we've finished admiring his PineTime, discussion started about fields
which we could improve in RIOT, with a focus on the input RIOT users and
newcomers. (Please apologize my sketchy notes)

* Documentation
  * Document modules (and make them discoverable)
  * Document how to use in them, in addition to what-are-its internals
  * Is Doxygen sufficient for this purpose? There was a PR to Sphinx
    some time ago, but would such a migration even feasible?
  * Grouping of drivers and/or examples in documentation and paths
  * "When developing an X, how do I..." for X in application, driver
    etc.
  * Module dependencies, esp. how they are done, and pseudomoldules (and
    which are there?)
    * Gaƫtan wrote basic doc on what a module is ... where is it? is it
      sufficient?
  * How are networks configured?
  * Many of those are currently solved by people coming to IRC / Matrix
  * Document environment variables inside the makefile. BOARDSDIR?
    EXTERNAL_MODULES_DIR? Make them searchable.
* PR experience: PR workflow is insufficiently described in
  CONTRIBUTING, some relevant information is in the maintainer
  documentation ("Why doesn't murdock build?")
  * PRs not being responded to. Use GitHub code owners file (even though
    we call it something else, but that's their file name)?
    * Preselection of PRs? Making someone feel responsible for code?
  * Run CI for PRs if nothing else running?
    * security implications
  * "When I got an ACK, why isn't it merged immediately?" Maybe have
    murdock reply to PRs on what is required?
  * uncrustify -- What do I need to address, what is a suggestion, what
    will maintainers enforce?
  * When is a "*ping*" OK, is it encouraged, etc.? Ping whom?
  * More often, for annoying little stuff, push to contributor branch
    (if allowed by contributer)?
  * How do people who did some comments stay in the reviewers list? Whom
    to add, what happens if nobody is assigned after triage when someone
    removed themselves?
* The dependency graph is not accessible: There can't be a `make
  info-module-tree`.
  * When will we run into make limitations? Won't need to replace make
    for everything, just for determining USE_MODULES.
  * Defaults for pseudomodules, and optional orders of preferences?
    stdio_cdc_acm vs stdio_uart etc

This certainly doesn't cover all topics touched, and might even have
missed proposed solutions, but might help spark further discussion
and/or identify points where improvement would be quite welcome.

KR
chrysn

-- 
I shouldn't have written all those tank programs.
  -- Kevin Flynn

Attachment: signature.asc
Description: PGP signature

_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Reply via email to