Identify and evaluate highest Flesch-Kincaid-level documentation pages - Content audit
Issue Description
From &3747:
What are our highest 25 Flesch-Kincaid scored pages and why? Can we optimize/improve them?
Results
Observations
From reviewing the list, twelve of the top 25 pages didn't really qualify for review, for reasons including that they were either index pages (required due to lack of effective search support for /help
users) or were API-related.
Of the 13 standard pages, in many cases the high reading score for the pages seemed to be related to not a lot of content, coupled with longer sentences or longer technical terms (or both). I don't think we need to take explicit effort with these pages (as they're not frequently visited), but we should use this information during our content rearchitecture process to ensure that we're consistently having the team write in shorter sentences to communicate concepts, as these pages demonstrate what happens when that isn't the case.
Until such time that the content rearchitecture can occur, the readability scores for all GitLab documentation pages is maintained in the content audit for use by the TWs, as they determine their continuing work.