Logo Home   MSDN Teams   Documents and Lists   Create   Site Settings   Help   
MSDN Intranet
The MSDN iWeb
partner intranet


Web Part Menu
  MSDN Publishing Standards
  MSDN Content Ratings
  Developer Centers
  Steelwire
  Online Customer Satisfaction Results
  Online Usability Results
  MSDN Publishing Roadmap
  MSDN Project Status Reports
 Add new link
 

MSDN Publishing
September 2003

Before You Start

Contents

Introduction
The Handoff Process for Offline Products
   Publishing Schedule: Quarterly MSDN Subscriptions Library Releases
   What We Need for Offline Publishing
   Handing Off Content for the Quarterly MSDN Subscriptions Library CD/DVD Product
   Reviewing Content for QA After It Is Built
   Content Maintenance Over Time
The Handoff Process for the MSDN Online Library
   Schedule: MSDN Online Library
   What We Need for Online Publishing
   Handing Off Content for the MSDN Online Library
   Reviewing Content for QA After It Is Built
   Content Maintenance Over Time
Drop Locations for Offline and Online Products
   Things To Remember
Further Reading

Introduction

The MSDN Library is built to several different products. We have the MSDN Online Library, the quarterly MSDN Subscriptions Library CD/DVD product, an MSDN Library included with Visual Studio, and other iterations of our product. Because of the different products we maintain, we have slightly different requirements and drop locations for each product.

There is a specific handoff process for offline products because offline content will generally appear as it does in standalone builds and does not need to be modified in any way. Please note that the MSDN Subscriptions Library offline product is produced on a quarterly time schedule. Also, there is a handoff process for the MSDN Online Library because the online content must be modified to fit the MSDN online template. The online and offline cycles are often divergent from each other; therefore, contributors will often receive bugs that refer specifically to either the online or the offline products.

Often contributors will request that their content only appear in either the online or offline product. Therefore we request that contributors create unique Product Studio tracking bugs for each destination. This will ensure that content will be built to the appropriate products. This also means that content dropped for an offline product will not automatically be picked up for the online product, and vice versa. If you wish to have your documentation converted and published in both the offline products and the MSDN Online Library, you must open separate tracking bugs.

Back to top

The Handoff Process for Offline Products

The offline product in this case refers to the quarterly MSDN Subscriptions Library CD/DVD product. For information regarding Visual Studio builds, please e-mail the MSDN build team (msdnbt@microsoft.com) for specific information.

Before handing off content, please make sure the content submission standards have been met and that you have noted the quarterly offline publishing schedule.

A "Call for Content" e-mail is sent out each quarter.

Figure 1 shows the handoff process for the MSDN Subscriptions Library.

Figure 1. The handoff process for the MSDN Subscriptions Library

Publishing Schedule: Quarterly MSDN Subscriptions Library Releases

Jan04 Release
Third week of Sept: Call for Content
Third week of Oct: Content Lockdown
Fourth week of Oct – First week of Nov: QA Review
Second week of Nov: Zero Active Bugs

Apr04 Release
Third week of Dec: Call for Content
Third week of Jan: Content Lockdown
Fourth week of Jan – First week of Feb: QA Review
Second week of Feb: Zero Active Bugs

Jul04 Release
Third week of Mar: Call for Content
Third week of Apr: Content Lockdown
Fourth week of Apr – First week of May: QA Review
Second week of May: Zero Active Bugs

Oct04 Release
Third week of June: Call for Content
Third week of July: Content Lockdown
Fourth week of July – First week of Aug: QA Review
Second week of Aug: Zero Active Bugs

Please also look up the current time schedule for publishing offline content (\\msdnfs\MSDNUsers\Library\).

What We Need for Offline Publishing

  • For contributors to consult the offline publishing schedule (\\msdnfs\MSDNUsers\Library\)
  • For contributors to properly prepare their content so that it meets all MSDN submission standards
  • For contributors to open a Product Studio tracking bug to initiate the process, assigning it to their Content Manager
  • For contributors to drop content to file://ppgbuild01/dropoff (for the quarterly MSDN Subscriptions Library CD/DVD product)
  • If \\ppgbuild01\dropoff is closed (it is closed for submissions during that phase of the Quarterly cycle when necessary to guarantee the stability of the Quarterly builds), contributors must create their own public share, drop the content to that location, and note the location in their Product Studio bug
  • For contributors to watch for ongoing bugs assigned to them and attend to them promptly
  • For contributors to be responsible for maintaining their content over time

Handing Off Content for the Quarterly MSDN Subscriptions Library CD/DVD Product

