Some of this work is triage work - not a bug or filed in the wrong place. For more information on general bugzilla triage work see BugZappers.
Some of the work is fixing the doc at the source - usually in git but some docs are still in cvs or svn. Rarely there will be a report to fix an item in the wiki. While anyone with a CLA can edit the wiki, there are testers and contributors who prefer not to have a FAS account.
So - anyone who has write access to a doc in git should also make sure they have the ability to close the related bug in bugzilla.
- get a bugzilla account if you do not have one. https://bugzilla.redhat.com/
- make sure the email you list in bugzilla matches the email you list in fas
- request sponsorship to the fas group fedorabugs
- ask stickster to approve fedorabugs. Note: there are also others who can sponsor, mostly from the bugzappers team. You may need to point out that this sponsorship if for Docs Project bugs or you may be asked to introduce yourself on the fedora-test-list and attend bugzapper meetings.
- let sparks and other document owners know to start assigning you bugs :)
- start fixing and closing bugs.
You do NOT need to own the bug to close it. When it is closed the assignee and the person that opened the bug will be notified, along with anyone else on the cc list. They will have the option to reopen the bug if they have more information or do not believe it should have been closed.
Do try to be polite and helpful when closing the ancient ones. It is ok to close as the doc is end of life but it is also nice to point out the link to the current version and encourage more review and reporting as needed.
For more assistance with bugzilla, see the BugZappers pages or ask the bugzappers team in #fedora-bugzappers.
Aditionally, a good time for cleaning up old bugs is at Release of a new version of Fedora. The general bugzilla cleanup for F11 timetable was recently described on the fedora-test-list mailing list https://www.redhat.com/archives/fedora-test-list/2009-May/msg00560.html