General questions and suggestions

Just a suggestion, but why not have a British version of the user guides as well as a US version? That way each user can have it in his/her native language conventions.

As for the workflow, what about using the odf format for creating the user guides and posting the actual files online as soon as changes have been made and then, after they are finished, converting them to the wiki. Save as pdf is a simple process as well.

Ron

Just a suggestion, but why not have a British version of the user guides
as well as a US version? That way each user can have it in his/her
native language conventions.

If someone has the time to redo the books and those screenshots that
differ, that would be great. But at OOo we have enough trouble just
keeping one set of manuals up to date.

As for the workflow, what about using the odf format for creating the
user guides and posting the actual files online as soon as changes have
been made and then, after they are finished, converting them to the
wiki. Save as pdf is a simple process as well.

That is what we do at OOo, and as I've written here before, IMO that's
the best overall approach... especially since the people who do most of
the work on the user guides prefer to create/review/edit in ODT.

As I'm sure others have pointed out, the best workflow is one that
*works* in terms of getting docs done using the resources available.

--Jean

Thanks Nino.

Yes, always best to use the right tool for the job. I was just trying to comment that we were actually the people building the tool and it would be quite the opportunity here to better fine tune our tool in this process while the document team had a direct feed to the devs. What better way to prove that your tool if built for complete document production from start to finish.

But I understand that there are time and schedule constraints to meet.

Cheers

Marc

sorry, it's not about authority but opinion - so I'd better stated:

"I've no doubt that you're welcome here, too"

:wink:

Nino
speaking always in behalf of myself unless explicitly stated

Sorry to the documentation team if this seemed a negative comment on your production process. I think that most members who have taken the time to read your posts have come to the same conclusion as I, in that you are very professional in your approach to documentation as well as in respecting the production flow.

In some ways I feel apprehensive to thank you because I don't think that any of you would be anything else than this in any other comparable tasks. Thank you and my respects.

But in the same breath ... I will still add my opinions when and where I can. :slight_smile:

Marc

Marc, please do! And I, at least, did not take your comments negatively.
I agree with all you said, and you said it well.

--Jean

[...] I was just trying
to comment that we were actually the people building the tool and it
would be quite the opportunity here to better fine tune our tool in
this process while the document team had a direct feed to the devs.

not sure what you mean by having "a direct feed to the devs" (I'm not a
native speaker so sometimes I have to ask for better understanding,
sorry)

I think we should roughly catch requirements, then ASAP pick and provide
appropriate tools and start working as soon as possible. Fine tuning
can be done successively, as all parties will be learning by doing.
Call it prototyping or similar, I'm not an expert here.

What better way to prove that your tool if built for complete
document production from start to finish.

The tool has to be adequate/appropriate. For Internet collaboration,
mere ODF is not (yet) good enough, wiki and web are far more
appropriate. But nonetheless, it's a challenge to set up appropriate
workflows and supportive tools (and BTW that's one of the reasons for
me to participate here).

But I understand that there are time and schedule constraints to
meet.

Don't forget that we are setting our constraints ourselves :slight_smile:

N.

I'll add that using the OOoAuthors website to produce LibO docs does NOT
mean that the LibO docs team is required to follow the procedures we use
for producing OOo docs. Indeed, I think some of the native-language
groups using the website follow slightly different processes from those
used by the English-docs team.

Also there is nothing to prevent the LibO docs team from switching (if
they choose to) from using the OOoAuthors website to using the Document
Foundation's site when it's up and running, doc procedures tested, and
so on.

IMO the team should use the most efficient methods available now to get
out the first release of user guides ASAP, and then refine methods as we
go along. Same for fonts and other issues like whether or not to use
heading numbering. With a properly set up template, fonts and heading
numbering and other changes can be made quickly and easily at any time.

--Jean

Thanks for the info.

Cheers

Marc

Thanks.

Marc

In that case, why not a Canadian version as well.

I will be converting every document into Aussie!

Just a taste:
"G'day, this is the bonza Libra Office kick off guide, grab a beer and start
typing!"

