Hi, Even though I understand the 'way it is going', I see two 'scenarios': - Projects like GNOME:Factory (which you mentioned and which I happen to be rather active in) => has a very small group of project maintainers, who are known to each other and that have a level of trust. A strict 4-eye principle is applied (none of us self-acks a request). So this does not fit the general 'issue' on this thread. It simply does not matter there. Projects like multimedia:libs, or even worse, games: a large group of project maintainers exist, Some are more active, some are less active. Typically, the 'less active ones' do not cause the 'trouble' (in my experience, they only 'care' for the few packages 'they' maintain). The large group can be a good thing, especially when people as a collective look after packages that are failing, maybe even after they update one library. The COLLECTIVE is supposed to maintain the PROJECT, which includes every and EACH package in this project. Now, there are scenarios where a small set of packages in the project were added 'as a best fit', but not with the intent to have 'everybody' maintain it without consulting 'the' maintainer.. which is exactly what is true for VLC, which lives in multimedia:libs. For me, generally, it's important that I know of changes there so that I can have a closer look also at my own BS-instance, which builds THE SAME package, with slight different dependenices (vlc-codecs package). Now, of course, every maintainer in multimedia:libs CAN accept this package (permission wise), but I 'added' myself as 'reviewer role' to the package. Which means, that only when all reviews passed (accept or decline) is the package ready for 'accepting' into the dev project (I happen to do them at the same time for this package... something done entirely different in GNOME:Factory for example). and THIS is the approach I would recommend to follow if there are packages you care that much about. Have the collective be able to look after it (once in a while, a PRJ maintainer might even fix a build) but have SRs go to review, assigned to you directly... and the workflow becomes clear. If THEN somebody STILL accepts a request that was clearly assigned to you for review, then I agree, it is time to roll up this discussion.. until then, let's use the technology at hand, configure it to our likings and let the eco system work to our advantage. Dominique