Proposal: Move all api.drupal.org issues to the Drupal project

I had this originally as a response to #236767: Update Documentation issue queue components but I don't want to de-rail that productive discussion with this.

Please tune out for a moment whilst I go on a rant...

Drupal 6 has been out now for over 6 months and there are still hooks that remain undocumented. There were something like 27 to begin with, now we're down to under 10 after a few of us got so disgusted with the situation back in May or so that we put a bunch of fake function descriptions in so there would at least be /something/ there. And don't even get me started on how out-dated the Form API documentation is...

... ok, you can tune back in now. :)

In a nutshell, I don't know that it makes sense for api.drupal.org documentation to be in the Documentation queue at all, because it's a completely different workflow. Documentation that's wrong on api.drupal.org has to be fixed in source code.

1. For functions, constants, and such, Drupal's source code needs to be changed in core itself, in which case we need to re-file the issue under the Drupal project, and the Documentation queue is the wrong place from the outset.
2. For hooks and "other" docs (like the FAPI reference), we need to update the source in various PHP files under contributions/docs/developer, and hope that a developer with CVS access is watching the docs queue (spoiler: they aren't) and stumbles across the issue and fixes it.

On the other hand, there are about 2,000 developers monitoring the Drupal project queue, and the Drupal project has a handy category: bug report, priority: critical queue, and we don't ship the next version of Drupal until that is down to 0. So I would actually advocate re-filing any problems with api.drupal.org against the Drupal project's documentation component instead, and if it's something egregious like a missing hook, bump the priority to critical there.

Opinions?