Core API documentation issue squad needed!

For the past several years, I have been the person who has managed the documentation component of the Drupal core issue queue.

Several people besides me have recently started contributing to Drupal's API documentation by patching issues, and I'm very happy about that! What I'd like to do now is also get a few people to take on the issue queue management tasks as well.

NOTE: Edited Nov. 11 - added Skills Needed to both tasks.

Here are the tasks:

1. A few times a week, check the documentation component of the Drupal core issue queue for newly-filed issues. These mostly come from the "file an issue" links at the bottom of the api.drupal.org pages. So, they need to be checked out:
   • Some of them are support requests. For these, politely inform the person that we don't do support in the Drupal Core issue queue, and direct them to other support options (I have a template that you can copy and paste). Then set the issue category to "support request" (if it wasn't already), and set the status to "fixed".
   • Some of them belong elsewhere. The most common are issues that belong in the Examples for Developers project (this project is included in api.drupal.org), or the Documentation project (there are a few files in the Documentation project git repository that are on api.drupal.org, and we use issue component "API documentation files" for issues related to those files in that project's issue queue). If an issue belongs in a different project, move it there (with a comment).
   • Some are not valid or need more information. If you investigate and don't agree with the report, you can either mark it "posponed (maintainer needs more information)" and ask for clarification, or you can mark it "works as designed" if the report is just wrong and the documentation is correct. Other status changes are possible too -- use your own judgment. In any case, always try to be polite to the person who filed the issue, and explain why you have changed the status.
   • Some are valid reports. For these, if it's a small change needed or if the report is very clear on what to change, add the Novice tag. And in any case, if you have investigated a report and find it to be a valid error in the documentation, add a comment thanking the person for reporting the problem and confirming that you agree it's a problem. You also need to move any Drupal 7.x issues into Drupal 8.x (assuming the same issue exists in 8.x), and mark them with tag "needs backport to D7", because we fix issues first in the in-development version of Drupal, and then backport to the previous versions.

   You may also want to click the Follow button to follow the issues you investigate or look at.
   Skills needed: You need to be proficient at reading PHP code, because you need to be able to definitively say that function abc's documentation does or does not correctly represent what function abc actually does. You do not need to be proficient at writing PHP code.

2. A few times a week, check the issue queue for issues newly marked "needs review", and review the patches:
   • Make sure that the patch fixes the identified problem.
   • Make sure that the resulting documentation is formatted according to our documentation standards.
   • Normally, I ask that if someone is fixing a docs issue in one function, that they also edit the rest of that function's doc header to bring it up to documentation standards and clear English. However, they shouldn't also do cleanup on documentation for other functions on that issue, just the one(s) mentioned in the issue report.... But if the same wrong content is in related functions, it's probably OK to expand the issue to fix the documentation for the related functions at the same time.

   After reviewing, add a polite comment and mark the issue status as "needs work" or "reviewed and tested by the community" as appropriate.
   Skills needed: In addition to the skills for the first task, you also need to be able to read/understand standard patch format, and you need to know how to apply patches.

Any takers? If you're interested, leave a comment here or find me in IRC (#drupal-docs or #drupal-contribute), and I can help you get going, answer questions, etc. Thanks!