Inspector

Interesting idea.

Have you checked for existing modules that provide this? It does sound rather familiar to me.

Also, the name 'Inspector' doesn't really convey what this does. Launch checklist would be better -- and I'm a feeling I've seen a module named along those lines.

It has been less than a month, actually. There are no applications that are more important than others.

Raising the priority doesn't have any effect; if you change it to critical, the application will not reviewed first. The priority is not used for tasks, and it is not used in this queue.

The priority description page reports the following text:

Choosing the right priorities

Tasks and Feature Requests should never be marked “critical”. They should usually be “normal” or “minor”. A support request can be marked “critical”, but the more-urgent priority is unlikely to give you better support; it is better to describe your issue thoroughly to help people understand what is wrong.

There are some similar-looking modules out there, but none of them do what this module does.

The Security module (http://drupal.org/project/security) appears to provide a security-based checklist, but it is only focused on security issues. Additionally, it is minimally maintained; the last commit was a year ago; and it has no official releases.
The QA Checklist module (http://drupal.org/project/qa_checklist) looks similar, but it doesn't actual check anything – it just recommends things to check and provides a way for you to mark them as having been done. It doesn't actually check that things have been done, which is part of what Inspector does.
The Security Review module (http://drupal.org/project/security_review) looks pretty nice, but again, it is only focused on security.
The SEO Checklist module (http://drupal.org/project/seo_checklist) is another checklist-type module, but is focused only on SEO.
The Checklist module (http://drupal.org/project/checklist) is yet another checklist-type module; but as with the others, does not check that the items on your list have actually been completed. It only provides a framework for making checklists (or it would, if there were any official releases).

Frankly, I read down that list and I don't see a reason for more than one module. Maybe two at a push if one is security focussed.

Which one is most popular? Which one has the best code (for a variety of definitions of 'best')?

I'd rather see efforts towards consolidating the existing landscape than one more module in it that will confuse users.

As per the the new project application priority guidelines, the application's priority should be set back to normal once a reviewer responds to the application and the application review process has continued.

Out of the above list, let's discount Security Review, Security, and SEO Checklist as too specialized.

That leaves QA Checklist and Checklist. Could one of those be expanded with the features here? Would co-maintainership be a possibility? If they are abandoned, could they be adopted?

@venutip, I would recommend trying to take over the QA Checklist module. I think it has a clearer name, I thought this was something like Devel Themer, or Firebug's inspector.
Plus, it reuses a namespace, instead of yet another similar module.

You can follow the Abandoned Module process and close your application, if you choose. Plus, I will tell you, it is an easier process.

Either way, here is a coding standards patch to help you out.

Hi @tim.plunkett, et. al.

I've worked with @venutip on this module a bit and have used it on a number of projects, sometimes as a pre-launch tool, but often for diagnostic reporting when to evaluate work done by other developers, provide quotes for site overhauls, and other "report" use cases that aren't covered by the particular focus of the QA Checklist module or that namespace.

Because there are a number of non-QA usecases, I think that the fact that this module aims to be a reporting and investigation tool, and not just a QA checklist tool, distinguishes it from other currently available modules. There are certainly a number of points of potential integration with modules like QA Checklist, and we could work to expose test routines and results a bit more through an API to allow other modules to take advantage of it, but I don't think they are the same thing.

That said, I think that the question about whether Inspector is a sufficiently descriptive name is a good one.

@venutip, perhaps we can look into this as part of a D7 port of the module?

Module is verified as solid, venutip is treating it as a full project already (applying patches etc). Technically, we currently vet project maintainers, not the projects themselves, and given the six-week approval queue we cannot afford to make overlap in the could-merge-together-in-the-future-but-clearly-have-different-cases-now category hold up a review.

This application has been in gestation for 10 and a half months. Lets move on to some that really need review.

venutip, you are now a vetted user, and can promote this to full project if you choose. Please take a good look at the best namespace, and ensure that becoming a part or a submodule or a 2.x branch of another module isn't the best route. I look forward to your continued improvement of this module which i expect to use in D7!