Lowering the participation barrier for Fedora Docs

[Chris Murphy]

On Nov 19, 2013, at 2:39 PM, Zachary Oglesby <zach at oglesby.co> wrote:
> 
> Sparks has tried to "reboot" the mentor process but I don't know how well that has worked. I think that the tutorial videos he is working on will help, but ultimately having someone (or multiple people) taking time to looking over their work and help them get started is a powerful motivator to keep going. The key is to keep people interested and show them they are helping. Fedora as a whole has always said that getting people to contribute is important because it provides a sense of ownership and keeps people engaged, its no different for any subgroup.

What sort of automation can apply here? I'm thinking of something that would track a contributor's contributions, and general areas of interest. And somehow track the aging of content either by chapter or even by subheadings, and if that content hasn't been reviewed/edited in a while, a request to review is sent based on some heuristic that makes sense:

a. request the original contributor
b. request the most recent editor of the content
c. request the most recent active contributor who has indicated this content is interesting
d. mark content as possibly obsolete/stale for review at a weekly meeting

Content could have different aging categories. One might be "each release" whereas a chunk of content might be "long term" for 2 or 3 releases before it needs to be hit up for review.

If any content is edited, then it's aging process starts over. 

Something that aids in knowing what content needs refreshing or at least a review. And also helps delegate those tasks. Maybe a role isn't even actually writing or editing, but just reviewing content.

And then also I like the idea of content pages having a user rating on them. Good or bad is super simplistic but at least would raise a red flag to shift the aging time shorter so it gets reviewed by someone. Good means "keep it" and bad means "fix it". In either case, it means users have a need for that content, and helps with resource allocation.

The people in the team who have been around the most should know where the land mines and bodies are buried. They should have the big picture view. So I think they need to come up with a priority listing of needs. From that, translate it into retooling, and recruitment. Until we're clear on exactly what problems or needs are, we aren't going to locate the right tools, processes, or recruits to address those problem and needs.

New users may be ripe source for recruitment on non-Fedora affiliated forums. It gets them active and invested in Fedora. They typically have some kinds of confusion about installing or using Fedora which is ripe content for writing, so maybe they're even familiar with how existing documentation helped or failed to help solve their problem.

And even moderators on 3rd party Fedora/linux forums, I'd wonder if they cite Fedora documentation and of not, why not. They may have some handle on what sorts of questions/problem always come up. That's good source material for documentation which should have those questions really clearly asked/answered already, side stepping a trip to a forum and waiting for an answer.

Chris Murphy