Divide and conquer governance

[patrickelectric]

I believe that we should do a transition to a more distributed governance of QGC, with small groups being responsible for individual subsystems. This should help speed up development in a sustainable way.
We could have, for example:

• CMake build system: @patrickelectric, @dagar
  • QMake build system (we are planning to phase this out): @patrickelectric, @dagar
• MAVLink support: Someone the third (TODO: find maintainer, possibly someone with overlap with MAVLink dev call)
• CI: @dagar
  • We are starting moving to containers and a build agnostic of CI infrastructure
  • @dagar will figure out Android and Linux
  • (TODO: find help for Windows and macOS)
• Thermal camera:
  • ping @dogmaphobic to see if he wants to do it
• ROV: Will
• Video: @patrickelectric
  • Look for a maintainer that is invested in making sure this works possibly from a company that depends on QGC
• PX4 Configuration Tooling Support: @dagar, @LorenzMeier, @bkueng
  ...

That way, each group could merge PRs in their areas, while still respecting the other's areas and responsibilities. We would have more people reviewing and merging, improving QGC development and workflow.
To be sure we don't step on each other's toes, we could make sure these groups have at least one member of each interested Company or a cross review process.

[dagar]

I'd like to be a bit more involved and get cmake fully supported (for my own sanity), then get all of the CI and deployment handled in that world.

I'll also be on the hook for PX4, although as much as possible I'm interested in QGC being flight stack agnostic (Mavlink common).

[LorenzMeier]

The proposal is great! While I'm all for component maintainers, I want to be clear that at the end there will still be a BDFL decision line for the grand scheme of things, as we're otherwise getting into decision deadlocks - I've seen this now often enough where we tried other models that I personally came back around full circle.

This is in particular important as job number one will be in 2021 to focus on what we support so that the (limited) time and energy we have can be focused around a core set of activities that can be supported. Part of that is a more clear cut set of video support, another part is that we will continue on the path or supporting the MAVLink standard and eventually only the MAVLink standard plus (externally maintained) plugins. Anything else is too much work and not sustainable.

[cbjornram]

Just a short thought I got after the bi-weekly meeting today where there was a question about recent UI changes and how those decisions are made. Should there be one of these small groups maintaining UI-related changes/PRs/discussions? Or would that be poor time/resource prioritization for the time being?

[jaxxzer]

Joystick code is one that still requires regular maintenance. @rjehangir and myself have contributed a lot to it, so we could assume responsibility over that, too.