Re: [DISCUSS] Cleanup installation files, make them more modular

[Joost Andrae]

Hi Marcus,

Am 26.10.2012 23:06, schrieb Marcus (OOo):

I've modified the subject as I think this topic deserves its own, new
thread.



that is a good idea.


Am 10/26/2012 07:28 PM, schrieb Ariel Constenla-Haile:

On Wed, Oct 24, 2012 at 05:27:41PM +0200, Jürgen Schmidt wrote:

Once thing to pay attention for the next release is the increasing size:
more than 14 Gb for Linux packages only. This is going to be even more,
as more languages are added. INFRA has already complained after the
first release (can't find the message right now) about the size of our
dist/ folder, so we must think about a solution, before they complain
once the next release is uploaded.


IMHO you can think and try whatever you want. At the end there is only
one solution:

Cleanup the packaging, delete redundat files, rearrange how the install
files will be packed, think new how the installation on the users-side
could be done.



I have some items to add:

- The installer packages should be modulized to allow the selection of 
parts (already done but we shouldn't forget to work on this)
- Localizations should be separated from the binaries (soffice.bin, 
libs, resfiles). Maybe it's a good idea to separate language packs from 
the installer and that localizations are not part of the base 
installation package (this can solve parts of the INFRA issues)
- The installer structure should allow small updatable packages (we 
already had this for MSI, MSP files). We should think about designing a 
more heterogenous approach for introducing a patch based update process.
- Documentation might be divided into parts that link to the soffice 
instance (via HelpIDs) and into parts that allow intermediate updates 
without interfering with the application logic. This would allow a 
continous development process for those who like to work on 
documentation items.


Just my 2 Euro Cents...

Joost

Re: extensions and translations.

[jan iversen]

I agree with you, we should NOT put a new framework on extensions writer.

I was thinking along the lines of

make a new directory ./extras/extensions/source, with files .

The extension writer must submit the file (we do not collect them) through
a committer.

This directory would then go into the normal l10n workflow, and the
resulting translation would go back into the same directory as ..po

jan.

On 27 October 2012 03:53, Ariel Constenla-Haile  wrote:

> On Sat, Oct 27, 2012 at 01:17:33AM +0200, jan iversen wrote:
> > I see, I have to get used to this license issues (a long time ago I
> > believed open source was just open source, then I joined an apache
> project).
>
> It has nothing to do with licensing. Even if the extension code and all
> its dependencies are under the ALv2, why should OpenOffice include
> extensions by default in the install set? This goes against the concept
> of an extension.
>
> The fact that now there are three supported extensions is just
> a question of old Sun/Oracle decisions to release these as extension and
> not integrated as part of the application.
>
> >
> > never mind.
> >
> > Would it be to our advantage if we offered third party developers (that
> is
> > how I see extension developers) the possibility to register a language
> file
> > and get it translated as part of the language packs ?
>
> This will break several concepts and things. Mainly extension developers
> have complete freedom about when to release updates, how to integrate
> translation in their extensions (use the configuration API and XCU
> files, use the resource API and Java-property-like files, etc.), most
> important what license to choose, etc.
>
> In short, you will have to implement a new framework and force
> extensions developers to use it. Besides several concerns, legal
> concerns among them.
>
>
> > Or should we just say extension developers does not concern us (and help
> > AOO get more used) so we just look the other way ?
>
> Programmability and extensibility has always been a priority in
> OpenOffice, just read the Developer's Guide and other parts of the wiki.
>
> I tend to agree that it will be useful for an extension developer a way
> to submit a set of resource strings and get them translated, as long as
> the extension developer is not forced with release/legal/other concerns.
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>

Re: [PROPOSAL] "difficulty" field for Bugzilla

[Andrea Pescetti]

jan iversen wrote:

The process should be:
- someone reports and describes a bug
- someone technically qualified confirms the bug, put a comment in on where
the bug probably sits and gives it a level.
Or is that too much ??


It is more complex than that, because we have dozens of people who are 
able to confirm and triage a bug (e.g., OpenOffice crashes on an Impress 
presentation; they can verify that it happens under multiple operating 
systems, detect whether this is a regression with respect to a previous 
stable version, produce a minimal presentation exhibiting the crash) but 
are not able to estimate where the code should be changed and what the 
impact of the fix is.


So, the difficulty flag is a welcome addition, but we should probably 
restrict access to it (if not by system privileges, at least by internal 
policy), much like it happens for the "Release blocker" field.


Regards,
  Andrea.

Re: extensions and translations.

[Marcus (OOo)]

Am 10/27/2012 03:53 AM, schrieb Ariel Constenla-Haile:

On Sat, Oct 27, 2012 at 01:17:33AM +0200, jan iversen wrote:

I see, I have to get used to this license issues (a long time ago I
believed open source was just open source, then I joined an apache project).


It has nothing to do with licensing. Even if the extension code and all
its dependencies are under the ALv2, why should OpenOffice include
extensions by default in the install set? This goes against the concept
of an extension.

The fact that now there are three supported extensions is just
a question of old Sun/Oracle decisions to release these as extension and
not integrated as part of the application.



never mind.

Would it be to our advantage if we offered third party developers (that is
how I see extension developers) the possibility to register a language file
and get it translated as part of the language packs ?


This will break several concepts and things. Mainly extension developers
have complete freedom about when to release updates, how to integrate
translation in their extensions (use the configuration API and XCU
files, use the resource API and Java-property-like files, etc.), most
important what license to choose, etc.


Right. Then they are no longer independent from their own release plan 
as they may would like to be.


Furthermore, I don't know how many extensions Sourceforge is hosting but 
it could hundreads if not thousands. Lets assume 10% of them will say 
"yes AOO, please translate the strings for me" then we have a lot more 
to do. And who should verify the translations? If we, then we have to 
install these hundreads/thousands extensions to see how it's working. If 
the developer, then do we get feedback in time? What about errors, are 
we able to fix them in time?


I think you can see now that the extension development has it own small 
but fine ecosystem. It doesn't fit into the AOO release process and IMHO 
this was never the idea.


However, thanks for making these thoughts. :-)

Marcus




In short, you will have to implement a new framework and force
extensions developers to use it. Besides several concerns, legal
concerns among them.



Or should we just say extension developers does not concern us (and help
AOO get more used) so we just look the other way ?


Programmability and extensibility has always been a priority in
OpenOffice, just read the Developer's Guide and other parts of the wiki.

I tend to agree that it will be useful for an extension developer a way
to submit a set of resource strings and get them translated, as long as
the extension developer is not forced with release/legal/other concerns.

Re: Ambiguous paths for module hunspell

[Oliver-Rainer Wittmann]

Hi,

Am 27.10.12 08:03, schrieb Ian C:

Hi,

I saw a post back in Aug 4 where Pedro had

build -- version: 275224
Ambiguous paths for module hunspell:

I just updated my svn and get the same thing.

Anyone have a solution?



Yes :-)

