I've been working on a new project board for tracking our editorial work
and wanted to share it (along with a bit of context!). You'll find it here:
## The workflow
The project board is a kanban-style board designed to help The Open
Source Way authors and editors visualize progress writing and editing
the book's contents.
When they appear, editorial issues ("something needs to be written,"
"something needs to be expanded," "something needs to be edited,"
"something needs to be corrected," etc.) will go on this board. They'll
move along the editorial workflow through the following steps, each of
which is represented with a different column on the board.
The workflow proposed here operates like this:
To Assign: Project managers have identified the issue as an editorial
issue and placed it on the board, but haven't yet assigned anyone to
work on it.
Assigned: Someone has agreed to write or edit material that addresses
the issue, and it's been assigned to them.
Drafting: That writer is now composing the material addressing the issue.
Draft Review: The writer has finished the draft and would like project
managers and editors to review it. Project managers and editors will
determine whether the writing sufficiently addresses the issue. If it
does, the card move "forward" to "Editing." Otherwise, it moves
Editing: An editor is now reviewing and making editorial changes to the
material. If the editor determines that additional work is necessary,
that editor will move the card "backward" to the appropriate column
(i.e., back to "Drafting" if more writing is necessary, or to "Draft
Review" if authors and project managers should simply take another look
to confirm something). If the editor deems the work complete, then card
moves "forward" to "Formatting."
Formatting: A technical editor is reviewing the writing and "marking it
up" (in AsciiDoc) if it's not already. As part of this process, the
technical editor ensures that the work conforms to other technical
parameters (line spacing, footnote formatting, etc.) and will "compile"
as part of the book.
Final review: Project managers and any other stakeholders who may need
to review the work one more time have the opportunity to do so here.
Completed: Finalized issues are moved here; they're closed closed, and
their associated materials are merged.
## Sections, chapters, topics
The project board conceptualizes The Open Source Way as comprised of
"sections," "chapters, and "topics." Sections contain chapters.
cover various topics.
As initially outlined, the book consists of these sections:
- Introductory Material
- Attracting Users
- Guiding Participants
- Growing Contributors
- Measuring Success
- Avoiding Pitfalls
Each of those sections has a corresponding "label" in the repository.
We'll assign chapters to sections. When we've determined the section in
which a particular chapter should be included, we can attach that
section's label to the issue associated with the chapter. For example,
the proposed chapter on "participant motivations" will likely appear in
the book section dedicated to guiding participants, so it gets the
"Guiding Participants" label in our repository.
Each section will contain several chapters. Chapters begin as issues
filed in the project repository. At minimum, issues proposing new
chapters should elaborate:
- The subject, aim, and scope of the chapter
- Potential topics the chapter might cover
Modifications to or suggestions on chapters also appear as issues.
Project managers will triage these issues and, upon recognizing them as
editorial issues, assign them to the editorial project board (see above!).
Each chapter will cover several topics. Readers can file issues
suggesting new topics for chapters, revisions to existing topics, etc.
As topics expand, they may become their own chapters. As chapters
expand, they may become their own sections.
... and that's as far as I've gotten!
Feedback certainly welcome.