This task is a break-down of the sixth and seventh week of GSoD based on the timeline {T255360}
Related tasks for other weeks can be found here {T262918}
===== Week 6 - 7 (October 19 - 30)
[] Revise the proposed format based on feedbacks gotten from mentors and documentarians.
[] Create a document guide explaining the finalized format discussed in depth.
[] Discuss how the format documented can be enforced on documentarians and across all Wikimedia documentations.
Last week, I proposed a documentation review process and explained how tools like phabricator can be leveraged on for documentation reviews.
This week, I'll be focusing more on revising the suggested process based on feedbacks gotten, I will be making adjustments where necessary. But firstly, I would like to restructure the five review processes into something less verbose.
== Revised review process
The documentation review process has been revised into 3 basic processes after which documentations would only be approved after all processes have been undergone.
==== 1) Prototype/Self review
The writer of a documentation is always the first reviewer of their own documentations, therefore, a documentarian is obligated to review and do a copy editing of his documentation before submitting it for review.
As a part of this step, the documentarian is allowed to share the documentation with a friend or colleagues.
The documentarian is to make sure that the documentation follows Wikimedia's documentation [style guides](https://www.mediawiki.org/wiki/Documentation/Style_guide), [formatting](https://www.mediawiki.org/wiki/Documentation/Style_guide#Formatting_text), methodologies, and use of [language](https://www.mediawiki.org/wiki/Documentation/Style_guide#Language). This helps the reviewer identify his own mistakes and makes sure the documentation conforms with the style guide. Additionally, new documentation tasks are to be created by strictly following this [guide](https://www.mediawiki.org/wiki/Documentation/Technical_documentation_prioritization).
==== 2) Technical Review
This phase would require a senior colleague to go through the documentation and check for technical accuracy, completeness of its content, and how easy it would be for new contributors to adapt. Comprehensive responses and feedbacks would be gotten here.
==== 3) Non-technical Review
Here, the documentation has been checked for technical accuracy and correctness and it's time to ascertain that the style guides, formatting, methodologies, and use of language were strictly followed. This would be done by an experienced reviewer who is more familiar with these guides.
Documentations would only be moved out of the review phase if all and only if all review stages has been passed.