the folder/module hunspell is moved from folder /main to /ext_libraries. 
The folder hunspell in folder /main is not deleted by an svn update, if 
it contains the output files from a previous build.
Thus, just delete the folder hunspell in folder /main manually and it 
should be working again.


Best regards, Oliver.

Re: Ambiguous paths for module hunspell

[Ian C]

On Sat, Oct 27, 2012 at 5:49 PM, Oliver-Rainer Wittmann
 wrote:
> Hi,
>
> Am 27.10.12 08:03, schrieb Ian C:
>
>> Hi,
>>
>> I saw a post back in Aug 4 where Pedro had
>>
>> build -- version: 275224
>> Ambiguous paths for module hunspell:
>>
>> I just updated my svn and get the same thing.
>>
>> Anyone have a solution?
>>
>
> Yes :-)
>
> the folder/module hunspell is moved from folder /main to /ext_libraries. The
> folder hunspell in folder /main is not deleted by an svn update, if it
> contains the output files from a previous build.
> Thus, just delete the folder hunspell in folder /main manually and it should
> be working again.

Excellent, thanks.
That has gone, but now it seems to be looking for rtlbootstrap.mk

make:  makefile.mk:  line 29:  Error: -- Include file
/ooo/main/solver/350/unxlngx6.pro/inc/rtlbootstrap.mk, not found
ERROR: error 65280 occurred while making
/ooo/main/instsetoo_native/inc_openoffice/unix

I just ran configure, bootstrap, sourced the sh file, changed to
instsetoo_native/
and ran build (no arguments seems to give more output)

Last time I ran build I added -all -P4 -- P4 to get some parallel
processing and threading.

This is a Fedora build by the way.

>
> Best regards, Oliver.



-- 
Cheers,

Ian C

Re: [PROPOSAL] Initiate a Contest for Branding of 4.0

[Andrea Pescetti]

On 26/10/2012 Ian Lynch wrote:

I arranged one for the OOo schools mascot ... The winner was
clear-cut. A 16 year old Italian boy who aspired to be a graphic designer.


