Skip to content

Latest commit

 

History

History
46 lines (40 loc) · 3.82 KB

guide-publishing-workflow.md

File metadata and controls

46 lines (40 loc) · 3.82 KB
Raw
title description draft
Guide Publishing Workflow
Learn how to create a great guide.
true

Roles: Submitter, Writer, Editor, Management Team, Technical Resource, Tester, Marketing Content Manager

  1. Submitter has an idea. In Sprint.ly Documentation Someday column, they add:
    • Working Title
    • Summary - At least 3 sentences about the problem, solution, background, value, and similar docs.
    • If they want to write the Guide
  2. At the weekly Backlog Review Meeting, the Management Team reviews, approves, outlines each approved card and moves to Backlog. Each outline includes:
    • Problem statement
    • Solution
    • Steps: One or several tasks, steps, or goals
    • Proof of Completion
    • Next Steps: further reading, links to other guides
  3. Writer chooses Guides to write from Backlog (They are tagged as ‘Guide’). They move the tasks to in Progress and add separate tasks to the Backlog for each task (titles of tasks are shown below):
    • 1st Draft
    • 1st Edit
    • Testing
    • Final Review
    • Founder Review
    • Author Signoff (optional)
  4. Writer consults with Technical Resource or Management Team to clarify objectives or ask questions.
  5. Writer writes first draft, submits to Editor for review. Completes “1st Draft” task.
  6. After edits, Editor sends to Tester.
  7. Tester reviews and repeats steps to make sure they are technically correct. They send back to Editor when complete. Editor completes the Technical Review task. Editor notifies Marketing Content Manager to create counterpart blog.
  8. Editor does the Final Review and completes the task. Assign to Scott for Management Team review.
  9. After management review at the Weekly Backlog Review meeting, Scott assigns back to Editor for publishing.
  10. Editor publishes.
  11. Profit.

Pull Requests

It's important that moderators know what follow up actions are required when Pull Requests are issued. That makes creating a detailed Pull Requests essential to the process. Each PR should include the following:

  • Purpose Statement: Start by explaining why it should be merged. All requests should communicate the full scope of edits made. Don't assume familiarity with the history of any task.
  • Associated Links: Have a Sprint.ly task? Reference it.
    • ex: completes item:92 draft
  • Review Needed: Be clear about what you expect to come from this request. If you would like feedback, tag who should review it and what should happen next.
  • If a request is issued to create a dialogue between contributors, include the prefix WIP indicating that the PR is a work in progress. This will help moderators know what's ready and what's not ready to go into production.

Merge Instructions

When the doc has received a +1 from a founder and editor. Merge and publish it. Delete the branch. Any fixes noticed after the fact will enter a normal update workflow.