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_Features [2] http://fedoraproject.org/wiki/Category:Documentation_beats -- -- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode - immanetize@xxxxxxxxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part
-- docs mailing list docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