Here he is (by chance, he's called Andrea too):
http://www.openoffice.org/editorial/interview_andrea_maggioni.html (EN)
http://www.openoffice.org/it/stampa/comunicati/avv12.html (IT)
A quick web search shows that in the end he managed to become a graphic 
designer indeed!


The mascot is at the end of
http://www.openoffice.org/marketing/education/schools/
but it didn't have that much recognition in the end.

Indeed, as Ian pointed out, the main value of that competition was in 
getting media exposure; while in this (OpenOffice 4.0 visual identity) 
competition we will probably want both media exposure and a professional 
outcome, so a clear RFP (Request for proposal) as Graham proposes will 
help and it is an excellent first step.


Regards,
  Andrea.

Re: Apache and ODF

[Inge Wallin]

On Thursday, October 25, 2012 21:14:19 Rob Weir wrote:
> On Thu, Oct 25, 2012 at 2:24 PM, Andreas Säger  wrote:
> > Hi,
> > 
> > Today my wife got her new Kindle which comes with a document viewer
> > based on Apache Freetype for the rendering job and Apache POI which is a
> > Java library to parse Microsoft documents.
> > It handles doc(x)/xls(x)/ppt(x) but no ODF. Although I am not deeply
> > involved in this project, I feel somewhat embarrassed and alarmed
> > because in the year 2012 the Apache foundation develops excellent tools
> > to process proprietary file formats but fails to offer anything
> > equivalent for the free and much simpler ODF standard.
> > Is my assumption correct that http://incubator.apache.org/odftoolkit/
> > would be the remedy to solve that problem but due to a lack of
> > development resources it is not ready for the job?
> 
> The ODF Toolkit is a Java library for manipulating ODF documents.  A
> classic use would be document automation, e.g., taking a document
> template and filling in data from a database, to create a new ODF
> document.  It does this all without any GUI, no OpenOffice required.
> It is not an editor, not a viewer.  It has no rendering, layout or
> calculation logic.  It operates directly on the document file.
> 
> So ordinarily I'd say that this was not appropriate for a document
> viewer, certainly not without a layout engine.  But on something like
> the Kindle, with relatively simple layout requirements, the ODF
> Toolkit would be analogous to POI, and would make the task far easier.
> 
> If you search for it, you will find various solutions for converting
> ODF to EPub.  But I have not seen something that does the same for
> Kindle's MOBI format.
> 
> -Rob
> 
> > Greetings,
> > Andreas Säger

Calligra Author and Calligra Words 2.6 that will be released as beta in next 
week has both a new Epub2 and a MOBI export. This is done because of the new 
Calligra Author application that is aimed especially at creating ebooks.

Upcoming versions will also have Epub3 support with dynamic contents.

Re: extensions and translations.

[Ariel Constenla-Haile]

On Sat, Oct 27, 2012 at 10:27:34AM +0200, jan iversen wrote:
> I agree with you, we should NOT put a new framework on extensions writer.
> 
> I was thinking along the lines of
> 
> make a new directory ./extras/extensions/source, with files  name>.

This will force the extension developer to release that file under the
ALv2, because only ALv2 code can be committed.


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpkFslOjxwNG.pgp
Description: PGP signature

Re: Ambiguous paths for module hunspell

[Ariel Constenla-Haile]

On Sat, Oct 27, 2012 at 06:16:08PM +0800, Ian C wrote:
> I just ran configure, bootstrap, sourced the sh file, changed to
> instsetoo_native/
> and ran build (no arguments seems to give more output)
> 
> Last time I ran build I added -all -P4 -- P4 to get some parallel
> processing and threading.

you should run build --all in instsetoo_native/
or build --from the module that broke.
See
http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO#Building_2

Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpCuDRFyZPcm.pgp
Description: PGP signature

Re: Ambiguous paths for module hunspell

[Ian C]

On Sat, Oct 27, 2012 at 8:56 PM, Ariel Constenla-Haile
 wrote:
> On Sat, Oct 27, 2012 at 06:16:08PM +0800, Ian C wrote:
>> I just ran configure, bootstrap, sourced the sh file, changed to
>> instsetoo_native/
>> and ran build (no arguments seems to give more output)
>>
>> Last time I ran build I added -all -P4 -- P4 to get some parallel
>> processing and threading.
>
> you should run build --all in instsetoo_native/
> or build --from the module that broke.
> See
> http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO#Building_2
>

Thanks, it seems to be working now. My bad I missed a - and entered
build -all which produced the errors
Ah, well, we live and learn...

Thanks for your time.

> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina



-- 
Cheers,

Ian C

Re: [DISCUSS] Cleanup installation files, make them more modular

[RGB ES]

2012/10/27 Joost Andrae 

> Hi Marcus,
>
> Am 26.10.2012 23:06, schrieb Marcus (OOo):
>
>  I've modified the subject as I think this topic deserves its own, new
>> thread.
>>
>>
> that is a good idea.
>
>
>  Am 10/26/2012 07:28 PM, schrieb Ariel Constenla-Haile:
>>
>>> On Wed, Oct 24, 2012 at 05:27:41PM +0200, Jürgen Schmidt wrote:
>>>
>>> Once thing to pay attention for the next release is the increasing size:
>>> more than 14 Gb for Linux packages only. This is going to be even more,
>>> as more languages are added. INFRA has already complained after the
>>> first release (can't find the message right now) about the size of our
>>> dist/ folder, so we must think about a solution, before they complain
>>> once the next release is uploaded.
>>>
>>
>> IMHO you can think and try whatever you want. At the end there is only
>> one solution:
>>
>> Cleanup the packaging, delete redundat files, rearrange how the install
>> files will be packed, think new how the installation on the users-side
>> could be done.
>>
>>
> I have some items to add:
>
> - The installer packages should be modulized to allow the selection of
> parts (already done but we shouldn't forget to work on this)
> - Localizations should be separated from the binaries (soffice.bin, libs,
> resfiles). Maybe it's a good idea to separate language packs from the
> installer and that localizations are not part of the base installation
> package (this can solve parts of the INFRA issues)
> - The installer structure should allow small updatable packages (we
> already had this for MSI, MSP files). We should think about designing a
> more heterogenous approach for introducing a patch based update process.
> - Documentation might be divided into parts that link to the soffice
> instance (via HelpIDs) and into parts that allow intermediate updates
> without interfering with the application logic. This would allow a
> continous development process for those who like to work on documentation
> items.
>
> Just my 2 Euro Cents...
>
> Joost
>


Last week there was an user on the ES forums with a particular problem: he
was trying to install AOO in a school on a really old machine without
network connection (no internet, no internal net, nothing) that runs Linux
and needed to donwload (and burn into a CD) the right AOO version on a
Windows machine. How such theoretical installer will manage those
situations? Yes, this particular user is a "corner case" but it is quite
easy to think about *many* corner cases... for example:

- Such installer should be multi platform, something like a java based app,
BUT can we presume that all systems have a java virtual machine working?
While this is usually true on Linux, it is not so true on Windows or Mac.

- How such installer will integrate with package managers on Linux? This is
a problem not only with rpm and deb, the currently supported packages, but
also with sabayon's entropy, with pardus' PiSi system...

- ...

While a new packaging system is an interesting idea, we need to be *really*
careful to not left many users outside it.

Regards
Ricardo

Re: extensions and translations.

[jan iversen]

Got it, as Marcus explained, this is  not a path to follow, but now I can
write in my document that is has been discussed.

jan

On 27 October 2012 14:47, Ariel Constenla-Haile  wrote:

> On Sat, Oct 27, 2012 at 10:27:34AM +0200, jan iversen wrote:
> > I agree with you, we should NOT put a new framework on extensions writer.
> >
> > I was thinking along the lines of
> >
> > make a new directory ./extras/extensions/source, with files  > name>.
>
> This will force the extension developer to release that file under the
> ALv2, because only ALv2 code can be committed.
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>

Re: [DISCUSS] Cleanup installation files, make them more modular

[Joost Andrae]

Hi,




I have some items to add:

- The installer packages should be modulized to allow the selection of
parts (already done but we shouldn't forget to work on this)
- Localizations should be separated from the binaries (soffice.bin, libs,
resfiles). Maybe it's a good idea to separate language packs from the
installer and that localizations are not part of the base installation
package (this can solve parts of the INFRA issues)
- The installer structure should allow small updatable packages (we
already had this for MSI, MSP files). We should think about designing a
more heterogenous approach for introducing a patch based update process.
- Documentation might be divided into parts that link to the soffice
instance (via HelpIDs) and into parts that allow intermediate updates
without interfering with the application logic. This would allow a
continous development process for those who like to work on documentation
items.

Just my 2 Euro Cents...

Joost




Last week there was an user on the ES forums with a particular problem: he
was trying to install AOO in a school on a really old machine without
network connection (no internet, no internal net, nothing) that runs Linux
and needed to donwload (and burn into a CD) the right AOO version on a
Windows machine. How such theoretical installer will manage those
situations? Yes, this particular user is a "corner case" but it is quite
easy to think about *many* corner cases... for example:

- Such installer should be multi platform, something like a java based app,
BUT can we presume that all systems have a java virtual machine working?
While this is usually true on Linux, it is not so true on Windows or Mac.

- How such installer will integrate with package managers on Linux? This is
a problem not only with rpm and deb, the currently supported packages, but
also with sabayon's entropy, with pardus' PiSi system...



yes, the Linux package management is a nightmare and the only way to 
work-around this is to provide packages that don't make use of it...
Joking aside, using system packages is needed to be available for 
distribution applications that manage the rollout within a network (LAN, 
WAN). And I belive there is already some kind of patch management on 
Linux, Solaris, FreeBSD and on MacOS available that is comparable to the 
MSP approach on Windows based systems. Unfortunately on Linux we have 
several packaging systems (.deb, rpm, etc.) that we need to take care 
of. On Linux there's another thing that needs attention that's the 
desktop system integration which differs from distribution to 
distribution and it's really a nightmare because some distros provide 
diverse frameworks like Gnome, KDE, etc. that need their own 
integration. This could be one thing that could be out-sourced into 
extra packages that a Linux user can download for his/her distribution 
additionally to the base installation package.


Kind regards, Joost

Re: [RELEASE] Releasing new languages for 3.4.1

[Andrea Pescetti]

On 26/10/2012 jan iversen wrote:

On 26 October 2012 19:43, Andrea Pescetti wrote:

- Releasing a new language is totally risk-free: a new language can't
break functionality in OpenOffice, while any feature could have bugs and
needs more qualified testing.

I do not agree to that statement for two reasons
- a bad translations will influence the reputation of AOO in that language
zone.
- Wrong translation of e.g. accelerators, might not break the product
technically speaking, but for sure the end-user will experience it as
non-functioning.


We can do worse as Marcus remembered (and actually we once managed to 
completely break styles in an Italian release candidate by translating 
"Header" and "Heading" with the same Italian word), but that was not my 
point. I meant that any damage a translation can do is self-contained: 
adding a translation will not pose any risk to the English (or other) 
version of OpenOffice (in other words: I can update the Danish language 
resources, rebuild and be sure that this does not introduce bugs in the 
English version).


As for testing translations, this goes without saying: for sure we want 
to distribute only languages that have been tested. We used to have 
acceptance tests that every N-L team would run on the localized build to 
give green light for its distribution. The release voting is now 
different, but I would still expect that we test every language at least 
at a very basic level.



release cycle of quarterly releases (every 3 or 4 months)?

This could be a solution too. In this case we would have the problem of
choosing what to translate

- I think it would be nice to give translators an early start possibility,
giving them a choice of working late after freeze or taking parts now with
the risk that new messages are added.


OK, from this and other comments it seems that the cleanest solution 
would be to establish a translation deadline (say, near the end of 
November, but this is purely hypothetical), incorporate all available 
translations and make a build available a few days later, give one week 
(or whatever appropriate) for feedback, then release a 3.4.2 with the 
standard process upon positive feedback. This would avoid "creative" 
solutions like publishing patched sources or working around the Apache 
release process. The 3.4.2 would of course be released from the AOO34 
branch, with the new language resources and maybe a few cherry-picked 
bugfixes.


Regards,
  Andrea.

Re: The Impossible Question

[Kay Schenk]

On Fri, Oct 26, 2012 at 4:57 PM, Dave Fisher  wrote:

>
> On Oct 26, 2012, at 2:06 PM, Louis Suárez-Potts wrote:
>
> > Hi
> > Every now and then a user finds the experience of downloading,
> installing, using AOO disappointing and frankly frustrating if not worse.
> They will usually go to the user forums, but sometimes they will contact
> the Apache Foundation directly. Okay, but this does not really help them.
> >
> > What we did with OpenOffice was set up a Support page, which has since
> been moved to here, http://www.openoffice.org/support/. It's pretty much
> an improved version of the old but of course the "ecosystem" needs further
> fleshing out—it suffers from a lack of substantial existence.
> >
> > I'm also not persuaded that the route to it from either the application
> download page or homepage or wherever is redundantly clear enough for the
> befuddled enduser who installs AOO to replace his or her whatever suite and
> doesn't really know where to go…..
> >
> > So, my query is the usual impossible question: What can we do to make it
> clearer to the puzzled and frustrated how to get help? Sure, we can have a
> knowledge base (kb), FAQ, etc., and also enthusiastic community members.
> >
> > But what would you suggest as a path, or paths for the user? I
> personally would include something in the installation sets that point to
> the support page above; but also banners, say, or tags, stickers—glaringly
> obvious neon coloured blinking lights?—to relay users to useful pages.
> >
> > Ideas?
>
> We could emulate a version of what the ASF does to highlight the many
> projects. Take a look at www.apache.org - you will see a feature project
> section.
>
> Perhaps on www.openoffice.org we can add a "Featured Support Question /
> Language / News". This would be backed by an xml file of FAQs, Languages
> and News which would randomly be selected every day and republished to the
> front page.
>


hmmm...an interesting idea. This would be easier to implement if our
"items" were in a DB of some sort. Otherwise I'm clueless has to how we
could realistically do this.


>
> Regards,
> Dave
>

Yeah, I got to thinking more after I posted this yesterday.

For starters, maybe we should put together a "Support FAQ" or "Problem
Shortlist" and link that prominently on the "support" page. This would take
some time to cull through issues, but I think we already have a pretty good
idea about what some of these are. I'm thinking of a rather short list here
-- like maybe 10 - 20 items.

Also, what about the "Support" page. Is the order of items OK. If not, what
should they be?

>
> >
> > Thanks
> > Louis
> >
>
>


-- 

MzK

"Anyone who considers protocol unimportant has never
 dealt  with a cat."
-- Robert Heinlein

Re: The Impossible Question

[Louis Suárez-Potts]

On 12-10-27, at 13:05 , Kay Schenk  wrote:

> Also, what about the "Support" page. Is the order of items OK. If not, what
> should they be?

The order there is totally up for grabs and there is no reason in that page's 
case to abide by precedent (just the expectation that others probably have of 
how things ought to be laid out—but even here, that is a little up in the air, 
if not cloud).

It was cobbled together by several, and the work they did was superb—thanks! 
But expectations have changed and so have what can or ought to be listed there.

Originally, the page was conceived using the old CollabNet static pages. That 
was a while ago, and in that while, we've come to use the New Millennium's 
technology.


-louis

Re: The Impossible Question

[Rob Weir]

On Sat, Oct 27, 2012 at 2:08 PM, Louis Suárez-Potts  wrote:
>
> On 12-10-27, at 13:05 , Kay Schenk  wrote:
>
>> Also, what about the "Support" page. Is the order of items OK. If not, what
>> should they be?
>
> The order there is totally up for grabs and there is no reason in that page's 
> case to abide by precedent (just the expectation that others probably have of 
> how things ought to be laid out—but even here, that is a little up in the 
> air, if not cloud).
>
> It was cobbled together by several, and the work they did was superb—thanks! 
> But expectations have changed and so have what can or ought to be listed 
> there.
>

Louis, it sounds like you are almost saying something, but not quite.
Could you be more specific, or give an example?

Thanks!

-Rob


> Originally, the page was conceived using the old CollabNet static pages. That 
> was a while ago, and in that while, we've come to use the New Millennium's 
> technology.
>
>
> -louis

Re: The Impossible Question

[Rob Weir]

On Fri, Oct 26, 2012 at 7:57 PM, Dave Fisher  wrote:
>
> On Oct 26, 2012, at 2:06 PM, Louis Suárez-Potts wrote:
>
>> Hi
>> Every now and then a user finds the experience of downloading, installing, 
>> using AOO disappointing and frankly frustrating if not worse. They will 
>> usually go to the user forums, but sometimes they will contact the Apache 
>> Foundation directly. Okay, but this does not really help them.
>>
>> What we did with OpenOffice was set up a Support page, which has since been 
>> moved to here, http://www.openoffice.org/support/. It's pretty much an 
>> improved version of the old but of course the "ecosystem" needs further 
>> fleshing out—it suffers from a lack of substantial existence.
>>
>> I'm also not persuaded that the route to it from either the application 
>> download page or homepage or wherever is redundantly clear enough for the 
>> befuddled enduser who installs AOO to replace his or her whatever suite and 
>> doesn't really know where to go…..
>>
>> So, my query is the usual impossible question: What can we do to make it 
>> clearer to the puzzled and frustrated how to get help? Sure, we can have a 
>> knowledge base (kb), FAQ, etc., and also enthusiastic community members.
>>
>> But what would you suggest as a path, or paths for the user? I personally 
>> would include something in the installation sets that point to the support 
>> page above; but also banners, say, or tags, stickers—glaringly obvious neon 
>> coloured blinking lights?—to relay users to useful pages.
>>
>> Ideas?
>
> We could emulate a version of what the ASF does to highlight the many 
> projects. Take a look at www.apache.org - you will see a feature project 
> section.
>
> Perhaps on www.openoffice.org we can add a "Featured Support Question / 
> Language / News". This would be backed by an xml file of FAQs, Languages and 
> News which would randomly be selected every day and republished to the front 
> page.
>

I like the idea in general, but from a support perspective I think we
need to get the feed down to the client.  Why?  Because users have no
current reason to visit www.openoffice.org homepage on a regular
basis.  It is not really a necessary place for them to visit, once
they've downloaded.

Most users just want to get their work done.  They don't have any
emotional attachment to AOO.  It is just a tool.  If they are thinking
about their tools rather then their work, then something is probably
wrong.  This is not sexy, Apple-like technology that users go gooey
over.   It is a good day that a user thinks about their document, but
not about their word processor.  The task is in the forefront, the
tool recedes into the background, like any good tool an extension of
the user.

Well, that's one ideal, at least.

So in terms of priorities, we should want:

1) Fewer bugs, not more bug FAQ's

2) Less need for support, not a more prominent support page

3) More quick avenues for self-help rather than hard-to-scale support offerings

4) More skill-building pages, ways user can become more productive
with the tools.  We could make a destination that users would actually
visit if we could pull together solid content on "power tips",
extensions reviews, lists of topical templates (for holidays, tax
time, etc.).

