The new procedure would be, the library author posts to the list, the first Boost member who endorses the library creates an issue for the library, additional endorsements are posted as comments on that issue. The Review Wizard, being the owner of the repo, receives notifications for each and can respond in the issue, if needed.
That is, all the communication that is relevant for a particular submission reaches the Review Wizard without him having to read the Boost list, or relying on people notifying him via private e-mail.
One exception to all the communication taking place in the issue could be when a review manager is suggested, because in case of rejection, people may not appreciate this taking place in public. I don't know how often review managers are rejected though, so I don't know if this is a practical problem.
Re Github stars, if the library is already on Guthub, which it pretty much has to be, the repo stars can be used as a metric of popularity. (The other way to gauge popularity is by the number of comments the library submission issue has attracted.)
I think this is all far too much for people to hold in their heads. If you were to script all this up into some webforms which called the github api for people, I could see it working. But for people to remember to open tickets and +1 them and all that ... I don't think it will fly. Too much to remember. (and Robert basically says the same thing in another reply) Don't get me wrong for a second Peter, I would *just love* to automate the hell out of all this stuff, bring state of the art automation to bear on "the Boost scalability problem". But that stuff doesn't come cheap, neither to implement, debug nor to maintain. Plus, nobody here seems keen on automation, we seem to like static HTML and email, and anything exceeding that is a very tough sell, especially anything regarding changes to process. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/