Michael Wheatland

Mate, getting the name of the product correct would be a good idea,
regardless of the dialect into which a document is localised.
*LibreOffice*

--Jean
(waving from Townsville, North Queensland)

Just a play on our pronunciation of the word Libre (Libra, like the
way we say Litre)
By the way, I am not far away from you, just over the gulf in Nhulunbuy.

Just a play on our pronunciation of the word Libre (Libra, like the
way we say Litre)

You say "litra"? I knew you Territorians talked funny, but I don't
recall hearing that one before. I learn something new every day!

--Jean

Jean Hollis Weber wrote:

I'll add that using the OOoAuthors website to produce LibO docs does NOT
mean that the LibO docs team is required to follow the procedures we use
for producing OOo docs. Indeed, I think some of the native-language
groups using the website follow slightly different processes from those
used by the English-docs team.

Well, the Italian team for instance only translates the published
English chapters, so it's expected that their processes are different.
In our case, the volunteers' choice was to base on the English ODT
version.

We thus have:
- English ODT -> English Wiki (through the "Wiki Publisher" extension)
- English ODT -> Italian ODT (through OmegaT and translation memory)
- Italian ODT -> Italian Wiki (through the "Wiki Publisher" extension)
- English Wiki -> Italian Wiki is forbidden

This, thanks to translation memories, proved to be the best workflow
when updates are concerned; and, if someone is going to adapt the
OpenOffice.org documentation to LibreOffice, this might be a good
approach to minimize the volunteers' efforts.

Regards,
  Andrea Pescetti.

Thanks Andrea, we will make a note of it for the Drupal setup.

Marc

BTW ... let us know if you need any other customizations and we will look into it as well.

Cheers

Marc

Hello,

I must confess that I read the thread fairly quickly so I may have missed some points, but here we go with my observations.

Language
It has to be en-US since, at least for OOo, this is the default language and the one you get in addition to the localized version.
Though I would like to see colour, metre, centre written correctly :wink: I think you can live with this choice.

File format
My preference is to use ODF.
No doubt that the wiki version is much more dynamic and better suited for a collaborative environment, but it also has drawbacks (review of entries, printing, tracking of the program version)

Workflow
There is another thread on this so to keep it short, I think we should stay with something similar to OOoAuthors based on
draft --> review --> publish
What is missing in OOoAuthors is a definition of the role of publisher / "editor in chief" that is the person(s) that decide when to pull the trigger and publish. At present Jean takes care of this (and does a great job) but if it wasn't for her dedication I do not know how a document would be deemed ready for publishing.
So some work to do there.

Template
I guess it does not make much sense to depart from the template used by OOoAuthors that over time has been refined and improved.
You may want to consider making better use of colours, adding heading numbers, make it more modern-looking but I am not sure that should be a priority unless you want to give the LibO guides their own identity from the start.

Cheers,

Michele

Hello,

I must confess that I read the thread fairly quickly so I may have missed some points, but here we go with my observations.

Language
It has to be en-US since, at least for OOo, this is the default language and the one you get in addition to the localized version.
Though I would like to see colour, metre, centre written correctly :wink: I think you can live with this choice.

File format
My preference is to use ODF.
No doubt that the wiki version is much more dynamic and better suited for a collaborative environment, but it also has drawbacks (review of entries, printing, tracking of the program version)

Workflow
There is another thread on this so to keep it short, I think we should stay with something similar to OOoAuthors based on
draft --> review --> publish
What is missing in OOoAuthors is a definition of the role of publisher / "editor in chief" that is the person(s) that decide when to pull the trigger and publish. At present Jean takes care of this (and does a great job) but if it wasn't for her dedication I do not know how a document would be deemed ready for publishing.
So some work to do there.

Template
I guess it does not make much sense to depart from the template used by OOoAuthors that over time has been refined and improved.
You may want to consider making better use of colours, adding heading numbers, make it more modern-looking but I am not sure that should be a priority unless you want to give the LibO guides their own identity from the start.

Cheers,

Michele