These people would be the gatekeepers. They would issue regular, public progress reports, just as the Mozilla owners do. They would respond to package enhancement requests and bug fix requests in public, just as the Mozilla owners do. And if they don't do a good job, the community could request that the TAB replaces them, just as the Mozilla governing body does.
I tried to manage the originally OpenACS 4 porting effort somewhat like this. Package owners who reported to me who then tried to maintain a status list (a job I did fairly lamely, miserably, poorly, incompetently - pick your adjective, Neophytos has offered to do it for 4.6 and I'm glad). By "reported to me" I don't mean in the managerial sense, I mean in the "if we weren't so lame we'd have set up some way for them to edit their own status but we didn't so Don tried to do it" sense. In general package porters were
very good at reporting progress, I was the communications bottleneck.
Now, on the new site, we might be able to give each package its own ETP page and let package admins scribble to their hearts delight, let others in their group scribble on it, etc.
There wasn't a real system of accountability in that effort, whatever accountability there was involved my e-mailing folks a note saying "hey, what's up with your package? You haven't told me in awhile?"
Big problem we've had is resource, i.e. getting people to own all the packages. Like every volunteer organization I've ever been involved in, we have a fairly high level of turnover. Folks get busy with other things, like jobs, family, school and can't volunteer at a sustained level forever.
But it is important that we find owners for packages if we're to move towards asynchronous releases, in other words where the calendar maintainers can issue new versions of that package to fix bugs or whatever rather than wait for the next release cycle or force folks to download from CVS.
The TAB/gatekeeper proposals here don't include a description of this sort of delegation, no. However if precedent on the OpenACS side is followed certainly CVS commit privs will be given to folks who are able to maintain and enhance packages. What's missing is the fleshing out of a plan to more formally assign responsibility for packages such as you suggest.
From my POV the only weakness in your plan is that it doesn't address the resource issue. Also any such plan needs to recognize that most of the actual package code resides in OpenACS (calendar, news, etc). But over all what you're talking about is a formalization of what I tried to do on a very informal basis during the porting effort.