-Rob


> Regards,
> Dave
>
>>
>> Thanks
>> Louis
>>
>

Re: the presentation program keeps losing my pages

[Andrea Pescetti]

Grant McPeetie wrote:

I have used the impress program to produce two presentations for my
work as a teacher.  The first time, it ate fifteen pages.  I loaded
it on a more powerful machine and I can’t account for three missing
pages.  I save my work all the time, even though it autosaves, and I
deleted only one page myself.  The thumbnails show the wrong
pictures.  If you drag and drop a page that’s out of order, sometimes
it just vanishes. ... I have used open office
forever and I’ve never needed to contact you prior to these problems.


Hi, this is a very uncommon report: but indeed OpenOffice Impress has a 
new slide management functionality; if you installed an old beta, this 
functionality was still incomplete there and occasionally it would lead 
to instability and crashes, at least on my system. But if you installed 
the official version from http://www.openoffice.org/ then it should be 
robust and stable as usual.


What you might have missed is that in the "Normal" view there is now a 
pop-up interface that allows you to hide a slide (just move the mouse 
over a thumbnail); hidden slides are not deleted, but they won't appear 
if you run your presentation.


Since it was an upgrade, a common advice we give to people who upgrade 
and report problems is to reset their user profile; you just need to 
rename a folder, see 
http://forum.openoffice.org/en/forum/viewtopic.php?t=12426#p58403 for 
more information.


