Re: [boost] Attn: New Boost library policy text ready for approval

Subject: Re: [boost] Attn: New Boost library policy text ready for approval
From: Peter Dimov (lists_at_[hidden])
Date: 2017-03-20 22:11:42

Niall Douglas wrote:
> >> Almost without doubt when potential review managers scan the list of 
> >> review pending libraries, they will prioritise those libraries with the 
> >> most public endorsements.
> >
> > How would they know which libraries have the most endorsements?
>
> I had been thinking that an extra column in the table at 
> http://www.boost.org/community/review_schedule.html would be entitled 
> "Seconded by" and in the cell would be the names of all those who endorsed 
> that library for review. In other words, if you Peter ask for endorsements 
> for review here for your new library SharedPtr2 or something, ...

Or for mp11, to take a completely random example.

What I am proposing does not change that in any way. The difference is how 
the endorsements are communicated to the person managing the table. The idea 
of using Github issues is to avoid the need to scan the Boost list, and to 
provide a place where the information about a specific library is 
concentrated.

Our current procedure would be, the library author posts to the list, people 
respond with endorsements (on the list), the author collects those 
endorsements and notifies the Review Wizard using private e-mail.

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.)