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 backward
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. 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.
As we are moving our work on The Open Source Way entirely to the external-from-Red Hat open community space, one of the last bits is the video conference meeting we have once a week.
We captured this bit from our meeting as a best-effort-at-the-time toward transparency and accessibility especially for participants and contributors:
(Please let me know if you have any issues accessing that, I'll do the best I can. We didn't discuss it per-se in that video but our intention is to release content via this project under the CC BY SA 4.0 International Unported IIRC license. I'll make sure to have us state that in the videos in the future.)
This guide has been part of a larger editorial discussion for our team in the Open Source Program Office at Red Hat, and we use these weekly sessions to keep on track for active project work.
We're ready to have these meetings entirely where anyone from the community can join, observe, and participate. I would like to see us do that for the next meeting we have scheduled, which is 20 February.
We're willing to work quickly toward having meetings that work for many timezones; this one happens to line up nicely for our US-based folks who are attending after their morning-with-European meetings. It's something to discuss.
This meeting covered the following topics IIRC:
- We gave an enthusiastic account of the Birds of a Feather session from FOSDEM.
- We talked about project management, getting a milestone-based schedule, and where to do that. We settled on continuing to use the tools that GitHub has to offer, with the caveat our commitment there is only for the 2.0 release and can--and will--review other options for the future when we catch our breathes post-2.0 release.
- We did not discuss actual release dates, that's for us to figure out here and in the meeting.
- We may have discussed some of the SCaLE workshop logistics.
I haven't re-watched this one since we had the meeting and do not have good contemporaneous notes. But I've been stuck getting this out and I have the few minutes right now to write up the best note, and anyone who watches feel free to chime in this thread with notes and/insights.
Our intention aside from a high degree of transparency is a higher degree of accessibility. At the moment, we are falling short of that goal. We feel that moving as quickly as we can in that direction while doing the best we can does the best job of--at the least--leaving a trail that can be made more accessible over time.
Apologies if this is jumping the gun, but I would just like to express my interest in picking up any of the discussions/sections that were jotted down from the Dev Room.
There were a lot of good sections to be introduced. Is there a visible overview of sections that require 'content'?
Apologies if this is jumping the gun, but I would just like to express my
interest in picking up any of the discussions/sections that were jotted
down from the Dev room.
There were alot of good suggestions to be introduced. Is there a visible
overview of sections that require content?