The mirror-tutorial and the usb-hotplug-tutorial have been moved to block bug 129722 (publication tracker). I believe I have incorporated all suggested changes from my editor -- thanks, Karsten -- and they should be ready for final review. I think I followed the workflow correctly; if not, let the paddling commence!
On Wed, 2004-10-13 at 06:17, Paul W. Frields wrote:
The mirror-tutorial and the usb-hotplug-tutorial have been moved to block bug 129722 (publication tracker). I believe I have incorporated all suggested changes from my editor -- thanks, Karsten -- and they should be ready for final review. I think I followed the workflow correctly; if not, let the paddling commence!
/me high-5s Paul
If you messed up the workflow, do what I do - blame the docs!
- Karsten
I am almost finished reading usb-hotplug-tutorial. mirror-tutorial is next on my list after reading gateway-server.
I set up 129722 for docs that were through the proof phase and were ready to push live. So, technically, they aren't supposed to move there yet. I would blame the docs, but I helped write them. ;-)
Thanks, Tammy
On Wed, 2004-10-13 at 09:17 -0400, Paul W. Frields wrote:
The mirror-tutorial and the usb-hotplug-tutorial have been moved to block bug 129722 (publication tracker). I believe I have incorporated all suggested changes from my editor -- thanks, Karsten -- and they should be ready for final review. I think I followed the workflow correctly; if not, let the paddling commence!
-- Paul W. Frields, RHCE
On Thu, 2004-10-14 at 16:03, Tammy Fox wrote:
I am almost finished reading usb-hotplug-tutorial. mirror-tutorial is next on my list after reading gateway-server.
I set up 129722 for docs that were through the proof phase and were ready to push live. So, technically, they aren't supposed to move there yet. I would blame the docs, but I helped write them. ;-)
You can't blame them anyway, it was my fault. I went back and reviewed the Quick Start Guide again, and it does state that "once the writer and editor feel it is ready to be published to the website, make bug 129722 depend on this bug so the project maintainer can review it and post it to the website." I didn't read carefully enough, so shame on me.
Consider these errors as, um, time-savers this time around. Yeah, that's the ticket. :-)
On Thu, 2004-10-14 at 13:56, Paul W. Frields wrote:
On Thu, 2004-10-14 at 16:03, Tammy Fox wrote:
I set up 129722 for docs that were through the proof phase and were ready to push live. So, technically, they aren't supposed to move there yet. I would blame the docs, but I helped write them. ;-)
You can't blame them anyway, it was my fault. I went back and reviewed the Quick Start Guide again, and it does state that "once the writer and editor feel it is ready to be published to the website, make bug 129722 depend on this bug so the project maintainer can review it and post it to the website." I didn't read carefully enough, so shame on me.
I've read this several times now, and I still get the same interpretation.
1. Writer (Paul) and Editor (Karsten) think the doc is ready, so it gets pushed to 129722
2. Web editor/maintainer (Tammy) continues workflow in 129722, doing a final edit before publishing.
Isn't this what Paul did?
Now, if what Tammy -meant- was that 129722 was only for docs that are totally edited, and literally just in the queue for inclusion on the website, then we need to fix the docs to reflect that.
I think of this in terms of the roles and the workflow. In the current situation, Tammy is filling several roles, i.e., project maintainer, Web maintainer, publication editor, etc. Since these are roles, they can be parsed into different people, and their actions are associated with different phases in a document's lifecycle.
Below is a representation of the workflow, aiui.
In this situation, I completed the Editing phase and sent the documents onto the Publication phase, which is represented in 129722. In that phase, if Tammy finds enough problems, she can send it back to me to resolve as I see fit, or bounce it all the way back to the Writing phase. The latter wouldn't usually occur; minor edits can be done by the publication editor, editor, or writer.
A different workflow, which is what I think Tammy is talking about, would have two parts to the Editing phase, or just insert a Publication Editing phase after the Editing phase. So, it just comes down to where we think the final-final edit/check-over should be in the workflow.
# Current Workflow
## Writing phase
Writer writes Editor observes
## Editing phase
Editor edits, can send back to Writing phase or send on to Publication phase
## Publication phase
Publication editor does a final read, approves or sends back to Editing or Writing phases.
Web maintainer takes a document, only after it's been approved for publication, and puts it on the site. Any problems after that go through a bug maintenance phase.
On Fri, 2004-10-15 at 12:35 -0700, Karsten Wade wrote:
On Thu, 2004-10-14 at 13:56, Paul W. Frields wrote:
On Thu, 2004-10-14 at 16:03, Tammy Fox wrote:
I set up 129722 for docs that were through the proof phase and were ready to push live. So, technically, they aren't supposed to move there yet. I would blame the docs, but I helped write them. ;-)
You can't blame them anyway, it was my fault. I went back and reviewed the Quick Start Guide again, and it does state that "once the writer and editor feel it is ready to be published to the website, make bug 129722 depend on this bug so the project maintainer can review it and post it to the website." I didn't read carefully enough, so shame on me.
I've read this several times now, and I still get the same interpretation.
- Writer (Paul) and Editor (Karsten) think the doc is ready, so it gets
pushed to 129722
- Web editor/maintainer (Tammy) continues workflow in 129722, doing a
final edit before publishing.
Isn't this what Paul did?
Now, if what Tammy -meant- was that 129722 was only for docs that are totally edited, and literally just in the queue for inclusion on the website, then we need to fix the docs to reflect that.
I think of this in terms of the roles and the workflow. In the current situation, Tammy is filling several roles, i.e., project maintainer, Web maintainer, publication editor, etc. Since these are roles, they can be parsed into different people, and their actions are associated with different phases in a document's lifecycle.
Below is a representation of the workflow, aiui.
In this situation, I completed the Editing phase and sent the documents onto the Publication phase, which is represented in 129722. In that phase, if Tammy finds enough problems, she can send it back to me to resolve as I see fit, or bounce it all the way back to the Writing phase. The latter wouldn't usually occur; minor edits can be done by the publication editor, editor, or writer.
A different workflow, which is what I think Tammy is talking about, would have two parts to the Editing phase, or just insert a Publication Editing phase after the Editing phase. So, it just comes down to where we think the final-final edit/check-over should be in the workflow.
# Current Workflow
## Writing phase
Writer writes Editor observes
## Editing phase
Editor edits, can send back to Writing phase or send on to Publication phase
## Publication phase
Publication editor does a final read, approves or sends back to Editing or Writing phases.
Web maintainer takes a document, only after it's been approved for publication, and puts it on the site. Any problems after that go through a bug maintenance phase.
Thanks for writing this out Karsten. Yes, I meant that I think there should be 2 phases after the edit phase -- one in which the publication editor reviews it and once in which the web maintainer publishes it after publication editor handoff. Perhaps we need another tracker bug? I hate to add even more process into the mix, but it would make it easier for me to remember which tutorials need my edits and which just need to be pushed live (other than the post-it note on my LCD). Right now, there seems to be one tracker bug with the label "Docs ready for going to fedora.redhat.com. " To me, the label implies they have past the publication editor phase. So, we either need to add another tracker or change the summary of the tracker bug to be more inline with its purpose.
Tammy
On Tue, 2004-10-19 at 11:06, Tammy Fox wrote:
[snipped process]
Thanks for writing this out Karsten. Yes, I meant that I think there should be 2 phases after the edit phase -- one in which the publication editor reviews it and once in which the web maintainer publishes it after publication editor handoff. Perhaps we need another tracker bug? I hate to add even more process into the mix, but it would make it easier for me to remember which tutorials need my edits and which just need to be pushed live (other than the post-it note on my LCD). Right now, there seems to be one tracker bug with the label "Docs ready for going to fedora.redhat.com. " To me, the label implies they have past the publication editor phase. So, we either need to add another tracker or change the summary of the tracker bug to be more inline with its purpose.
Actually, that sounds like it's just part of the Editing phase. The approach would be:
1. New doc gets new individual tracking #, blocking the active bug tracker
2. Writer is assigned to that bug.
3. Writer assigns that bug to the Editor for editing. If the Editor needs to kick it back to the Writer, reassign it back. Otherwise, the Editor assigns it to the Publications Editor (or Editor-in-Chief or whatever we call that role).
4. Pub Editor does the final-final check. If it's sent back, it stays blocking the same bug, but gets individually reassigned to the Editor (or Writer). If it's approved, it gets assigned to the Web Maintainer -and- moved to block the ready-for-publication bug.
How's that?
I need a swim diagram for this stuff. :)
- Karsten
On Tue, 2004-10-19 at 12:20 -0700, Karsten Wade wrote:
On Tue, 2004-10-19 at 11:06, Tammy Fox wrote:
[snipped process]
Thanks for writing this out Karsten. Yes, I meant that I think there should be 2 phases after the edit phase -- one in which the publication editor reviews it and once in which the web maintainer publishes it after publication editor handoff. Perhaps we need another tracker bug? I hate to add even more process into the mix, but it would make it easier for me to remember which tutorials need my edits and which just need to be pushed live (other than the post-it note on my LCD). Right now, there seems to be one tracker bug with the label "Docs ready for going to fedora.redhat.com. " To me, the label implies they have past the publication editor phase. So, we either need to add another tracker or change the summary of the tracker bug to be more inline with its purpose.
Actually, that sounds like it's just part of the Editing phase. The approach would be:
- New doc gets new individual tracking #, blocking the active bug
tracker
Writer is assigned to that bug.
Writer assigns that bug to the Editor for editing. If the Editor
needs to kick it back to the Writer, reassign it back. Otherwise, the Editor assigns it to the Publications Editor (or Editor-in-Chief or whatever we call that role).
- Pub Editor does the final-final check. If it's sent back, it stays
blocking the same bug, but gets individually reassigned to the Editor (or Writer). If it's approved, it gets assigned to the Web Maintainer -and- moved to block the ready-for-publication bug.
How's that?
I need a swim diagram for this stuff. :)
Sounds good to me.
This brings back memories of drawing state diagrams in Automata class. ;-)
- Karsten
-- Karsten Wade, RHCE, Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
-
Karsten Wade -
Paul W. Frields -
Tammy Fox