documentation: information on review process, PR experience, what to expect?

[fjmolinas]

Description

This has come up a couple of times on different discussions as well as at FOSDEM. Here is the summary from FOSDEM @chrysn sent down the mainling list.

* 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?

Would be nice to extend CONTRIBUTING to extend this, and maybe add it in the PR header template as well.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.