help define our workflow, other notes

[Paul W. Frields]

On Sat, 2007-07-14 at 16:18 -0700, Karsten Wade wrote:
[...snip...]
> > > 4) at stable, i assume only key members can edit... and this 
> > > is where we go to translations
> > > 
> > >         ## KW - This makes sense.  Translators find mistakes or have
> > >         questions/clarifications for the original; an editor or original
> > >         owner needs to be able to fix those and push the content back
> > >         for translation (generate a new POT, alert translators with open
> > >         PO files, whatever.)  How much of this can be done through
> > >         Plone?  Through CVS?
> > 
> > The more we can do through Plone, the easier it will be for non-techies
> > to help with documentation.  That's a major blocker for our subproject
> > right now -- I suspect there are people out there who can correct
> > grammar and write good standard English, but who are frightened of doing
> > CVS because they think they might irreparably break something.  (A silly
> > or at least misplaced fear, but you have to respect the fact that they
> > care.)  So if they can do this with a pleasant, or at least
> > comprehensible, web interface, that's a win in my book.
> 
> +1
> 
> This particular question around translators might be a bit different.
> By the time a translator has found an error, the content is in the
> 'stable' workflow state, and resolution needs to be handled by a more
> experienced team member (editor, writer) with sufficient permissions.  A
> decision has to be made (via bugzilla, mailing list) and a new POT
> pushed (if needed), then some social work has to be done (alert
> translators via mailing list, in addition to any workflow alerts they
> receive.)  In some cases, the error report was on a mailing list, where
> the solution gets worked out, and the thread needs to be closed.
> 
> So, there is going to be complexity and 'harder' here because of the
> number of people affected.  But I do agree that the tooling shouldn't be
> difficult to match -- i.e., don't make an editor drop to the CLI to
> handle this.  BUT -- the editor should be able to do this from the CLI
> (cvs + Jon's daemon).  And there should be sufficient
> checks-and-balances to ensure other contributors are not walked on by
> the changes. :)

How hard would it be for published/stable documents to have a standard
toolbar such as "Report Problem" -> Bugzilla autofilled entry?  And a
POT push, for example, should trigger something automagically from the
trans.fp.o app, right?  I would think it's a good idea to cut down on
multiplicity of error threading (mailing list, IRC, etc.) in favor of
single channels that have wide reporting flexibility for subscribers.
As a doc maintainer, I don't want to have to figure out which of four
ways to "close out" an error report -- everything should go through
Bugzilla, whether or not the reporter interacts with it initially in
that particular way.  Rather than making anyone join or post on a
mailing list, the document should offer an easy way to report problems.

> > Right.  Part of the reason we want this is for good interaction with
> > Dimitris' DL work, where fixes can be detected visually by L10N'ers...
> > or by people who like detecting automagically against
> > fedora-docs-commits.  
> 
> Detected one time and searched for in multiple instances?
> 
> http://translate.fedoraproject.org/search

I was talking just about simply detecting changes by looking at the
completion graphs, but this is cool too.

> > This does mean we have to get the Kupu-fu right,
> > or at least to a point where people like Karsten, me, Dimitris, John, et
> > al., can add styles to Kupu as needed to support all elements we use in
> > DocBook XML.
> 
> This is interesting to ponder.  We'll have to first decide how we are
> going from XHTML => XML, then test what that does with the various
> styles.  I reckon we can do a fair bit with CSS classes.  Might need a
> bit of custom work in between (XHTML => XML w/ classes => XML) to
> interpret the classes into the specific XML elements.  Or, you know,
> maybe it will have been done by someone already?

I would think that CSS classes would take care of this nicely, i.e.

<section id="sn-foo">
  <title>My Foo</title>
  <para>My foo is <emphasis>nice</emphasis>.
    I like foo. So will you.</para>
</section>


<div class="db.section" id="sn-foo">
  <div class="db.title">My Foo</div>
  <div class="db.para">My foo is <span
    class="db.emphasis">nice</span>. I
    like foo. So will you.</div>
</div>

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
      Fedora Project:  http://fedoraproject.org/wiki/PaulWFrields
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/docs/attachments/20070717/0cc98303/attachment.bin