Regards,
  Andrea.

Re: proposal for new l10n workflow

[jan iversen]

Based on the comments I have received, I have updated the document.

The major changes are:

- removed l10n web page tools
- no auto-commit in any tools
- proposed changes to pootle server (based on request from andrea, to
use/change existing tools)
- added more text on the translation workflow, inkl. local teams

The document is available as pdf:
http://wiki.openoffice.org/wiki/File:L10procNew2.pdf
and (due to a polite hint) as a wiki page:
http://wiki.openoffice.org/wiki/Localization_AOO/new_proposal
Furthermore a projectplan is available as a wiki page:
http://wiki.openoffice.org/wiki/Localization_AOO/workPlan

this mail is posted on both ooo-L10n and ooo-dev, but please use ooo-dev
for discussions.

Andrea:
I hope you have time to see if your suggestions are well represented now,
so this document could be used as discussion basis when you meet the pootle
people.


Have a nice evening.
jan I.


On 25 October 2012 23:01, Andrea Pescetti  wrote:

> On 21/10/2012 jan iversen wrote:
>
>> I have finally finished my proposal for a new workflow.
>> please have a look at:
>> http://wiki.openoffice.org/**wiki/File:L10procNew.pdf
>>
>
> It seems I'm the first one who replies after having read your document in
> full. And the quality of your proposal is not the issue here: on the
> contrary, it is a very good one and I'm answering in detail below. So the
> issue must be somewhere else. I'm confident you will understand that I'm
> not criticizing or lecturing you here, and I'm not implying any of the
> items below to be you fault (none is); but maybe this will help you in
> getting better feedback in future.
>
> 1) Unfortunate timing. We've just graduated, the Apache Conference is
> coming in about one week, we need to relocate all infrastructure... It's a
> busy period, so we may be less responsive than usual.
>
> 2) Excess of communication. If all people on this list had written as much
> as you did in the last 24 hours to the OpenOffice lists, ooo-dev would have
> received a message every 9 seconds! If you make yourself manageable it will
> be easier for us to answer your requests with less confusion.
>
> 3) Dispersion of communication. Discussion about your proposal is
> scattered in three different threads across ooo-dev and ooo-l10n (not
> counting private e-mails); if you need to send a message to multiple lists,
> and this is a good example, it's best to send one message to two lists (and
> specify which one should receive answers) since answers will be grouped in
> the same discussion for people who are reading e-mail by discussions.
>
> 4) Proposal format. Uploading a PDF is very convenient but it does not
> make others feel empowered to really contribute. I would have applied a
> dozen typo fixes to your proposal if it had been available as a wiki page.
> Others might have done the same.
>
> OK, enough said. The proposal has significant merit, so let's focus on
> that for the rest of this message. It won't be short: it's still a 20-page
> document.
>
> The main reasons to drive it forward are:
> - It puts us back in total control of the l10n process, with no need to
> rely on partially broken or lost tools.
> - It reduces the number of steps strings must go through for being
> translated and imported back.
> - It automates a number of operations that have been manual so far.
> - It allows to have a proper version control for translations.
>
> In general, I think the document would benefit from some knowledge about
> how the process works with established teams:
> - There is a "string freeze" date in the release schedule (this concept
> needn't be taken away: for sure we still want a string freeze even if tools
> allow a continuous localization; translators shouldn't have the surprise to
> see new strings appear in the last weeks before a release)
> - After string freeze, strings are made available in Pootle (and this
> happens automatically in your proposal)
> - Volunteers pick a file, usually a help file and the main application
> related to it (so, the "sw" module for Writer and its help file; and,
> answering another message from you, the subdivision you propose would be
> OK). Here indeed it is helpful to know that a file has been taken,
> something that volunteers track manually at the moment. Volunteers do not
> have time constraints and may well take two weeks to complete their
> assignments: the "4 days" you propose are not realistic for most teams.
> - Nobody works on Pootle. This has nothing to do with rights, it is
> totally incorrect to see Pootle as the "committers tool". The Pootle server
> used to be slow and not responsive and anyway, as a matter of fact, most
> people, including me, prefer to work with downloaded files.
> - Volunteers mark all strings they touched as "fuzzy" to distinguish them;
> if I understand correctly, a XLIFF based workflow here would suggest to
> mark the strings as "to be reviewed".
> - Other volunteers (in gen

Re: The Impossible Question

[Kay Schenk]

On Sat, Oct 27, 2012 at 11:57 AM, Rob Weir  wrote:

> On Fri, Oct 26, 2012 at 7:57 PM, Dave Fisher 
> wrote:
> >
> > On Oct 26, 2012, at 2:06 PM, Louis Suárez-Potts wrote:
> >
> >> Hi
> >> Every now and then a user finds the experience of downloading,
> installing, using AOO disappointing and frankly frustrating if not worse.
> They will usually go to the user forums, but sometimes they will contact
> the Apache Foundation directly. Okay, but this does not really help them.
> >>
> >> What we did with OpenOffice was set up a Support page, which has since
> been moved to here, http://www.openoffice.org/support/. It's pretty much
> an improved version of the old but of course the "ecosystem" needs further
> fleshing out—it suffers from a lack of substantial existence.
> >>
> >> I'm also not persuaded that the route to it from either the application
> download page or homepage or wherever is redundantly clear enough for the
> befuddled enduser who installs AOO to replace his or her whatever suite and
> doesn't really know where to go…..
> >>
> >> So, my query is the usual impossible question: What can we do to make
> it clearer to the puzzled and frustrated how to get help? Sure, we can have
> a knowledge base (kb), FAQ, etc., and also enthusiastic community members.
> >>
> >> But what would you suggest as a path, or paths for the user? I
> personally would include something in the installation sets that point to
> the support page above; but also banners, say, or tags, stickers—glaringly
> obvious neon coloured blinking lights?—to relay users to useful pages.
> >>
> >> Ideas?
> >
> > We could emulate a version of what the ASF does to highlight the many
> projects. Take a look at www.apache.org - you will see a feature project
> section.
> >
> > Perhaps on www.openoffice.org we can add a "Featured Support Question /
> Language / News". This would be backed by an xml file of FAQs, Languages
> and News which would randomly be selected every day and republished to the
> front page.
> >
>
> I like the idea in general, but from a support perspective I think we
> need to get the feed down to the client.  Why?  Because users have no
> current reason to visit www.openoffice.org homepage on a regular
> basis.  It is not really a necessary place for them to visit, once
> they've downloaded.
>
> Most users just want to get their work done.  They don't have any
> emotional attachment to AOO.  It is just a tool.  If they are thinking
> about their tools rather then their work, then something is probably
> wrong.  This is not sexy, Apple-like technology that users go gooey
> over.   It is a good day that a user thinks about their document, but
> not about their word processor.  The task is in the forefront, the
> tool recedes into the background, like any good tool an extension of
> the user.
>
> Well, that's one ideal, at least.
>
> So in terms of priorities, we should want:
>
> 1) Fewer bugs, not more bug FAQ's
>
> 2) Less need for support, not a more prominent support page
>