Before handing off content, please make sure the content submission standards have been met and that you have noted the quarterly offline publishing schedule (\\msdnfs\MSDNUsers\Library\).

We use Product Studio to communicate with product teams regarding their bugs. It is expected that all product teams designate a contact person in their team to whom MSDN can log bugs. That person is expected to check Product Studio at least once a day during production to make sure no urgent issues arise. We recommend that users install PSAlert, Bugger, or another Product Studio monitoring tool to use when attending to issues that arise and when tracking the progress of their bugs. You will be able to review your bug at any time to find out where it currently is in the process.

To handoff content for offline publishing:

  1. Drop your HxS/HxI files to the drop location.
    For the MSDN Quarterly Subscriptions Library that location is file://ppgbuild01/dropoff. Once content has been dropped to this location, revisions should also be made to the same location.

    If \\ppgbuild01\dropoff is closed (as it is during the phase of the Quarterly cycle when it is closed to submissions to guarantee the stability of the Quarterly builds), contributors must create their own public share, drop the content to that location, and note the location in their Product Studio bug. The MSDN Build team will pick up the files from that location at the appropriate time.

  2. If you need to install Product Studio, go to http://productstudio/.
  3. Open a Product Studio tracking bug and assign it to your content manager if you are:
    • Submitting a new file(s)
    • Dropping a revised file(s)
    • Deleting a file(s) from the Library (files continue to ship in the Library until a contributor requests them to be removed)
  4. You must use the Product Studio template to create a Product Studio tracking bug for your content. Download the Product Studio template (offline.pst) (\\ppgbuild01\public\PSTemplates). (To use this template, copy the .pst file to your local machine and place it at C:\Documents and Settings\<your alias>\My Documents\Product Studio Files).
  5. Use the following fields in Product Studio:
    Issue type: Production
    Priority: 3
    Severity: 3
    Source: Other
    How found: contrib
    MediaType: CD and DVD
    Release: choose the appropriate quarterly release
  6. In the body of the bug, please provide the following information, which is listed in the Product Studio template:
    • File name: the name(s) of your document set (HxS/HxI pair). You can list multiple docsets here if they are part of a collection.
    • Title of each .hxs in the set
    • Total size of the doc set
    • Content manager: the name of the MSDN content manager who deals with your content
    • Version number of the doc set (obtained by right-clicking the hxs and getting the properties). File versions must increment each time a new file is dropped to MSDN (for example 7.0.1032.2322). For more file versioning info, see Content Submission Standards for Product Documentation Sets.
    • If content is an update to doc sets already submitted to MSDN, provide a list of content that has been added or removed
    • Product team contact: name of a contact to whom we should log Product Studio bugs. All bugs will be assigned to this alias; this person can in turn reassign bugs to others on their team, as necessary.
    • Requested quarterly build: your requested live date or targeted quarterly date, if any (for example MSDN Quarterly October 2003)
    • Location from which docs can be obtained. Indicate here that your files have been dropped to the drop location.
    • TOC placement: requested location within the master TOC if this is new content or if it needs to be moved within the Library.
    • OTHER COMMENTS: Any special notes you need to add go here.
Note   Contributors can log multiple HXSs in one Product Studio bug (for example, multiple Windows CE or Exchange builds), but they will have to log a bug for each release of their product. This means that they will log a different bug for the MSDN Online Library, the MSDN Subscriptions Library, and the next release of Visual Studio, if applicable.

Reviewing Content for QA After It Is Built

Verify that the proper content and TOC information are showing up in the daily MSDN Library builds. The daily builds are installed on a Terminal Server named Spectre01. Use Remote Desktop to connect to this machine. The MSDN QA team also makes a QA pass on the content.

Once your content has been posted to spectre01, it is the contributor's responsibility to review the content and the TOC information to confirm that it meets the following QA requirements:

  • TOC check—verify that:
    • All content is in correct location in the TOC
    • Topic pages open correctly
    • No pages contain File Not Found in the TOC page where the article's title should be
    • TOC and topic title are identical
    • Content titles should not appear as double nodes (title listed twice in descending levels). For instance:
      User Interface Basics
          Overview: User Interface Basics
              Overview: User Interface Basics
