Wikipedia:WikiProject Military history/Coordinators/XVII Tranche Project Audit

Context
The Project's history dates back to 2003 when it as first started as WikiProject Battles. Widening the scope, we settled as WikiProject Military History, as one of the largest and most active projects on English Wikipedia. As we've grown from a small group to a big project, we've adopted several structures, practices, and ways along the way to make the best out of this collaboration. So it is time we have an internal assessment of our practices, check the inefficiencies, and if necessary, make necessary changes for the same.

The audit's workflow, various steps involved, and goals are explained in the further sections. The audit has been titled as "XVII Tranche Project Audit" as it is being done by XVII Trache of project's coordinators. The audit begins on DATE MONTH YEAR.

Goals

 * Create necessary pages as listed in the further sections.
 * Expand pages and sections as listed in the further sections.
 * Check specific aspects of the Project including the pages related, whether if they are up-to-date, and make necessary improvements.
 * Collect opinions from the Project members regarding their experience with the Project.
 * Collect ideas from the Project members to suggest new measures that can implemented for our future best.
 * Make necessary changes to the Project's overall structure and strategy for the best.
 * Make necessary changes to the Project's coordination structure and strategy for the best.
 * In the end, publish a detailed report on how the audit went, through The Bugle, if possible also spread a word to The Signpost, and the Wikimedia Foundation Blog

Audit team

 * All current and past project coordinators, if you're interested, please add yourself here.



Workflow

 * Create a subpage for the aspect being reviewed, and add it to progress table below. Also update the "Current status" to "Reviewing" and sign accordingly.
 * On the review subpage, please use following tags in the section header to indicate status of a particular page or process. By this, the TOC of this page becomes a summary of progress.
 * Pending
 * Reviewing
 * Reviewed
 * Checked
 * Closed
 * Reopened
 * Create a section on the talk page of each topic with the heading, "XVII Tranche Project Audit".
 * The purpose of the comments section is to notify issues that arise which may affect one or more of the Academy's pages. It is also to "flag" a discussion at a particular page that may require broader participation. However, such discussions should be conducted on the talk page for the particular "topic".
 * On the subpage, for each section, this following protocol is recommended
 * Track the progress of the audit process in more detail than indicated by the heading.
 * Provide a summary of the auditable trail of the process and who has completed each step of the process.
 * Request an editor action the next step in the process.
 * Record that that a request is being actioned. This is important to avoid duplicate effort.
 * Record that an action has occurred.
 * On the subpage, under each section each step is indicated by a key word shown in "bold face" and signed by the editor recording the step per the following example. Edit summaries should use the key words indicated.
 * Reviewing A user is reviewing a page
 * Check A user is requesting a check of a review (the section heading shows that the page has been reviewed).
 * Checking A user records that they are responding to a request to check.
 * Closed If the checking user is satisfied that with the actions taken in review of the page, the review is closed.
 * Close If the checker or reviewer requests a third-party close.
 * Closing When a user responds to a request to close.
 * Reopened As a result of an issue being identified in the course of reviewing another page. A brief description should accompany this (perhaps, with links to the talk page sections where this is raised). A reopend review needs to be closed by a similar process.
 * Note Reopening can happen anytime before the final closure of the audit.

Process
The process for auditing is as follows :
 * Advise the project (on the project talk page) of the review in general. Invite comments in general at the Academy review talk page and specifically at "topic" talk pages. Make it clear that this will be a longish process and that all input will be considered. Periodically readvertise as topics are coming up for review. This step may not have occurred in the early stages of planning the audit process. A "close" in such a case does not preclude revisting a "topic" in light of concerns being raised by members of the project.
 * An editor uninvolved with the topics creation reviews and copy edits the page. This person becomes the "reviewer" in the following process. Their role is much like the nominator in any other review process.
 * Any "significant" issues are notified at the Audit talk page (or, for the Academy, the "Academy review talk page") for resolution.
 * The reviewer proposes the topic page for checking at the Audit talk page (or, for the Academy, the "Academy review talk page").
 * A "checker" checks the work of the reviewer for accuracy, typos content etc. They fix minor matters and make a recommendation. If there are no unresolved issues, the checker may close the review.
 * In the event of unresolved issues, a "closer" may be called upon (per the Academy review talk page) to provide a third opinion and, having resolved the issue, close the review.
 * In the course of reviewing a topic page, changes to a "previously" reviewed page may be indicated (by the "identifier"). These will not be simple typos. They may entail a change in terminology or something more complex. Where this occurs, there must be concurrence of the ""identifier" and a seconder familiar with the implications of the change at the "previous" page. The matter may be simply resolved. If it is not, the "previous" pages may need to be reviewed anew to resolve the matter. This is becomes an iterative process. The issue and its resolution should be documented on the "previous" topics talk page. It should be linked to the topic that gave rise to the issue and provide an "auditable trail" of what has transpired.
 * The underlying principle is that, changes to project documentation are not the consequence of one persons actions alone, that changes can be validated and that there is an "auditable trail" to substantiate the validation. The steps in the process link directly to the progress for each "topic" page.