Documenting Features

[Pete Travis]

Hey guys,

I've been reading the Feature discussions on devel@ today, and an idea
came to mind. A process for documenting accepted Features would help
prevent major changes from slipping through the cracks. Here's what I
came up with so far; I think we can hammer it into something useful:

Accepted Features[1] will be listed in a table roughly analogous to that
used for Release Note Beats[2]. The table would have columns for the
Feature name, a docs volunteer, and developer contact, as well as others
reflecting the Feature documenting workflow.

A set of guidelines for the docs volunteer covering a feature will come
along with the table. The set of tasks to be juggled might include:
	- Establishing an appropriate developer point of contact to aid in
documentation. Note that this isn't always the feature owner.
	- Ensuring the content of the Feature is understandable by a
hypothetical average user.
	- Working up a basic guide to implementing the feature, if applicable. 
	- Creating an entry for the Feature in the appropriate Release Notes
beat.
	- Checking existing guides for impact caused by the new Feature, filing
bugs as needed, and assisting the guide owners in updating as
appropriate. 

A defined process like this will help split up the workload caused by
feature churn and cut redundant efforts by providing new information for
multiple published works. Your thoughts?

[1]
http://fedoraproject.org/wiki/Releases/19/FeatureList#Fedora_19_Accepted_...
[2] http://fedoraproject.org/wiki/Category:Documentation_beats



-- 
-- Pete Travis
 - Fedora Docs Project Leader
 - 'randomuser' on freenode
 - immanetize(a)fedoraproject.org