[Qgis-psc] Request for appointing a formal release "traffic controller" role

[Nyall Dawson]

Hi PSC,

I'd like to raise the notion that qgis.org appoint a formal position
for a release "traffic controller". This role would be responsible
for:

1. Making the final call on what is suitable for backporting to stable releases
2. Guide formal policy regarding the different stages in the lifetime
of an LTR release, and develop written guidelines on what is
acceptable to backport at different patch releases for an LTR
3. Make the final call on feature freeze exemptions during a
pre-release freeze period.

Some clarifications:
- This role would be distinct from the release manager position, which
is currently responsible for making QGIS releases, release packaging
and release cycles. This would be a time-intensive role, and I don't
think it should be added to the already (time-intensive) duties of the
release manager position.
- It would be a highly technical, very hands-on role, requiring
**daily/bi-daily** monitoring of the pull request queue and issue
tracker and full knowledge across all different parts of the QGIS
codebase and the interplay between them (and the risks associated with
changes). It is NOT a "project manager for QGIS" type role!
- It would be a formal community role appointed by PSC, not a position
on the PSC/board itself

I'm raising this now after reflecting on the recent informal practice
that Matthias Kuhn and I have been trialling where non-crash,
non-data-corruption, non-trivial fixes get put into a "time delay"
before being allowed to included in an LTR patch release. (see
https://github.com/qgis/QGIS/pull/36718,
https://github.com/qgis/QGIS/pull/36812). By doing this, we ensure
that these fixes have exposure in a standard (non LTR) release for at
least one month before they get included in the LTR release. The
intention is to dramatically reduce the risk of regressions being
introduced in the middle of an LTR release. (When this happens, it
undermines user/enterprise confidence in the LTR process and reflects
poorly on QGIS). This is a completely informal policy we developed and
wanted to trial, and while I totally stand behind it and think it's a
great way approach it makes me nervous that Matthias and I have
basically just forced this policy ourselves. See
https://github.com/qgis/QGIS/pull/36718#issuecomment-639428003 for
discussion on this whether this policy is acceptable or not.

IMO, suitable candidates would be developers with extensive experience
across a whole range of areas of the QGIS code, and demonstrated
history of timely reviews and responses to comments on github. I would
suggest that suitable candidates, (based on activity on github over
the past 12+ months and commits ranging across all areas of QGIS) are:
- Matthias
- Alessandro
- Denis
- (myself)

Thanks for your consideration!
Nyall