Things to consider during the review - you don't have to do all of it - team up with someone if your strength is technical fact checking and you need help with the wordsmithing! (or the other way around).

(Re)write Chapter

This stage is for two things: re-fact checking and then editing the formatting and organization of sections so that it lines up with all of our conventions. This could mean anything from fixing headers to putting in admons (like the ones at the bottom of this page) to making sure that the standard installation process is referenced instead of including it inline. Ideally most rewriting is done between releases (from release to next alpha).

Fact Check

This stage just changes all factual information so that it syncs up with the facts for the upcoming version. If the default browser happens to be Dillo instead of Firefox for this release, the Fact Check stage should reflect this after completion. This is the core of the work during Alpha and with the early release candidates for Beta.

Edit/Wordsmith

This is for the English majors. Make the page grammatically sound while keeping our conventions and a technical writing style in mind. Extra points go for stylizing the writing as long as it doesn't conflict with the core goals of readability and simplicity in comprehension.

Edit Format/XML Conversion

Make sure it still builds in Publican! This task continues through Beta with any updates as well as ensuring that the translated versions also build without error.

Submitting updates

All edits get done in xml/docbook/git (master branch)

If you do not have commit access, please submit a git formatted patch to the docs mailing list or in bugzilla

git diff > mypatch-chaptername

Then attach mypatch-chaptername

If you submit enough, do not be surprised if you are given commit access.

If you cannot provide a git formatted patch, do not let that stop you, submit suggestions, paragraphs, fixes, anyway possible.

F14 Status table

When you claim a chapter to review, place your name in the column.

As you take breaks, update the status. This way someone else can pick it up if you cannot get back to it. This is also a where you can indicate that you need some help in the review such as wordsmithing or fixing an xml error.

verify all authors are added to Contributors_and_production_methods.xml and Revision_History.xml

General LifeCycle of the User Guide

During Alpha

All new features should be announced and included in the alpha. This is the time to review the User Guide for major changes such as new default applications or major look and feel changes to GNOME, KDE, or other desktops covered.

During Beta

Complete the review of all chapters and branch for translation. Since the UG should not change much beyond beta, this document should be branched early in the beta cycle so that translators can get the work done and be ready for the push of more significant document updates such as the installation guide and release notes.

Builds of draft documentation in the languages occurs during this time. Review the builds for xml errors and review bugzilla for content fixes to be made. Correct what is wrong but balance that with minimizing changes that will cause more work for the translation teams.

Advanced Topics

Whenever we add something that would be nice to have in the user's guide but isn't necessary for the basic desktop user who just migrated fresh from Windows (example: discussion of FTP programs, advanced discussion of yum on the command line), we should add a template to let the confused user know not to worry about this section if they don't want to. This is what I've come up with right now:

Advanced UsageThis content is written for the more advanced user. It assumes that you are comfortable with the command line and have a relatively good knowledge of Linux terminology. It is probably not necessary to using Fedora as a desktop user, but can help a desktop user expand his or her knowledge base and face more complicated troubleshooting issues.

That, again, is just my current idea until someone suggests or comments on that. Let me know in IRC or on the list.
--Danielsmw 15:08, 25 February 2009 (UTC)

admin tasks TODO

Find out where git commits are going - ie not to someplace I am already subscribed to

Figure out Trac. https://fedorahosted.org/userguide/ looks like it was used briefly with F9 wiki -> xml conversion and that is all. Start with can I edit main page or how to I gain access to edit main page.

Create wiki page with procedures and general task lists for managing the user guide. Point to trac and bugzilla and git.