openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From F Campos Costero <>
Subject Re: Trying to re-generate the Documentation effort
Date Mon, 01 Jun 2020 22:23:49 GMT
I am not sure that this part of the process has to remain as it is.
> Unfortunately that is not going to change a whole lot. Just as the
> development effort is self directed so is the Documentation effort and
> all volunteers are advised of that.

If we can increase participation in the documentation work by having
someone to assign tasks to others, that seems like a reasonable change to
make. I am willing to take on coordinating the assignments if others can
help create a reasonable list of tasks. To be clear, if someone wants to be
self directed, that would be great. If someone feels more comfortable being
given a task, having a specific person to contact for help and perhaps
having a little checking in on progress, I can do that. I have no training
in technical writing. I took a quick look at DocBook and it does not seem
conceptually difficult, so I can try to learn that. If someone can give me
a little help at first, I would appreciate it.

If you are wondering who I am, I have been a moderator on the user forum
for about 10 years.


On Mon, Jun 1, 2020 at 9:58 AM Keith N. McKenna <>

> On 5/31/2020 10:41 PM, Peter Kovacs wrote:
> >
> > Am 31.05.20 um 02:41 schrieb Keith N. McKenna:
> >
> >> Another would be to use Docbook, though this is not as appealing as I
> >> have no familiarity with it and it appears that there is a steep
> >> learning curve to its use and that would be a disadvantage to attracting
> >> new people.
> >
> > The SUSE documenters use(d) Docbook to create multiple targets for
> > documentation.
> I like the idea of DocBook and since AOO will create the version 4.1.2
> DTD for the XML structure the learning curve for a volunteer is greatly
> reduced. The learning curve would be myself and hopefully others in
> learning how to generate the different formats for distribution.
> >
> > They presented their way on FOSDEM in 2017, for LO. It was very
> > interesting. But I dont know if they stick to it, because LO shifted all
> > documentation into the web.
> >
> > And created a Platform similar to pootle. (I never looked at it, just
> > what I picked up from my FOSDEM visits)
> From What I can see from a cursory inspection of there documentation
> pages they have taken over the old ODF Authors site At least that is
> where the link in the old documentation from ODF Authors redirects to.
> >
> >>
> >> I look forward to any other suggestions that could move this effort
> >> along as it has languished for far to long.
> >
> > IMHO the first step is to create a plan. Dividing the plan into work
> > packages that can be promoted is important.
> >
> > Because all people who expressed interest expected they are told what
> > needs to be done where. They did not felt
> >
> > comfortable to figure that out on their own.
> Unfortunately that is not going to change a whole lot. Just as the
> development effort is self directed so is the Documentation effort and
> all volunteers are advised of that. One the the ultimate goals I have in
> mind is to re-invigorate doc@ as the place for all things related to
> documentation to help create the the community that will be necessary..
> >
> > Also socializing seems to be important. The volunteers do not want to
> > work "alone". They want to be part of something.
> >
> > How it is done, did not seem so important to me on first spot.
> >
> >
> > I just want to point out, since I had multiple discussions now. ProOOBox
> > (Jörg care to share some details?) is working on a documentation update.
> >
> > Integrating them would be very nice from my stand point.
> Yes it would be, but could take a large translation effort if the
> Documentation they produce is not currently in English
> >
> >
> > That is my experience from Recruiting and AOO ComDev efforts I have been
> > involved in.
> >
> >
> > HTH
> >
> > Peter

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message