General questions and suggestions

Hi Marc, :slight_smile:

Also, if we are going to keep advertising the virtues of the ODF files. It
would seem to make sense that we find ways to make the ODF files system
"play nice" with the internal document flow. What better occasion would we
get than having the use of a corporate-like structure such as the
"TDF/LibreOffice document team division" use the ODF files internally at
developing documents from start to end.

+1 ... And a better starting point for conversions to other formats,
too, IMHO, after I thought further about the question. :slight_smile:

David Nelson

Thanks Nino.

That is exactly what I am proposing. If we can't use the ODF in a pragmatic way with our suite, then, how can we advertise that it is so to others?

Marc

It's not only about being able to use ODF but in addition about what is
the most efficient/pragmatic workflow for delivering good quality
documentation in time. Therefore, we have to test all possibilities and
to choose what is most appropriate. And stay prepared to adapt/change
our workflow when needed.

Nino

Yes, I'm an old-timer in the OOo project, having been around since 2002,
lead editor at OOoAuthors since 2004-ish, Co-Lead of the Documentation
Project since early 2009 (continuing).

However, I am too busy to take on a lead role with LibO docs. I see my
role as "senior adviser" -- "senior" in terms of the OOo old-timer
aspect as well as my age. And BTW, I'm a she. :wink:

Regarding the "international English" vs "US English" discussion, at
OOoAuthors we had been using the US English version of the *software*
because way back when, the British English version was not readily
available as it is now. I suspect the US-Eng version is still more
commonly used internationally, but I've not attempted to find any
statistics on this.

So if the screenshots are from the US-Eng version of the software, then
the text should be in US-English *spelling* to match the software.
However, the *punctuation* can (and IMO should) be in the more logical
"British" style. Actually, the differences are minor and most of them
are easily avoided.

--Jean

Marc, you have expressed my opinion on this subject better than I can.
Thank you.

--Jean

Hello David,

> > Historcally, the question has been raised a couple of years ago in
> > the ooo project. The answer was to use the format in which most
> > people preferred to contribute (which seems pretty rational). Both
> > possibilities were offered, but AFAIK the community has preferred
> > ODT for writing User Guides by far, whereas Dev Documentation has
> > been mainly produced in wiki form.
> >
> > I don't think that a formal decision has been made. Up to now,
> > there is no official (or inofficial) team in charge of the doc
> > project. So who should make a decision? Things are just evolving
> > :wink:
>
> Jean Hollis Weber seems to be active in documentation, and seems to
> have been an old-timer in the OOo project (if I'm not mistaken)...
> Maybe he's the kind-of de facto lead for the moment?

Jean is a "She", and she has led the OOoAuthors project since it's inception
and if you had done a bit of research you would have found out that she is a
highly respected Technical Editor and a published Author on things OOo. And
I'm not so sure she would get off being referred to as an "OldTimer" :slight_smile:

Frankly I see no reason why we don't use OOoAuthors as the place to produce
documentation. The software in general will be the same with minor
differences. The challenge for the LibreO team will be keeping track of and
documenting those differences. OOoAuthors is not part of OOo it is an
independent group that happens to contribute to the OOo documentation project.
Any fork or version based on the OOo source could use the OOoAuthors Manuals.

As the ooo community as a whole did not follow the transition to LibO,
my feeling is that the community here is kind of starting from scratch.
We should take the chance and try to establish our own identity, leads
and processes. IMHO, of course.

To me, the most productive thing people could do is join the OOoAuthors team
and contribute there, then take the product and edit and add to suit for
LibreO. For instance pdf import is installed by default, a chapter for that
or standard extensions would have to be added and so on.

But maybe I'm wrong, so don't take my words for the only truth possible.

Jean, you're always welcome to take/continue your role as doc lead here,
too :slight_smile:

I'm so glad that you have the Authority to grant this. :confused:

cheers
GL

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.