Well this is the ideal of course.   In some cases though, what a user
already has running on their system may be a major culprit and something we
can't control or deal with easily (yep! I spent a number of years in User
Support as well).


> 3) More quick avenues for self-help rather than hard-to-scale support
> offerings
>
> 4) More skill-building pages, ways user can become more productive
> with the tools.  We could make a destination that users would actually
> visit if we could pull together solid content on "power tips",
> extensions reviews, lists of topical templates (for holidays, tax
> time, etc.).
>
> -Rob
>

I don't know ANYTHING about how the Help (the Support menu item) pages for
AOO are constructed (maybe time I learned?).  There's already a LOT of
information under "Common Help Topics". But, maybe we need to spend some
time revisiting this area and see if the topics still meet current needs
(in the product itself). Some of the issues that have been reported
recently are very odd but maybe there's a reason.  This would be the most
direct route for the end user I assume.


>
> > Regards,
> > Dave
> >
> >>
> >> Thanks
> >> Louis
> >>
> >
>



-- 

MzK

"Anyone who considers protocol unimportant has never
 dealt  with a cat."
-- Robert Heinlein

Re: [PROPOSAL] "difficulty" field for Bugzilla

[Kay Schenk]

On Fri, Oct 26, 2012 at 3:09 PM, Rob Weir  wrote:

> On Fri, Oct 26, 2012 at 5:28 PM, Kay Schenk  wrote:
> > On 10/26/2012 07:26 AM, Rob Weir wrote:
> >> On Fri, Oct 26, 2012 at 3:47 AM, Andre Fischer 
> wrote:
> >>> On 24.10.2012 22:28, Dennis E. Hamilton wrote:
> 
>  @Regina,
> 
> Yes, Wizard is a reference to the level of mastery that a solver
> must
>  possess, and is one of those "which one of these words does not
> belong"
>  solutions.
> 
>  There is a well-known *logarithmic* difficulty scale that has been
> used
>  over 40 years for problem difficulty.  It might be worth adapting:
> 
> (after unknown),
> 
>  00 easy - immediately solvable by someone willing to do it
>  10 simple - takes minutes
>  20 medium, average - quarter hour
>  30 moderate, an evening
>  40 difficult, challenging, non-trivial (term project, GSoC...)
>  50 unsolved, deep, requires a breakthrough, research
> (PhD dissertation)
>  60 intractable (that I just made up - probably not something that
> is technically feasible regardless of skill, Nobel Prize,
> P = NP, etc.)
> >>>
> >>>
> >>> Is this not similar to what Knuth used (uses) in his "Art of Computer
> >>> Programming" series?
> >>>
> >>
> >> It reminds me of Knuth as well.
> >>
> >> In any case, I've added the new field, using the above scale, but
> >> changing "unsolved" to "research", since all open bugs are unsolved in
> >> some sense.
> >>
> >> -Rob
> >
> > Rob, Will you be updating the information/instructions on:
> >
> > http://wiki.openoffice.org/wiki/QA/HowToFileIssue
> >
> > with this new field?
> >
>
> I don't think the average bug reporter has any idea whether something
> is an easy fix or not.  Only a developer would know this.  And
> developers don't read pages with names like 'How to file a good Issue"
> ;-)
>
> But I will document as part of the new volunteer orientation stuff I'm
> writing up.  There are a number of pieces that I need to connect
> together -- the new volunteers directory, the new orientation modules,
> the BZ difficulty field, etc.  Hopefully I can get this ready to
> launch soon.
>

