Yes, which is why the same concern is listed in the “drawbacks” section at the end. As I also wrote there, the whole idea is to add more people that currently fall short, for one reason or another, of the role of “maintainer”, so we don’t get gatekeepers.
Also, this is really the least “bureaucratic” process possible, unless by “bureaucratic” you mean “something that doesn’t rest on the narrow shoulders of a single person”, in which case we are just winding up the ticking clock until GNOME is maintained by three people in a trenchcoat. Don’t know if you noticed, by the amount of “maintainers” hasn’t been skyrocketing, as of late.
Then why don’t have more people share this load, without necessarily having Red Hat pay for them?
Also, this whole section is puzzling, to me, to a degree that I barely can fathom:
Do you think I review all the merge requests in GLib, GTK, Pango, GdkPixbuf, gobject-introspection, or any other library I am even tangentially involved in? Because I don’t. There are people that know more than me about aspects of a lot of code bases for which I am nominally a maintainer.
If you are knowledgeable in the GDM bits, I assume you’re going to feel confident in reviewing code that touches GNOME Shell’s use of GDM.
This proposal is not meant to create teams of people that know the whole code base that falls under their area of interest—though it would be great if more people knew more parts of GNOME, which is why more people should be involved in this. What this proposal does is:
- create teams of people with shared interests, responsible for projects that fall under those areas, and have them talk to each other in a reasonably public setting whenever they want to change something in GNOME
- create a steering committee from representatives of those teams that work on global vision, and act as a referee when teams propose changes
The fiefdom problem is solved not when we don’t have people that know a project very well: it’s solved when those people are not in the position of blocking things from happening, or dumping a whole change as a fait accompli without telling anybody else.
On a longer scale, this proposal create a culture of sharing the load, with the ability of including more people to propose and discuss changes.