<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.technet.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Writing good technical documentation, part 1</title><link>http://blogs.technet.com/jeanie_d/archive/2009/01/06/TechDocs1.aspx</link><description>A recent comment by "BPM software" suggested that I write about best practices for writing technical documentation. I thought about it for awhile and decided I couldn't really do it justice in one post - hence, "part 1". I'll begin by plagiarizing myself</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>Writing good technical documentation, part 2</title><link>http://blogs.technet.com/jeanie_d/archive/2009/01/06/TechDocs1.aspx#3211110</link><pubDate>Tue, 10 Mar 2009 07:50:31 GMT</pubDate><guid isPermaLink="false">d5e57398-b9ef-4490-9955-07cbb4e4a80d:3211110</guid><dc:creator>Words and Software</dc:creator><description>&lt;p&gt;(Part 1) Joel Spolsky has an excellent post on the role of the program manager . I work with program&lt;/p&gt;
</description></item></channel></rss>