OK, I know what you're saying...the thing is this will be a field the
reporter can access, correct? They *may* put something in or wonder what
they should use.  I just think for completeness it should be included.

and thanks for all of this...


> -Rob
>
> >
> >>
> >>> -Andre
> >>>
> >
> > --
> > 
> > MzK
> >
> > "Anyone who considers protocol unimportant has never
> >   dealt with a cat."
> > -- Robert Heinlein
>



-- 

MzK

"Anyone who considers protocol unimportant has never
 dealt  with a cat."
-- Robert Heinlein

Re: volunteering

[Kay Schenk]

On 10/27/2012 02:00 PM, Prabha Chidambaran wrote:

Hello Apache: My name is Prabha Chidambaran and I live in New Jersey.
I am an aspiring technical writer and would love to get involved in
writing documentation and help guides for your website. I have a
Master's degree from Rutgers University and I have some background in
journalism. I am very comfortable with MS Office and familiar with MS
Access. I'd be thrilled if I could help you all in the writing parts.

Thank you so much,
Prabha



Hello Prabha --

We can certainly use your skills as a technical writer in the project.

There are basically two forms of documentation that we maintain/support 
-- volunteer material on the Documentation area of the wiki, and an 
ongoing effort for more formal User Guides, currently carried on by the 
ODFAuthors group.


More information on these approaches and how you can get started is 
available on the Documentation area of the wiki (see especially the "How 
to Contriubte" link to the right side of the following page):


http://wiki.openoffice.org/wiki/Documentation

Thank you for contacting Apache OpenOffice.

--

MzK

"Anyone who considers protocol unimportant has never
 dealt with a cat."
   -- Robert Heinlein