I'm not saying unpopular packages are not taking a look at. The power of the community on choosing what to mantain, document and test is a strong force that it should not be treat it slightly.
There are multiple things I'd like to explore in quickreviews. One of them is putting the package in our radar, if in the future we are solving a similar problem such as the one the library is solving we can rely on that and make some use of it.
Secondly, at the early stages of the development we can see how much are the author and main contributors writing in terms of documentation and tests.
Thirdly, peaking how the code is structured and how issues are handled wouldn't hurt.
"quick" for me means 30 minutes. As I like to post regularly short articles, instead of writing for a few days. I'm going to continue with the same strategy I did for the book review:
If after a quickreview we decided that something is worth a next level review (will think about a name later). We'll do it :D