The repeated title, "Overview: User Interface Basics," should only appear once at the higher level in the TOC.
  • Geopolitical check—verify the following:
    • Check the fix recommendations for English products in the English Terms Reference Guide (http://gpsweb/tools/policheck/DisplayTerms.asp?LCID=9) on the GeoPolitical Strategy Web site and verify that content does not include any of the "must fix" terminology
    • Also, check the GeoPolitical Strategy home page for new geopolitical issues at Welcome to GPSweb (http://gpsweb/).
  • Functionality check
In addition to verifying basic functionality for Library functions, also check the following:
  • Cursory link check: Check random links in content to make sure nothing is wrong
  • TOC sync check: Random check to make sure that content syncs to TOC
  • Script check: Verify that all functions such as glossary look-ups and popups work as expected
  • Formatting check—verify the following:
  • That formatting within sections is uniform
  • That the appropriate footer and CSS are inserted
  • Basic Proofing—verify the following:
  • High-profile dates and copyrights are current
  • Check for common typos and errors (missing graphics, common misspellings of Microsoft products and so on)
  • No gross formatting bugs or obvious errors (blank pages, bad margins/frames, broken toolbars and so on)

Content Maintenance Over Time

The content owner is responsible for making fixes subsequent to publishing, such as updating product naming, fixing broken links, making corrections in areas such as geopolitical issues, and following any other MSDN requirements that come into effect.

If new MSDN requirements come into effect, you will be contacted by your content manager to ask you to make the changes. We will always ask product teams to make changes rather than have MSDN do them to ensure that the changes appear in all future content drops. You may also initiate changes in your content for any reason. If your team is directing the redrop of content, please log a new Product Studio bug as discussed below. If MSDN directed your team to rebuild, please contact your content manager, who will help to facilitate the rebuild of your content.

Back to top

The Handoff Process for the MSDN Online Library

Before handing off content, please refer to Content Submission Standards for Product Documentation Sets and be sure that these have been met.

Product Studio is our method for communicating with product teams regarding their bugs. It is expected that all product teams designate a contact person in their team to whom MSDN can log bugs. That person is expected to check Product Studio at least once a day to make sure no urgent issues arise. We recommend that users install PSAlert, Bugger, or another Product Studio monitoring tool to use when attending to issues that arise and when tracking the progress of their bugs. You will be able to review your bug at any time to find out where it currently is in the process.

Figure 2 shows the handoff process for the MSDN Online Library.

Figure 2. The handoff process for the MSDN Online Library

Schedule: MSDN Online Library

There is a two-week period during the Quarterly CD/DVD cycle when the QA team must concentrate fully on the Quarterly CD. During these periods we will be unable to prop content for MSDN Online Library. Refer to the Quarterly CD/DVD cycle schedule (\\msdnfs\MSDNUsers\Library\) to look up these dates.

What We Need for Online Publishing

Handing Off Content for the MSDN Online Library

  1. Drop your HxS/HxI files to the drop location.
    For the MSDN Online Library that location is file://ppgbuild01/webcollection.
    Once content has been dropped to this location, revisions should be made to the same location.
  2. .If you need to install Product Studio, go to http://productstudio/.
  3. Open a Product Studio tracking bug, assigned to your content manager, if you are:
    • submitting a new file(s)
    • dropping a revised file(s)
    • deleting a file(s) from the Library (Files continue to ship in the Library until a contributor requests them to be removed)
  4. You must use the Product Studio template to create a Product Studio tracking bug for your content. Download the Product Studio template (online.pst) from \\ppgbuild01\public\PSTemplates. (To use this template, copy the .pst file to your local machine and place it at C:\Documents and Settings\<your alias>\My Documents\Product Studio Files).
  5. Use the following fields in Product Studio:

    Issue type: Production
    Priority: 3
    Severity: 3
    Source: Other
    How found: contrib
    MediaType: online
    Release: choose the appropriate FY Quarter

  6. In the body of the bug, please provide the following information, which is listed in the Product Studio template:
    • File name: the name(s) of your document set (HxS/HxI pair). You can list multiple docsets here if they are part of a collection.
    • Title of each .hxs in the set
    • Total size of the doc set
    • Content manager: the name of the MSDN content manager who deals with your content
    • Version number of the doc set (obtained by right-clicking the hxs and getting the properties). File versions must increment each time a new file is dropped to MSDN (for example 7.0.1032.2322). For more file versioning info For more file versioning info, see Content Submission Standards for Product Documentation Sets.
    • If content is an update to doc sets already submitted to MSDN, provide a list of content that has been added or removed
    • Product team contact: name of a contact to whom we should log Product Studio bugs. All bugs will be assigned to this alias; this person can in turn reassign bugs to others on their team, as necessary.
    • Live date requested for this content
    • Location from which docs can be obtained. For online, that location is file://ppgbuild01/webcollection. Just indicate here that your files have been dropped to the drop location.
    • Location requested in the master TOC, if this is new content or it needs to be moved within the Library
    • Other comments: record any special notes or comments here
    Note   Contributors can log multiple HXSs in one Product Studio bug (for example, multiple Windows CE or Exchange builds), but they will have to log a bug for each release of their product. This means that they will log a different bug for the MSDN Online Library, the MSDN Subscriptions Library, and the next release of Visual Studio, if applicable.

Reviewing Content for QA After It Is Built

Once content has been built, contributors must review content for Quality Assurance on file://MSDNPROD/library. Verify what is showing up according to the list below. The MSDN QA team also makes a QA pass on the content.

Your content must meet the following QA requirements:

  • TOC check—verify that:
    • All content is in correct location in the TOC
    • Topic pages open correctly
    • No pages contain File Not Found in the TOC page where the article's title should be
    • TOC and topic title are identical
    • Content titles should not appear as double nodes (title listed twice in descending levels). For instance:

      User Interface Basics
          Overview: User Interface Basics
              Overview: User Interface Basics

      The repeated title, "Overview: User Interface Basics," should only appear once, at the higher level, in the TOC.

  • Geopolitical check—verify the following:
    • Check the fix recommendations for English products in the English Terms Reference Guide (http://gpsweb/tools/policheck/DisplayTerms.asp?LCID=9) at the GeoPolitical Strategy Web site and verify that content does not include any of the "must fix" terminology.
    • Also, check the GeoPolitical Strategy home page for new geopolitical issues at Welcome to GPSweb (http://gpsweb/).
  • Functionality check:

    In addition to verifying basic functionality for Library functions, also check the following:

    • Cursory link check: Check random links in content to make sure nothing is wrong.
    • TOC sync check: Random check to make sure that content syncs to TOC
    • Script check: All special functions such as glossary look-ups and popups work as expected
  • Formatting check—verify the following:
    • That formatting within sections is uniform
    • That appropriate footer and CSS are inserted
  • Basic Proofing—verify the following:
    • High-profile dates and copyrights are current
    • Check for common typos and errors (missing graphics, common misspellings of Microsoft products and so on)
    • No gross formatting bugs or obvious errors (blank pages, bad margins/frames, broken toolbars and so on)

Content Maintenance Over Time

The content owner is responsible for making fixes subsequent to publishing, such as updating product naming, fixing broken links, making corrections in areas such as geopolitical issues, and following any other MSDN requirements that come into effect.

If new MSDN requirements come into effect, you will be contacted by your content manager to ask you to make the changes. We will always ask product teams to make changes rather than have MSDN do them to ensure that the changes appear in all future content drops. You may also make changes in your content for any reason. If your team is directing the redrop of content, please log a new Product Studio bug as discussed earlier. If MSDN directed your team to rebuild, please contact your content manager, who will help to facilitate the rebuild of your content.

Back to top

Drop Locations for Offline and Online Products

Because the MSDN Library is a family of different products, each product has unique handoff requirements.

  • For the quarterly MSDN Subscriptions Library CD/DVD product, drop to file://ppgbuild01/dropoff.

    If \\ppgbuild01\dropoff is closed (it is closed for submissions during that phase of the Quarterly cycle when necessary to guarantee the stability of the Quarterly builds), contributors must create their own public share, drop the content to that location, and note the location in their Product Studio bug.

  • For the MSDN Online Library, drop to file://ppgbuild01/webcollection.

Things to Remember

  • Be sure to log the drop location you have used in the appropriate Product Studio bug.
  • Remember to drop copies of files to multiple locations if it is to appear in several different products.
  • Once content has been dropped to any of the above locations, additional drops should be made to the same location.

Back to top

Further Reading

For further detailed information about preparing your product documentation sets, please continue on to the following resources:

Back to top

All information is strictly Microsoft confidential.
 
 
   
Web Part Menu
  MSDN: About Our Business
  MSDN Team Aliases & Contacts
  MSDN Teams
  MSDN OOF Calendar
  Intranet feedback alias
  MSDN team-only contacts (restricted access)
  MSDN Metrics
  Alert me to changes in Key Resources
 Add new link
Web Part Menu
  MSDN Online
  MSDN Online Developer Centers Index
  MSDN Subscriptions
  MSDN Magazine
  GotDotNet
  GDN Blogs
 Add new link
 
Add Web Parts Browse Search Import Design this Page Modify Shared Web Parts MSDN Online Links Page Title (this shows the same text as ... Handing Off Product Documentation Sets t... Confidentiality Reminder Page Footer Key Resources MSDN Public Sites Shared View Personal View Minimize Restore Close Delete Modify Shared Web Part Connections Export...