Re: [RELEASE]: new snapshot base don revision r1400866

[Oliver-Rainer Wittmann]

Hi

On 26.10.2012 08:49, Andrea Pescetti wrote:

On 26/10/2012 Larry Gusaas wrote:

The requested URL
/~jsc/developer-snapshots/r1400866/macos/languagepacks/Apache_OpenOffice-Dev_AOO350m1_MacOS_x86_langpack_en-US.dmg

was not found on this server.


This is the list of remaining broken links (excluding checksums) at
https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds
 :

http://people.apache.org/~jsc/developer-snapshots/r1400866/windows/Apache_OpenOffice-Dev_AOO350m1_Win_x86_install_sk.exe


Seems to be missing.



http://people.apache.org/~jsc/developer-snapshots/r1400866/windows/languagepacks/Apache_OpenOffice-Dev_AOO350m1_Win_x86_langpack_en-US.exe


Seems to be missing.


http://people.apache.org/~jsc/developer-snapshots/r1400866/macos/languagepacks/Apache_OpenOffice-Dev_AOO350m1_MacOS_x86_langpack_en-US.dmg


Seems to be missing


http://people.apache.org/~jsc/developer-snapshots/r1400866/windows/Apache_OpenOffice-SDK_3.5.0_Win_x86_install_en-US.exe


Corrected link.



http://people.apache.org/~jsc/developer-snapshots/r1400866/macos/Apache_OpenOffice-SDK_3.5.0_MacOS_x86_install_en-US.dmg


Corrected link.

Best regards, Oliver.




Also note that
http://people.apache.org/~jsc/developer-snapshots/r1400866/windows/
seems to contain Polish (pl) builds too, but they are not listed. Example:
http://people.apache.org/~jsc/developer-snapshots/r1400866/windows/Apache_OpenOffice-Dev_AOO350m1_Win_x86_install_pl.exe


Regards,
   Andrea.

[RELEASE] Releasing new languages for 3.4.1

[Andrea Pescetti]

It is now clear that, thanks to new volunteers now coordinating on 
ooo-l10n, we will soon be in a position to add 3-5 new languages to 
Apache OpenOffice.


It is also clear that at the moment we have no demand for a 3.4.2 with 
critical bugfixes because... well, 3.4.1 does not have critical bugs. 
And releasing 3.4.2 only to add new languages seems definitely overkill: 
80% of the work would be wasted, we would need a new vote and so on.


So, what's the best way to get those new languages released?

Would a checkout of the 3.4.1 tag, where we replace the language files 
for those 3-5 languages and then build, work as an interim solution? I 
honestly don't like it very much (it's of course better than committing 
to a tag, but still not clean), but it would probably allow to skip the 
release process and voting, since we would merely be adding 3-5 binary 
artifacts (built for different platforms).


Any better solutions? Wait for the moment when a 3.4.2 is needed? 
Picking some bugfixes and forcing a 3.4.2 soon?


Regards,
  Andrea.

Re: [QA BUG] - some regression defects were found by GUI perfromance test

[Linyi Li]

Hi Jianfang,

Thanks for your clarification.
I will retest it when the build is ready:)

On Thu, Oct 25, 2012 at 10:20 PM, zhangjf  wrote:

> Hi,
>
> For bug 121199, it has the same root cause as bug 121134, so I just
> duplicated it with bug 121134. And Jinlong still doesn't have the
> commit right yet, so he only put the fix patch into bug 121134. I have
> just delivered this piece of fix code by revision 1402153. Hopefully
> there will be a build for test tomorrow.
>
> Thank you again for the great bug finding.
>
> zhangjf
>
> On Thu, Oct 25, 2012 at 1:53 PM, Linyi Li  wrote:
> > Hi Herbert,
> >
> > I checked defect[2] on r1401602, it still has this problem. Could you
> tell
> > me which build you tested?
> >
> > About defect[1], I saw there is a response:
> > --- Comment #5 from wujinl...@gmail.com ---
> > This is a known bug, and I have already had a fix for it. Please see bug
> > 121134
> > for details.
> > CC to wujinlong, is this fix already commited to trunk build?
> >
> > Defect[3] is found on ubuntu12.04, 32bit. It is OK on ubuntu12.04 64bit.
> >
> >
> >
> >
> > On Thu, Oct 25, 2012 at 9:41 AM, Linyi Li 
> wrote:
> >
> >> Thanks Herbert.
> >> I will check[1][2] in current build:)
> >>
> >>
> >> On Wed, Oct 24, 2012 at 11:03 PM, Herbert Duerr  wrote:
> >>
> >>> Hi,
> >>>
> >>>
> >>> On 24.10.2012 07:34, Linyi Li wrote:
> >>>
>  I did GUI performance test of AOO trunk build. I found some
>  defects[1][2][3], and two of them are regression ones[1][2].
> 
> >>>
> >>> Great finds and great bug reports, thank you!
> >>>
> >>> And kudos to the wonderful automated testing framework that allows to
> run
> >>> such extensive tests with that thoroughness and frequency.
> >>>
> >>>
> >>>  I think defects[1][2] are severe which will block users‘ normal use of
>  AOO,
>  so is there anyone who can help to fix these defects?
> 
> >>>
> >>> I looked into them and updated their status:
> >>>
> >>>
> >>>  [1]
>  Bug 121199 - [Automation][Regression]**Crashed when loading 2 docx
>  files.
> 
> >>>
> >>> The patch that caused the crashes is known and reverting it solves the
> >>> problem. But probably the patch can be updated to fix both the new and
> the
> >>> original issues. The developers knowing the patch best were CC'ed.
> >>>
> >>>
> >>>  [2]
>  Bug 121200 - [Regression][Automation][**Performance]Severe downgrade
> to
>  save
>  xls sample files.
> 
> >>>
> >>> This seems to be fixed in the current trunk revision.
> >>>
> >>>
> >>>  [3]
>  Bug 121256 - Crash when saving ppt on Linux.
> 
> >>>
> >>> This cannot be reproduced here. If anyone sees the problem please
> attach
> >>> a stack trace in the issue. If possible for a build with sufficient
> debug
> >>> info.
> >>>
> >>> Herbert
> >>>
> >>
> >>
> >>
> >> --
> >> Best wishes.
> >> Linyi Li
> >>
> >>
> >
> >
> > --
> > Best wishes.
> > Linyi Li
>



-- 
Best wishes.
Linyi Li

Re: Apache and ODF

[Fan Zheng]

Hi, All:

I am confused about the UX specifications of document representation
requirement on mobile devices, that which is the most first important point
should be, the different device condition adaptability of layout result? or
the fidelity of the document originally recorded?

For example. An ODT format text document with several pages sized as
"Letter", which is physically defined as 279:216 (ratio as 1.29), and user
want to render it in a Kindle Fire, which supplies a 1024:600 (ratio as
1.71) screen for presenting. If we do much more care about the adaptability
of representation, lots data recorded inside the file will be changed,
removed or even ignored. But, if we care about the fidelity much more, we
have to record all the document data inside, and rendering it on the
devices dutifully. In the case, all we could do for the UX, is to give some
adjustable scale.  Such differences are meaning not only the pagination
stuff, but also some solid data inside: thinking about a full
page-width-size table for instance.

Of cause, all the former document editor/viewer applications for desktop,
will obey the "Keep Fidelity" as the very first rule. But what about the
mobile device platforms?

As such differences will actually lead the solution into the different
direction, we maybe should make it clear before having a deeper discussion.

Thanks.

ZhengFan


2012/10/26 Andreas Säger 

> Am 25.10.2012 21:14, Rob Weir wrote:
> >
> > 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
> >
>
> Thank you. I know about the converters. The problem is that all our
> office documents are ODF documents. The Kindle device does not provide
> any access to our documents until they have been converted by some other
> device.
>
>
>

Re: [PROPOSAL] "difficulty" field for Bugzilla

[Andre Fischer]

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?


-Andre

Re: [RELEASE]: new snapshot base don revision r1400866

[Jürgen Schmidt]

On 10/26/12 9:00 AM, Oliver-Rainer Wittmann wrote:
> Hi
> 
> On 26.10.2012 08:49, Andrea Pescetti wrote:
>> On 26/10/2012 Larry Gusaas wrote:
>>> The requested URL
>>> /~jsc/developer-snapshots/r1400866/macos/languagepacks/Apache_OpenOffice-Dev_AOO350m1_MacOS_x86_langpack_en-US.dmg
>>>
>>>
>>> was not found on this server.
>>
>> This is the list of remaining broken links (excluding checksums) at
>> https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds
>> :
>>
>> http://people.apache.org/~jsc/developer-snapshots/r1400866/windows/Apache_OpenOffice-Dev_AOO350m1_Win_x86_install_sk.exe
>>
> 
> Seems to be missing.
> 
>>
>> http://people.apache.org/~jsc/developer-snapshots/r1400866/windows/languagepacks/Apache_OpenOffice-Dev_AOO350m1_Win_x86_langpack_en-US.exe
>>
> 
> Seems to be missing.
>>
>> http://people.apache.org/~jsc/developer-snapshots/r1400866/macos/languagepacks/Apache_OpenOffice-Dev_AOO350m1_MacOS_x86_langpack_en-US.dmg
>>
> 
> Seems to be missing
>>
>> http://people.apache.org/~jsc/developer-snapshots/r1400866/windows/Apache_OpenOffice-SDK_3.5.0_Win_x86_install_en-US.exe
>>
> 
> Corrected link.
> 
>>
>> http://people.apache.org/~jsc/developer-snapshots/r1400866/macos/Apache_OpenOffice-SDK_3.5.0_MacOS_x86_install_en-US.dmg
>>
> 
> Corrected link.
> 

It seems that I messed up the links, it should be clean now. Let me know
if there are still missing links

Juergen

> Best regards, Oliver.
> 
>>
>>
>> Also note that
>> http://people.apache.org/~jsc/developer-snapshots/r1400866/windows/
>> seems to contain Polish (pl) builds too, but they are not listed.
>> Example:
>> http://people.apache.org/~jsc/developer-snapshots/r1400866/windows/Apache_OpenOffice-Dev_AOO350m1_Win_x86_install_pl.exe
>>
>>
>>
>> Regards,
>>Andrea.

Re: apache2.conf file for openoffice.org server.

[jan iversen]

Thanks I got it working now, having followed the instructions rob gave me,
my biggest concern was not to build something that would not work on the
live site.

have a nice weekend
Jan.

On 25 October 2012 22:50, Kay Schenk  wrote:

>
>
> On 10/25/2012 09:07 AM, jan iversen wrote:
>
>> Hi.
>>
>> I got the "old" l10n, and saw that in SVN it did not use templates, then I
>> went on and checked the root (AOO) and also found no use of templates...I
>> did find it a bit strange but assumed there were good reasons for not
>> using
>> templates, so I went down that road.
>>
>> But taking your advice, I will have another look at the templates (it is
>> never too late to do a good thing).
>>
>> Jan.
>>
>
> Jan, as an FYI...the OO website associates ssi with ".html", i.e. all
> .html.
>
> If you follow the instructions that Rob pointed you too, AND do the python
> setup -- when you run the CMS build scripts, you will see a ".htaccess"
> file dumped in the main content directory "content". This is the
> "definition" of the ssi processing for our site. Additionally, the build
> scripts convert the mdtext of the template files to html on output.
>
> As it turns out, the .htaccess business did NOT work with my Apache
> webserver setup, 2.2., so I just did kind of generic ssi config, and now
> have to delete the generated ".htaccess" each time, but oh well, other than
> that, I'm good.
>
> Bottom line, it is unlikely you will get to "see" the webserver config we
> actually use, but I'm sure you can cobble up something that will work.
>
>
>
>> On 25 October 2012 17:55, Dave Fisher  wrote:
>>
>>
>>> On Oct 25, 2012, at 8:04 AM, jan iversen wrote:
>>>
>>>  Thanks for your as usual very informative instructions.

 I did that, BUT it does not tell me which kind of SSI the apache server

>>> is
>>>
 using, there are two different methods:
 1) using .shtml (which gives a problem with index.shtml)
 2) setting excute bit on pages containing SSI, this requires XBitHack
 set
 in httpd.conf (or apache2.conf on ubuntu).

>>>
>>> I hope you have looked into the ooo-site/trunk/templates directory where
>>> you will see that the SSIs are not shtml. They are  --**--**
> 
> MzK
>
> "Anyone who considers protocol unimportant has never
>  dealt with a cat."
>-- Robert Heinlein
>

Re: Apache and ODF

[Ian Lynch]

On 26 October 2012 08:42, Fan Zheng  wrote:

> Hi, All:
>
> I am confused about the UX specifications of document representation
> requirement on mobile devices, that which is the most first important point
> should be, the different device condition adaptability of layout result? or
> the fidelity of the document originally recorded?
>
> For example. An ODT format text document with several pages sized as
> "Letter", which is physically defined as 279:216 (ratio as 1.29), and user
> want to render it in a Kindle Fire, which supplies a 1024:600 (ratio as
> 1.71) screen for presenting.


Is it possible to have choices? Keep the original page aspect ratio and
scroll (Never used a kindle so not sure if it can scroll but obviously
Android on phones can!) or have a "fit to aspect" where the page is scaled
to the kindle in AOO befor export. If one of the pre-defined page templates
in AOO was the kindle page size it would be possible to reformat the pages
in a document to that size just as you can change from say A4 to US letter.
Probably for complex documents with graphics this would break some parts of
the layout but for the sort of text only novels etc mostly used on these
devices it should work well enough. This assumes you can export to
epub/mobi format in any scale but I'm assuming that will be similar to
export to pdf. Of course the resulting document layout could be checked by
viewing the epub/mobi output. Having an odf viewer for the mobile devices
would be an alternative method and probably less constrained than using
epub formats but it is also more work to do it. OTOH a versatile odf reader
for mobile devices could be very useful in helping establish odf as the
open standard for all types of document.


> If we do much more care about the adaptability
> of representation, lots data recorded inside the file will be changed,
> removed or even ignored. But, if we care about the fidelity much more, we
> have to record all the document data inside, and rendering it on the
> devices dutifully. In the case, all we could do for the UX, is to give some
> adjustable scale.  Such differences are meaning not only the pagination
> stuff, but also some solid data inside: thinking about a full
> page-width-size table for instance.
>

There can be issues with documents that have both portrait and landscape
pages in them on normal computer screens.

>
> Of cause, all the former document editor/viewer applications for desktop,
> will obey the "Keep Fidelity" as the very first rule. But what about the
> mobile device platforms?
>
> As such differences will actually lead the solution into the different
> direction, we maybe should make it clear before having a deeper discussion.
>
> Thanks.
>
> ZhengFan
>
>
> 2012/10/26 Andreas Säger 
>
> > Am 25.10.2012 21:14, Rob Weir wrote:
> > >
> > > 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
> > >
> >
> > Thank you. I know about the converters. The problem is that all our
> > office documents are ODF documents. The Kindle device does not provide
> > any access to our documents until they have been converted by some other
> > device.
> >
> >
> >
>



-- 
Ian

Ofqual Accredited IT Qualifications (The Schools ITQ)

www.theINGOTs.org +44 (0)1827 305940

The Learning Machine Limited, Reg Office, 36 Ashby Road, Tamworth,
Staffordshire, B79 8AQ. Reg No: 05560797, Registered in England and
Wales.

Re: Apache and ODF

[Rory O'Farrell]

On Fri, 26 Oct 2012 09:58:25 +0100
Ian Lynch  wrote:

> On 26 October 2012 08:42, Fan Zheng  wrote:
> 
> > Hi, All:
> >
> > I am confused about the UX specifications of document representation
> > requirement on mobile devices, that which is the most first important point
> > should be, the different device condition adaptability of layout result? or
> > the fidelity of the document originally recorded?
> >
> > For example. An ODT format text document with several pages sized as
> > "Letter", which is physically defined as 279:216 (ratio as 1.29), and user
> > want to render it in a Kindle Fire, which supplies a 1024:600 (ratio as
> > 1.71) screen for presenting.
> 
> 
> Is it possible to have choices? Keep the original page aspect ratio and
> scroll (Never used a kindle so not sure if it can scroll but obviously
> Android on phones can!) or have a "fit to aspect" where the page is scaled
> to the kindle in AOO befor export. If one of the pre-defined page templates
> in AOO was the kindle page size it would be possible to reformat the pages
> in a document to that size just as you can change from say A4 to US letter.
> Probably for complex documents with graphics this would break some parts of
> the layout but for the sort of text only novels etc mostly used on these
> devices it should work well enough. This assumes you can export to
> epub/mobi format in any scale but I'm assuming that will be similar to
> export to pdf. Of course the resulting document layout could be checked by
> viewing the epub/mobi output. Having an odf viewer for the mobile devices
> would be an alternative method and probably less constrained than using
> epub formats but it is also more work to do it. OTOH a versatile odf reader
> for mobile devices could be very useful in helping establish odf as the
> open standard for all types of document.
> 
> 
> > If we do much more care about the adaptability
> > of representation, lots data recorded inside the file will be changed,
> > removed or even ignored. But, if we care about the fidelity much more, we
> > have to record all the document data inside, and rendering it on the
> > devices dutifully. In the case, all we could do for the UX, is to give some
> > adjustable scale.  Such differences are meaning not only the pagination
> > stuff, but also some solid data inside: thinking about a full
> > page-width-size table for instance.
> >
> 
> There can be issues with documents that have both portrait and landscape
> pages in them on normal computer screens.
> 
> >
> > Of cause, all the former document editor/viewer applications for desktop,
> > will obey the "Keep Fidelity" as the very first rule. But what about the
> > mobile device platforms?
> >
> > As such differences will actually lead the solution into the different
> > direction, we maybe should make it clear before having a deeper discussion.
> >
> > Thanks.
> >
> > ZhengFan
> >
> >
> > 2012/10/26 Andreas Säger 
> >
> > > Am 25.10.2012 21:14, Rob Weir wrote:
> > > >
> > > > 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
> > > >
> > >
> > > Thank you. I know about the converters. The problem is that all our
> > > office documents are ODF documents. The Kindle device does not provide
> > > any access to our documents until they have been converted by some other
> > > device.
> > >

In this discussion it is important to specify clearly which Kindle is the 
target device, as the screen ratio and pixel count varies from device to device 
with the newer Kindles.  A stranger coming to this discussion might assume that 
Kindle genericly refers to the normal "reading" Kindle, with an 800h x 600w 
screen, which is the common Kindle in use.




-- 
Rory O'Farrell 

Re: proposal for new l10n workflow

[jan iversen]

Thanks a lot for your long and informative answer, I read it with a
positive attitude and will just make one comment, it is hard to be new
especially with the state of documentation we have. I will in the future
make a lot less noise.

I will work your comments into my proposal, and in general I agree it is
better to extend existing tools than to make new ones.

There is however one misunderstanding (probably due to my formulations)
that I need to correct, the l10n upload/download feature was NOT to
circumvent the system, but to allow contributors to upload files without
having to go through private mail adresses/bugzilla etc.

Thanks for using time on my proposal.
Jan.


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 general one person per language) review the
> translations, collect all files and make them available to developers
> (Bugzilla, personal web space, e-mail...)
>
> So we already have a (kind of) "team coordinator" who reviews the fil

[QA Call For Review]Bug 121279 - [testuno]frame wrap,anchor,position,size,description,hyperlink test uno script

[Du Jing]

Hi all,

I have developed a test script about frame
anchor,wrap,position,description,hyperlink properties,below is patch link,
is there anyone help me to review?

https://issues.apache.org/ooo/show_bug.cgi?id=121279




Thanks~

Re: Apache and ODF

[Fan Zheng]

To Ian:

Yes, I agree with you that there shall be options for:
1. Fitful formatting way, for the READING; and
2. Uniform formatting way, for the REPRESENTATION;

Thus, the solution will lead:
A: The bad thing is that there shall be a series of formatting
specification definitions, for Kindle, Kindle Fire, Kindle Fire II, iPad,
iPad Mini, IPod touch, IPhone BLA BLA BLA
B: The good thing is, such refining job indicating various device
platforms, could be finished inside the AOO existing framework and
formatting process, only with the external works on supplying above
definitions.



To Rory:
In my point, now, we may need not to specify the exact target we are aimed
at. For although the detailed specification of every type of popular
devices we faced are different, the problems need to be clarified and
solved are commonly the same type of issue, is that "Adaptability and
Fidelity, which is bigger". Definitely, it is an UX issue, which should let
KG to be involved in; But, a given solution for the issue should be
workable for all the devices (of cause maybe including annoy duplicated
works, but should sharing the same working path and steps), whatever the
decision will be.

Ah, yes, maybe we let the new comers confused in some degree. So should we
keep on going within a new thread? Or renaming the current one?

Thanks.

ZhengFan.



2012/10/26 Rory O'Farrell 

> On Fri, 26 Oct 2012 09:58:25 +0100
> Ian Lynch  wrote:
>
> > On 26 October 2012 08:42, Fan Zheng  wrote:
> >
> > > Hi, All:
> > >
> > > I am confused about the UX specifications of document representation
> > > requirement on mobile devices, that which is the most first important
> point
> > > should be, the different device condition adaptability of layout
> result? or
> > > the fidelity of the document originally recorded?
> > >
> > > For example. An ODT format text document with several pages sized as
> > > "Letter", which is physically defined as 279:216 (ratio as 1.29), and
> user
> > > want to render it in a Kindle Fire, which supplies a 1024:600 (ratio as
> > > 1.71) screen for presenting.
> >
> >
> > Is it possible to have choices? Keep the original page aspect ratio an
> > scroll (Never used a kindle so not sure if it can scroll but obviously
> > Android on phones can!) or have a "fit to aspect" where the page is
> scaled
> > to the kindle in AOO befor export. If one of the pre-defined page
> templates
> > in AOO was the kindle page size it would be possible to reformat the
> pages
> > in a document to that size just as you can change from say A4 to US
> letter.
> > Probably for complex documents with graphics this would break some parts
> of
> > the layout but for the sort of text only novels etc mostly used on these
> > devices it should work well enough. This assumes you can export to
> > epub/mobi format in any scale but I'm assuming that will be similar to
> > export to pdf. Of course the resulting document layout could be checked
> by
> > viewing the epub/mobi output. Having an odf viewer for the mobile devices
> > would be an alternative method and probably less constrained than using
> > epub formats but it is also more work to do it. OTOH a versatile odf
> reader
> > for mobile devices could be very useful in helping establish odf as the
> > open standard for all types of document.
> >
> >
> > > If we do much more care about the adaptability
> > > of representation, lots data recorded inside the file will be changed,
> > > removed or even ignored. But, if we care about the fidelity much more,
> we
> > > have to record all the document data inside, and rendering it on the
> > > devices dutifully. In the case, all we could do for the UX, is to give
> some
> > > adjustable scale.  Such differences are meaning not only the pagination
> > > stuff, but also some solid data inside: thinking about a full
> > > page-width-size table for instance.
> > >
> >
> > There can be issues with documents that have both portrait and landscape
> > pages in them on normal computer screens.
> >
> > >
> > > Of cause, all the former document editor/viewer applications for
> desktop,
> > > will obey the "Keep Fidelity" as the very first rule. But what about
> the
> > > mobile device platforms?
> > >
> > > As such differences will actually lead the solution into the different
> > > direction, we maybe should make it clear before having a deeper
> discussion.
> > >
> > > Thanks.
> > >
> > > ZhengFan
> > >
> > >
> > > 2012/10/26 Andreas Säger 
> > >
> > > > Am 25.10.2012 21:14, Rob Weir wrote:
> > > > >
> > > > > 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
> > > > >
> > > >
> > > > Thank you. I know about the converters. The problem is that all our
> > > > office documents are ODF documents. The Kindle device does not
> provide
> > > > any access to our documents until they ha

Re: [RELEASE]: new snapshot base don revision r1400866

[Andrea Pescetti]

Jürgen Schmidt wrote:

It seems that I messed up the links, it should be clean now. Let me know
if there are still missing links


Slovak (sk) Windows: listed in
https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds
but missing.

Polish (pl) Windows+Mac: not listed in
https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds
but existing at
http://people.apache.org/~jsc/developer-snapshots/r1400866/windows/Apache_OpenOffice-Dev_AOO350m1_Win_x86_install_pl.exe
and
http://people.apache.org/~jsc/developer-snapshots/r1400866/macos/Apache_OpenOffice-Dev_AOO350m1_MacOS_x86_install_pl.dmg

Regards,
  Andrea.

Re: [RELEASE]: new snapshot base don revision r1400866

[Jürgen Schmidt]

On 10/26/12 1:16 PM, Andrea Pescetti wrote:
> Jürgen Schmidt wrote:
>> It seems that I messed up the links, it should be clean now. Let me know
>> if there are still missing links
> 
> Slovak (sk) Windows: listed in
> https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds
> 

ups, indeed, it seems that I missed to build it on Windows. Will do that...

> but missing.
> 
> Polish (pl) Windows+Mac: not listed in
> https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds
> 
> but existing at
> http://people.apache.org/~jsc/developer-snapshots/r1400866/windows/Apache_OpenOffice-Dev_AOO350m1_Win_x86_install_pl.exe
> 
> and
> http://people.apache.org/~jsc/developer-snapshots/r1400866/macos/Apache_OpenOffice-Dev_AOO350m1_MacOS_x86_install_pl.dmg
> 

Polish is listed now

Juergen

> 
> Regards,
>   Andrea.

Re: Need new logo for openoffice.apache.org

[Andrea Pescetti]

On 22/10/2012 Andrea Pescetti wrote:

On 20/10/2012 imacat wrote:

I happen to have a 300x100 logo at hand, so I updated it. Feel free
to revise it if you feel my uploaded logo is ugly.

The reference logo is
http://www.openoffice.org/images/AOO_logos/AOO-logo-hires.jpg ...
http://incubator.apache.org/openofficeorg/images/300x100_dj_trans.png
has different colors and different fonts so I would remove it


I've replaced it with a 300x100 version of the reference logo. I'm not 
sure it is being used, but anyway it's good to enforce consistency and 
the previous version remains of course in SVN.


Regards,
  Andrea.

Re: [RELEASE] Releasing new languages for 3.4.1

[Rob Weir]

On Fri, Oct 26, 2012 at 3:07 AM, Andrea Pescetti  wrote:
> It is now clear that, thanks to new volunteers now coordinating on ooo-l10n,
> we will soon be in a position to add 3-5 new languages to Apache OpenOffice.
>
> It is also clear that at the moment we have no demand for a 3.4.2 with
> critical bugfixes because... well, 3.4.1 does not have critical bugs. And
> releasing 3.4.2 only to add new languages seems definitely overkill: 80% of
> the work would be wasted, we would need a new vote and so on.
>
> So, what's the best way to get those new languages released?
>

A few options:

1) release new languages via lang packs only for now

2) release full installs, but for only these new languages

3) wait until next planned release (or unplanned release if we find we
need a 3.4.2)

Can we really skip the release process?  PO files == source, right?
Maybe it is not C++ code, but it is something like "source resources".
 Maybe a question for legal-discuss if we're not certain.

However in options 1 or 2 maybe we can do something lightweight, like
release a source package of only the new PO files, or even a diff that
can be applied to the base 3.4.1 source package?

Another thing to consider is that we could very easily get another 5
languages next month.  Once we get the volunteer program up and
running, and promote it, I expect these will come in at a rapid pace.
How do we want to handle this on an ongoing basis?  New point release
for every new language?  Every 5 new languages?  It is certainly good
for volunteers to get the encouragement of a fast turnaround for their
work.  But this is the same for a C++ programmer.  But if a programmer
adds a new feature to the trunk they still need to wait several months
for it to be released.

In the end, I wonder whether the best solution is to get into a steady
release cycle of quarterly releases (every 3 or 4 months)?  That way
we never need to wait very long to release new features or
translations or bug fixes.

-Rob

> Would a checkout of the 3.4.1 tag, where we replace the language files for
> those 3-5 languages and then build, work as an interim solution? I honestly
> don't like it very much (it's of course better than committing to a tag, but
> still not clean), but it would probably allow to skip the release process
> and voting, since we would merely be adding 3-5 binary artifacts (built for
> different platforms).
>
> Any better solutions? Wait for the moment when a 3.4.2 is needed? Picking
> some bugfixes and forcing a 3.4.2 soon?
>
> Regards,
>   Andrea.

Re: Apache and ODF

[Rob Weir]

On Fri, Oct 26, 2012 at 3:42 AM, Fan Zheng  wrote:
> Hi, All:
>
> I am confused about the UX specifications of document representation
> requirement on mobile devices, that which is the most first important point
> should be, the different device condition adaptability of layout result? or
> the fidelity of the document originally recorded?
>

Generally both modes are supported.  And sometimes it varies based on
the format.

For example, PDF files are fixed-layout.  So they require you to "zoom
and pan" on smaller screens.  But larger screens, like Kindle DX or
iPad can show a full PDF page.

ePub and MOBI digital book files are designed to reflow according to
screen size and user's font size preferences.

But some content types, like magazines on the Kindle, can work both
ways.  The user can choose to have a full-page layout that mimics the
original printed magazine.  Or they can choose to have it reflow per
the screen and font size.

So ideally we would want to support both.

-Rob

> For example. An ODT format text document with several pages sized as
> "Letter", which is physically defined as 279:216 (ratio as 1.29), and user
> want to render it in a Kindle Fire, which supplies a 1024:600 (ratio as
> 1.71) screen for presenting. If we do much more care about the adaptability
> of representation, lots data recorded inside the file will be changed,
> removed or even ignored. But, if we care about the fidelity much more, we
> have to record all the document data inside, and rendering it on the
> devices dutifully. In the case, all we could do for the UX, is to give some
> adjustable scale.  Such differences are meaning not only the pagination
> stuff, but also some solid data inside: thinking about a full
> page-width-size table for instance.
>
> Of cause, all the former document editor/viewer applications for desktop,
> will obey the "Keep Fidelity" as the very first rule. But what about the
> mobile device platforms?
>
> As such differences will actually lead the solution into the different
> direction, we maybe should make it clear before having a deeper discussion.
>
> Thanks.
>
> ZhengFan
>
>
> 2012/10/26 Andreas Säger 
>
>> Am 25.10.2012 21:14, Rob Weir wrote:
>> >
>> > 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
>> >
>>
>> Thank you. I know about the converters. The problem is that all our
>> office documents are ODF documents. The Kindle device does not provide
>> any access to our documents until they have been converted by some other
>> device.
>>
>>
>>

Re: Apache and ODF

[Andreas Säger]

Am 25.10.2012 21:14, Rob Weir wrote:
> 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.
> 

For the records: Amazon does not even deliver .epub files sent via Email
to the mail account of the Kindle Fire HD (it drops attachments into the
home folder). The sender (me) gets an error mail with a list of accepted
formats.

Re: Apache Asia Roadshow 2012 - Dec 13th Beijing

[Shenfeng Liu]

Don & Peter,
  I think it is a very good opportunity to promote Apache OpenOffice in
China marketing through Apache Asia Roadshow 2012. And from another side,
the wide influence of OpenOffice can also help to promote Apache.
  I'd like to work with Peter together on it. The target can be not only
attract individual volunteers to participate the community, but also
demonstrate the business opportunities and attract local business partners.
  While first of all, I'd like to know more details about this event.
Perhaps Jimmy is the right contact?


BTW, I just took a small surgery yesterday, and in the following week I
have to spend most of the daytime in hospital for subsequent treatment. So
my response to the mail threads may be slow. But I will try to catch up on
this topic.

- Shenfeng Liu (Simon)




2012/10/26 Peter Junge 

> Hi Don,
>
> thanks for the notice. Unfortunately, the Apache Asia Roadshow 2012 seem
> to lack of promoting the event. I only heard about it by coincidence a
> couple of days ago.
>
> (more inline)
>
>
> On 10/25/2012 9:47 PM, Donald Harbison wrote:
>
>> On Thu, Oct 25, 2012 at 6:28 AM, Justin Erenkrantz > >wrote:
>>
>>
> [...]
>
>
>  we plan the main topic around cloud computing: open source really

>>> produce a
>>>
 basement  to the cloud computing, like Apache Hadoop and cloudstack;

>>> welcome
>>>
 any open source topic in or out of this area.

>>>
>>>
>> The Apache OpenOffice community has a significant local representation in
>> Beijing. I'm cc'ing the community
>> to alert our Chinese contributors to reach out to you and explore the
>> possibility of adding an Apache OpenOffice
>> session to increase its visibility. We just graduated to an Apache TLP, so
>> we have a solid foundation upon which
>> to build with a strong global community. The Chinese community is very
>> important and making a large contribution.
>>
>
> As I seem to be the only one in Beijing who's with OpenOffice from the
> beginning, I'd like to offer a talk about the history of OOo, if that is of
> interest. As the 13th is a weekday, I just have to find out if I can take a
> day off my daily job.
>
> @concom: I cannot find anything about the Apache Asia Roadshow 2012 at
> http://wiki.apache.org/**apachecon/ 
> Do you have a link to the Apache Asia Roadshow 2012 for me? I want to
> write an event announcement at the homepage of the Beijing Linux User Group
> (http://blug.chinalug.org/). We're reaching quite a few geeks.
>
> Best regards,
> Peter
>

Re: Apache Asia Roadshow 2012 - Dec 13th Beijing

[Jürgen Schmidt]

On 10/26/12 3:48 PM, Shenfeng Liu wrote:
> Don & Peter,
>   I think it is a very good opportunity to promote Apache OpenOffice in
> China marketing through Apache Asia Roadshow 2012. And from another side,
> the wide influence of OpenOffice can also help to promote Apache.
>   I'd like to work with Peter together on it. The target can be not only
> attract individual volunteers to participate the community, but also
> demonstrate the business opportunities and attract local business partners.
>   While first of all, I'd like to know more details about this event.
> Perhaps Jimmy is the right contact?
> 
> 
> BTW, I just took a small surgery yesterday, and in the following week I
> have to spend most of the daytime in hospital for subsequent treatment. So
> my response to the mail threads may be slow. But I will try to catch up on
> this topic.

Get well soon!

Juergen

> 
> - Shenfeng Liu (Simon)
> 
> 
> 
> 
> 2012/10/26 Peter Junge 
> 
>> Hi Don,
>>
>> thanks for the notice. Unfortunately, the Apache Asia Roadshow 2012 seem
>> to lack of promoting the event. I only heard about it by coincidence a
>> couple of days ago.
>>
>> (more inline)
>>
>>
>> On 10/25/2012 9:47 PM, Donald Harbison wrote:
>>
>>> On Thu, Oct 25, 2012 at 6:28 AM, Justin Erenkrantz >>> wrote:
>>>
>>>
>> [...]
>>
>>
>>  we plan the main topic around cloud computing: open source really
>
 produce a

> basement  to the cloud computing, like Apache Hadoop and cloudstack;
>
 welcome

> any open source topic in or out of this area.
>


>>> The Apache OpenOffice community has a significant local representation in
>>> Beijing. I'm cc'ing the community
>>> to alert our Chinese contributors to reach out to you and explore the
>>> possibility of adding an Apache OpenOffice
>>> session to increase its visibility. We just graduated to an Apache TLP, so
>>> we have a solid foundation upon which
>>> to build with a strong global community. The Chinese community is very
>>> important and making a large contribution.
>>>
>>
>> As I seem to be the only one in Beijing who's with OpenOffice from the
>> beginning, I'd like to offer a talk about the history of OOo, if that is of
>> interest. As the 13th is a weekday, I just have to find out if I can take a
>> day off my daily job.
>>
>> @concom: I cannot find anything about the Apache Asia Roadshow 2012 at
>> http://wiki.apache.org/**apachecon/ 
>> Do you have a link to the Apache Asia Roadshow 2012 for me? I want to
>> write an event announcement at the homepage of the Beijing Linux User Group
>> (http://blug.chinalug.org/). We're reaching quite a few geeks.
>>
>> Best regards,
>> Peter
>>
> 

Re: [PROPOSAL] "difficulty" field for Bugzilla

[Rob Weir]

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

> -Andre
>

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

[Rob Weir]

On Fri, Oct 26, 2012 at 4:36 AM, Graham Lauder  wrote:
> The launch of 4.0 is a unique opportunity in the life of AOO both now and
> far into the future.
>
> The branding needs to position us in the market place, be distinctive and
> unique and makes a statement about the product.
>
> The creation of this requires a skillset that we do not have an over
> abundance of in the project.
>
> The proposal therefore is to initiate a contest to create this new
> branding, this would have multiple benefits in terms of community outreach,
> marketing and raising brand awareness.
>
> The contest would be source of the eventual branding of AOO 4.0
>

+1

The devil is in the details, but I think a contest can be a great way
of getting many ideas, but also promoting AOO 4.0.  It makes it "an
event".

I think Dave mentioned that another Apache project had a logo contest
and received a large number of entries.

> The process would be:
>
> Formulate a RFP with contest details and guidelines (these would include
> the product name and a reasonable outline of our target markets),
> timeframe, methodologies of presentation and breadth of branding elements.
>
> Perhaps sound out some sponsors for a prize
>
> Filter responses for eligibility according to the initial criteria
>
> Filter responses for global appropriateness
>
> Filter responses for target market relevance
>

It will be important that this filtering is done in a way that
everyone sees as fair.  Who judges "global appropriateness", for
example?

One way might be to appoint a judging panel.

> Communicate with the creators of this first shortlist to get them to sell
> their idea
>
> Shortlist to a dozen or less based on function (ie usability across
> multiple media)
>

For maximum impact we could have blog post and social media campaign
to promote the short list of logos and drive traffic to the survey.

> Create a survey to gauge general public impressions/feelings with regard to
> certain branding criteria: Uniqueness, Impact, Impression and
> Representation.
>
> Reduce and Repeat.
>
> If no clear "winner" emerges then PMC becomes the tiebreaker
>
> Lazy consensus 5 days seeing as how the weekend is nearly upon us
>
> Cheers
> GL

Re: [proposal] Outdated articles in Wiki

[Jürgen Schmidt]

On 10/25/12 9:19 PM, jan iversen wrote:
> Maybe we could move them to an archive ??

I think we can find probably common consensus that we want to delete
pages to clean up this old stuff.

For example nobody needs today the old building guides. Let us focus on
the future and here I think less but correct and up-to-date information
is more.

When I remember correct there exist a template that could be used to
mark a page for deletion.

Simply put {{Delete}} on top of the page

Or we can create our own delete template with further instructions how
to proceed.

Administrator can for this from time to time and can delete stuff. Or we
can try to cleanup such pages via a wiki bot.

Juergen


> 
> jan
> 
> On 25 October 2012 21:12, Alexandro Colorado  wrote:
> 
>> Nobody want to delete information and wiki pages only admin can
>> actually delete pages. Even then there might be some rights about
>> ownership. Is like sourceforge dont delete inactive projects.
>>
>> Still good conversation to debate.
>>
>> On 10/25/12, jan iversen  wrote:
>>> To my knowledge, articles that are marked outdated with a reference to a
>>> newer article stays in Wiki.
>>>
>>> Would it not be a good idea to remove such pages, in order not to confuse
>>> users ??
>>>
>>> There are however no means, which I can find, to do that ?
>>>
>>> Reason for my idea/question is that I am looking at localization (l10n),
>>> and there are a bit of old information.
>>>
>>> Jan.
>>>
>>
>>
>> --
>> Alexandro Colorado
>> PPMC Apache OpenOffice
>> http://es.openoffice.org
>>
> 

Re: [proposal] Outdated articles in Wiki

[jan iversen]

Do you mean the "outdated" symbol, which should do just fine ??

Jan.

On 26 October 2012 17:18, Jürgen Schmidt  wrote:

> On 10/25/12 9:19 PM, jan iversen wrote:
> > Maybe we could move them to an archive ??
>
> I think we can find probably common consensus that we want to delete
> pages to clean up this old stuff.
>
> For example nobody needs today the old building guides. Let us focus on
> the future and here I think less but correct and up-to-date information
> is more.
>
> When I remember correct there exist a template that could be used to
> mark a page for deletion.
>
> Simply put {{Delete}} on top of the page
>
> Or we can create our own delete template with further instructions how
> to proceed.
>
> Administrator can for this from time to time and can delete stuff. Or we
> can try to cleanup such pages via a wiki bot.
>
> Juergen
>
>
> >
> > jan
> >
> > On 25 October 2012 21:12, Alexandro Colorado  wrote:
> >
> >> Nobody want to delete information and wiki pages only admin can
> >> actually delete pages. Even then there might be some rights about
> >> ownership. Is like sourceforge dont delete inactive projects.
> >>
> >> Still good conversation to debate.
> >>
> >> On 10/25/12, jan iversen  wrote:
> >>> To my knowledge, articles that are marked outdated with a reference to
> a
> >>> newer article stays in Wiki.
> >>>
> >>> Would it not be a good idea to remove such pages, in order not to
> confuse
> >>> users ??
> >>>
> >>> There are however no means, which I can find, to do that ?
> >>>
> >>> Reason for my idea/question is that I am looking at localization
> (l10n),
> >>> and there are a bit of old information.
> >>>
> >>> Jan.
> >>>
> >>
> >>
> >> --
> >> Alexandro Colorado
> >> PPMC Apache OpenOffice
> >> http://es.openoffice.org
> >>
> >
>
>

RE: Apache and ODF

[Dennis E. Hamilton]

@Rory,

I agree about Kindle.  A Kindle Fire has more functionality and all of the UI 
capabilities one expects of an Android device, whereas the Kindle Readers have 
a different, special-purpose application.

I see Rob has provided a comprehensive statement later on this thread.  I would 
add that this is not a matter that requires particular support in ODF.  
Implementations of ODF support clearly have discretion in this area, since 
there is no specification of how presentation is handled for editing.  

 - Dennis

OTHER EXPERIENCE

My smart phone has Adobe (Acrobat) Reader on it.
 
Acrobat Reader maintains layout fidelity but it is easy to zoom into the 
full-page view and also move around on it.  I can rotate the phone, of course, 
in order to have a wider view or a longer view. 

For Word documents on my smartphone, there is less attention to formatting and 
print layout and the material is "re-flowed".  If I rotate the phone, the 
layout will be reflowed again to take advantage of the landscape or portrait 
window.  There is no attempt to replicate page layout.

Also, my phone does not allow editing of Office documents that have features 
the phone can't preserve.  (I have the option of opening the document, stored 
on SkyDrive, via the browser on the phone, however.)  

For Excel documents, there is more attention to layout preservation.  It is a 
bit in-between the PDF and the Word cases.

I agree, tablets and slates will have more room for improved layout.  Since a 
table may be able to connect to a printer, also, there would need to be a way 
to see a print preview, even if print layout is challenging, depending on the 
size of the tablet display.  A great deal will also depend on how much of the 
work is done on the device and how much is in the cloud, depending on 
connectivity and other provisions/options.

 - Dennis

-Original Message-
From: Rory O'Farrell [mailto:ofarr...@iol.ie] 
Sent: Friday, October 26, 2012 02:06
To: ooo-dev@incubator.apache.org
Subject: Re: Apache and ODF

On Fri, 26 Oct 2012 09:58:25 +0100
Ian Lynch  wrote:

> On 26 October 2012 08:42, Fan Zheng  wrote:
[ ... ]
> Is it possible to have choices? Keep the original page aspect ratio and
> scroll (Never used a kindle so not sure if it can scroll but obviously
> Android on phones can!) or have a "fit to aspect" where the page is scaled
> to the kindle in AOO befor export. If one of the pre-defined page templates
> in AOO was the kindle page size it would be possible to reformat the pages
> in a document to that size just as you can change from say A4 to US letter.
[ ... ]
> There can be issues with documents that have both portrait and landscape
> pages in them on normal computer screens.
[ ... ]

In this discussion it is important to specify clearly which Kindle is the 
target device, as the screen ratio and pixel count varies from device to device 
with the newer Kindles.  A stranger coming to this discussion might assume that 
Kindle genericly refers to the normal "reading" Kindle, with an 800h x 600w 
screen, which is the common Kindle in use.




-- 
Rory O'Farrell 

RE: [PROPOSAL] "difficulty" field for Bugzilla

[Dennis E. Hamilton]

@Andre,

Absolutely.

Knuth originally published his scale for difficulty of exercises in 1968.  It 
is in the Notes on Exercises in every edition since, including the 1997 version 
that I use now.

I modified it as you can see.  

Also, Knuth has a way to indicate when there were special skills needed along 
with the level of difficulty.  HM for higher-math, M for mathematically 
oriented.  I suppose one could use a CS (computer-science) difficulty as well 
as Advanced CS or similar prefix.  There are problems where one needs to prove 
that an algorithm is sound and also analysis with regard to the performance of 
an algorithm, when one is required.  

 - Dennis

Note: Although Fermat's famous theorem was proved since, Knuth has reduced it 
in the first 4 exercises in the book from [HM50] to [HM45] because it is still 
difficult to know how to do that proof even now.

-Original Message-
From: Andre Fischer [mailto:awf@gmail.com] 
Sent: Friday, October 26, 2012 00:48
To: ooo-dev@incubator.apache.org
Subject: Re: [PROPOSAL] "difficulty" field for Bugzilla

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?

-Andre

Re: [proposal] Outdated articles in Wiki

[Keith N. McKenna]

Hi All;

I have been slowly trying to update the documentation wiki with up to 
date information for users, but I am not a developer and have no inkling 
as to what is or is not good info in those docs.


A good place to start is the documents in the "Need Rework" category. An 
alphabetized list of these is available from the following link: 
http://wiki.openoffice.org/wiki/Category:Documentation/NeedsRework.


Regards
Keith

Jürgen Schmidt wrote:

On 10/25/12 9:19 PM, jan iversen wrote:

Maybe we could move them to an archive ??


I think we can find probably common consensus that we want to delete
pages to clean up this old stuff.

For example nobody needs today the old building guides. Let us focus on
the future and here I think less but correct and up-to-date information
is more.

When I remember correct there exist a template that could be used to
mark a page for deletion.

Simply put {{Delete}} on top of the page

Or we can create our own delete template with further instructions how
to proceed.

Administrator can for this from time to time and can delete stuff. Or we
can try to cleanup such pages via a wiki bot.

Juergen




jan

On 25 October 2012 21:12, Alexandro Colorado  wrote:


Nobody want to delete information and wiki pages only admin can
actually delete pages. Even then there might be some rights about
ownership. Is like sourceforge dont delete inactive projects.

Still good conversation to debate.

On 10/25/12, jan iversen  wrote:

To my knowledge, articles that are marked outdated with a reference to a
newer article stays in Wiki.

Would it not be a good idea to remove such pages, in order not to confuse
users ??

There are however no means, which I can find, to do that ?

Reason for my idea/question is that I am looking at localization (l10n),
and there are a bit of old information.

Jan.




--
Alexandro Colorado
PPMC Apache OpenOffice
http://es.openoffice.org

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

[Ian Lynch]

On 26 October 2012 16:04, Rob Weir  wrote:

> On Fri, Oct 26, 2012 at 4:36 AM, Graham Lauder 
> wrote:
> > The launch of 4.0 is a unique opportunity in the life of AOO both now and
> > far into the future.
> >
> > The branding needs to position us in the market place, be distinctive and
> > unique and makes a statement about the product.
> >
> > The creation of this requires a skillset that we do not have an over
> > abundance of in the project.
> >
> > The proposal therefore is to initiate a contest to create this new
> > branding, this would have multiple benefits in terms of community
> outreach,
> > marketing and raising brand awareness.
> >
> > The contest would be source of the eventual branding of AOO 4.0
> >
>
> +1
>
> The devil is in the details, but I think a contest can be a great way
> of getting many ideas, but also promoting AOO 4.0.  It makes it "an
> event".
>
> I think Dave mentioned that another Apache project had a logo contest
> and received a large number of entries.
>

I arranged one for the OOo schools mascot with Daniel Carrera. It was quite
easy to do and got a lot of publicity.

>
> > The process would be:
> >
> > Formulate a RFP with contest details and guidelines (these would include
> > the product name and a reasonable outline of our target markets),
> > timeframe, methodologies of presentation and breadth of branding
> elements.
> >
> > Perhaps sound out some sponsors for a prize
> >
> > Filter responses for eligibility according to the initial criteria
> >
> > Filter responses for global appropriateness
> >
> > Filter responses for target market relevance
> >
>
> It will be important that this filtering is done in a way that
> everyone sees as fair.  Who judges "global appropriateness", for
> example?
>
> One way might be to appoint a judging panel.
>


The way we did it was to put up all the entries on a web page and got all
the participants to vote on-line - peer review essentially. The winner was
clear-cut. A 16 year old Italian boy who aspired to be a graphic designer.



>
> > Communicate with the creators of this first shortlist to get them to sell
> > their idea
> >
> > Shortlist to a dozen or less based on function (ie usability across
> > multiple media)
> >
>
> For maximum impact we could have blog post and social media campaign
> to promote the short list of logos and drive traffic to the survey.
>
> > Create a survey to gauge general public impressions/feelings with regard
> to
> > certain branding criteria: Uniqueness, Impact, Impression and
> > Representation.
> >
> > Reduce and Repeat.
> >
> > If no clear "winner" emerges then PMC becomes the tiebreaker
> >
> > Lazy consensus 5 days seeing as how the weekend is nearly upon us
> >
> > Cheers
> > GL
>



-- 
Ian

Ofqual Accredited IT Qualifications (The Schools ITQ)

www.theINGOTs.org +44 (0)1827 305940

The Learning Machine Limited, Reg Office, 36 Ashby Road, Tamworth,
Staffordshire, B79 8AQ. Reg No: 05560797, Registered in England and
Wales.

Re: Another logo needs updating: "Get it here!"

[Kay Schenk]

On 10/25/2012 04:58 PM, Rob Weir wrote:

On Thu, Oct 25, 2012 at 5:57 PM, Kay Schenk  wrote:

On Mon, Oct 22, 2012 at 3:37 PM, Kay Schenk  wrote:




On 10/20/2012 12:23 PM, Rob Weir wrote:


http://incubator.apache.org/**openofficeorg/get-it-here.html

This logo has an integrated incubator reference in it as well.

I think Drew made the most recent version of this.

Anyone have the source, or can easily respin it without the "incubator"
block?

Thanks!

-Rob



oh boy...while looking around just now, it seems we DO have an svg file of
Get it here! *without* incubator on it --

http://www.openoffice.org/**images/AOO_logos/svg/get-aoo_**300x100.svg

if this is any use ...





Ok, we still need to do cleanup on this one.

Do we want to replace--

  http://incubator.apache.org/openofficeorg/images/get-it-here/en.png

with a link to a 300x100 rendering (without the beveled edges, so older I
suspect), at:

http://www.openoffice.org/images/AOO_logos/get-aoo-300x100.png



OK.  That's why I did for now.  It is same size and everything.

-Rob


thanks...since you were the primary contact on this, I hesitated to do 
this if there were objections. I am not sufficiently talented to add 
bevels to this image, but I hope someone is.






we have .svg for this if someone wants to re-bevel.




--
--**--**


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


--

MzK

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

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

[Graham Lauder]

On Friday 26 Oct 2012 11:04:46 Rob Weir wrote:
> On Fri, Oct 26, 2012 at 4:36 AM, Graham Lauder  wrote:
> > The launch of 4.0 is a unique opportunity in the life of AOO both now
> > and
> > far into the future.
> > 
> > The branding needs to position us in the market place, be distinctive
> > and
> > unique and makes a statement about the product.
> > 
> > The creation of this requires a skillset that we do not have an over
> > abundance of in the project.
> > 
> > The proposal therefore is to initiate a contest to create this new
> > branding, this would have multiple benefits in terms of community
> > outreach, marketing and raising brand awareness.
> > 
> > The contest would be source of the eventual branding of AOO 4.0
> 
> +1
> 
> The devil is in the details, but I think a contest can be a great way
> of getting many ideas, but also promoting AOO 4.0.  It makes it "an
> event".
> 
> I think Dave mentioned that another Apache project had a logo contest
> and received a large number of entries.

Which is why we go with "Branding", it's much broader than just a graphic 
logo.  there's color pallet, overall style, message, tenor, presentation.  
Those who just present a logo in isolation will be filtered early.  Those that 
have a grasp of the full depth of the brand but without the whole package will 
show early which is why we go back to the responders for more detail later on.  
Initial  proposals will to show understanding of the task first up.  

> 
> > The process would be:
> > 
> > Formulate a RFP with contest details and guidelines (these would include
> > the product name and a reasonable outline of our target markets),
> > timeframe, methodologies of presentation and breadth of branding
> > elements.
> > 
> > Perhaps sound out some sponsors for a prize
> > 
> > Filter responses for eligibility according to the initial criteria
> > 
> > Filter responses for global appropriateness
> > 
> > Filter responses for target market relevance
> 
> It will be important that this filtering is done in a way that
> everyone sees as fair.  Who judges "global appropriateness", for
> example?
> 
> One way might be to appoint a judging panel.

Indeed, although "judging" is probably not the best description, I just can't 
think of a better one.  The initial filtering is done on purely objective 
criteria laid out in the RFP.  Global appropriateness is a minefield I agree, 
but hopefully we have a broad enough cultural awareness on our L10n list to 
help us avoid any clumsy gaffs.

> 
> > Communicate with the creators of this first shortlist to get them to
> > sell
> > their idea
> > 
> > Shortlist to a dozen or less based on function (ie usability across
> > multiple media)
> 
> For maximum impact we could have blog post and social media campaign
> to promote the short list of logos and drive traffic to the survey.

+1 good plan, as Ian was saying initial target will be Design Colleges and 
oither such educational institutions.  Any others that may be interested could 
be reached by community contact.  The initial contact will ideally be 
concentrated, so we publicise that the RFP will be available on a  specific 
date and the submissions will close on another date.  Otherwise it will drag 
on.  

Experience shows however that logos will continue to come long past the 
closing as people seem to think that their new version is greater than 
anything that has come before and that the whole process will be dumped just 
so we can bathe in the light at the feet of the new Michaelangelo!  :)

Cheers
GL

> 
> > Create a survey to gauge general public impressions/feelings with regard
> > to certain branding criteria: Uniqueness, Impact, Impression and
> > Representation.
> > 
> > Reduce and Repeat.
> > 
> > If no clear "winner" emerges then PMC becomes the tiebreaker
> > 
> > Lazy consensus 5 days seeing as how the weekend is nearly upon us
> > 
> > Cheers
> > GL

Re: [proposal] Outdated articles in Wiki

[Keith N. McKenna]

Jan;

No the outdated symbol is different. {{Delete}} Is a template that puts 
the article in a special category to be deleted by an admin or by a bot.


Keith

jan iversen wrote:

Do you mean the "outdated" symbol, which should do just fine ??

Jan.

On 26 October 2012 17:18, Jürgen Schmidt  wrote:


On 10/25/12 9:19 PM, jan iversen wrote:

Maybe we could move them to an archive ??


I think we can find probably common consensus that we want to delete
pages to clean up this old stuff.

For example nobody needs today the old building guides. Let us focus on
the future and here I think less but correct and up-to-date information
is more.

When I remember correct there exist a template that could be used to
mark a page for deletion.

Simply put {{Delete}} on top of the page

Or we can create our own delete template with further instructions how
to proceed.

Administrator can for this from time to time and can delete stuff. Or we
can try to cleanup such pages via a wiki bot.

Juergen




jan

On 25 October 2012 21:12, Alexandro Colorado  wrote:


Nobody want to delete information and wiki pages only admin can
actually delete pages. Even then there might be some rights about
ownership. Is like sourceforge dont delete inactive projects.

Still good conversation to debate.

On 10/25/12, jan iversen  wrote:

To my knowledge, articles that are marked outdated with a reference to

a

newer article stays in Wiki.

Would it not be a good idea to remove such pages, in order not to

confuse

users ??

There are however no means, which I can find, to do that ?

Reason for my idea/question is that I am looking at localization

(l10n),

and there are a bit of old information.

Jan.




--
Alexandro Colorado
PPMC Apache OpenOffice
http://es.openoffice.org

[APEU2012] Schedule on 11/5

[imacat]

Dear all,

I will arrive Hotel Sinsheim at noon, 11/5.  You may find me in the
afternoon, 11/5, if you want to discuss with me about forum, wiki or
anything.  We do not have a scheduled Hackathon, but we may still work
on something.  See you there. ^_*'

P.S. Do we have anyone that is local at Sinsheim or will arrive earlier?

-- 
Best regards,
imacat ^_*' 
PGP Key http://www.imacat.idv.tw/me/pgpkey.asc

<> News: http://www.wov.idv.tw/
Tavern IMACAT's http://www.imacat.idv.tw/
Woman in FOSS in Taiwan http://wofoss.blogspot.com/
OpenOffice http://www.openoffice.org/
EducOO/OOo4Kids Taiwan http://www.educoo.tw/
Greenfoot Taiwan http://greenfoot.westart.tw/



signature.asc
Description: OpenPGP digital signature

Re: [RELEASE]: new snapshot base don revision r1400866

[Ariel Constenla-Haile]

On Wed, Oct 24, 2012 at 05:27:41PM +0200, Jürgen Schmidt wrote:
> Hi,
> 
> a new snapshot build is available for MacOS and Windows. Linux will be
> available later.

They are now available.

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.


> See
> https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds
> 
> I have called it 3.5 snapshot but we haven't really confirmed if our
> next release will be a 3.5 or 4.0. That can be discussed and decided
> when we have finalized our plans.
> 
> The snapshot is build on top of revision r1400866.
> 
> I have provided full install set for all supported languages and a
> further language pack for en-US + the SDK and src release.

It seems you've built SDKs that install as normal version, not as
OOo-Dev, please check (this is the impression I get from their file
name, they gave me an error when I generated the wiki page with my
script).


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpw4xgQJwJFk.pgp
Description: PGP signature

Re: svn commit: r1402586 - /incubator/ooo/site/trunk/content/openofficeorg/pmc-faqs.mdtext

[Dave Fisher]

I have access to the current list and will make the full update by early next 
week.

Sent from my iPhone

On Oct 26, 2012, at 10:19 AM, b...@apache.org wrote:

> Author: bmcs
> Date: Fri Oct 26 17:19:31 2012
> New Revision: 1402586
> 
> URL: http://svn.apache.org/viewvc?rev=1402586&view=rev
> Log:
> Updated moderators
> 
> Modified:
>incubator/ooo/site/trunk/content/openofficeorg/pmc-faqs.mdtext
> 
> Modified: incubator/ooo/site/trunk/content/openofficeorg/pmc-faqs.mdtext
> URL: 
> http://svn.apache.org/viewvc/incubator/ooo/site/trunk/content/openofficeorg/pmc-faqs.mdtext?rev=1402586&r1=1402585&r2=1402586&view=diff
> ==
> --- incubator/ooo/site/trunk/content/openofficeorg/pmc-faqs.mdtext (original)
> +++ incubator/ooo/site/trunk/content/openofficeorg/pmc-faqs.mdtext Fri Oct 26 
> 17:19:31 2012
> @@ -40,10 +40,10 @@ contact first, before escalating to Apac
> 
> Each mailing list has one or more moderators.  
> 
> -  - ooo-dev moderators are Rob Weir,
> -  - ooo-users moderators are Rob Weir, Simon Phipps, 
> +  - ooo-dev moderators are Rob Weir, Dave Barton
> +  - ooo-users moderators are Rob Weir, Simon Phipps, Dave Barton
>   - ooo-qa moderators are Rob Weir,
> -  - ooo-marketing moderators are Rob Weir,
> +  - ooo-marketing moderators are Rob Weir, Dave Barton
>   - ooo-private (restricted access) moderators are Rob Weir,
>   - ooo-security (restricted access)with Rob Weir, Dennis Hamilton, Wolf 
> Halton 
> and Juergen Schmidt as members.  New members can be added by consensus of the 
> PMC
> 
> 

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

[Dave Fisher]

Sent from my iPhone

On Oct 26, 2012, at 9:59 AM, Graham Lauder  wrote:

> On Friday 26 Oct 2012 11:04:46 Rob Weir wrote:
>> On Fri, Oct 26, 2012 at 4:36 AM, Graham Lauder  wrote:
>>> The launch of 4.0 is a unique opportunity in the life of AOO both now
>>> and
>>> far into the future.
>>> 
>>> The branding needs to position us in the market place, be distinctive
>>> and
>>> unique and makes a statement about the product.
>>> 
>>> The creation of this requires a skillset that we do not have an over
>>> abundance of in the project.
>>> 
>>> The proposal therefore is to initiate a contest to create this new
>>> branding, this would have multiple benefits in terms of community
>>> outreach, marketing and raising brand awareness.
>>> 
>>> The contest would be source of the eventual branding of AOO 4.0
>> 
>> +1
>> 
>> The devil is in the details, but I think a contest can be a great way
>> of getting many ideas, but also promoting AOO 4.0.  It makes it "an
>> event".
>> 
>> I think Dave mentioned that another Apache project had a logo contest
>> and received a large number of entries.
> 
> Which is why we go with "Branding", it's much broader than just a graphic 
> logo.  there's color pallet, overall style, message, tenor, presentation.  
> Those who just present a logo in isolation will be filtered early.  Those 
> that 
> have a grasp of the full depth of the brand but without the whole package 
> will 
> show early which is why we go back to the responders for more detail later 
> on.  
> Initial  proposals will to show understanding of the task first up.

For Apache Flex there were over 50 submissions of varying quality, style and 
presentation including a video. Everything was handled on the dev list. There 
was an understanding that branding would be involved. There were two rounds of 
voting and the community and the PPMC were in close agreement. The PPMC chose 
the community's second choice, but it was a very close second.

The licensing required was made clear and the submissions were gathered on the 
podling site.

For this contest we should be very clear  about the contexts that submissions 
should show. Site, splash screen, tshirt, etc.

Regards,
Dave

>  
> 
>> 
>>> The process would be:
>>> 
>>> Formulate a RFP with contest details and guidelines (these would include
>>> the product name and a reasonable outline of our target markets),
>>> timeframe, methodologies of presentation and breadth of branding
>>> elements.
>>> 
>>> Perhaps sound out some sponsors for a prize
>>> 
>>> Filter responses for eligibility according to the initial criteria
>>> 
>>> Filter responses for global appropriateness
>>> 
>>> Filter responses for target market relevance
>> 
>> It will be important that this filtering is done in a way that
>> everyone sees as fair.  Who judges "global appropriateness", for
>> example?
>> 
>> One way might be to appoint a judging panel.
> 
> Indeed, although "judging" is probably not the best description, I just can't 
> think of a better one.  The initial filtering is done on purely objective 
> criteria laid out in the RFP.  Global appropriateness is a minefield I agree, 
> but hopefully we have a broad enough cultural awareness on our L10n list to 
> help us avoid any clumsy gaffs.
> 
>> 
>>> Communicate with the creators of this first shortlist to get them to
>>> sell
>>> their idea
>>> 
>>> Shortlist to a dozen or less based on function (ie usability across
>>> multiple media)
>> 
>> For maximum impact we could have blog post and social media campaign
>> to promote the short list of logos and drive traffic to the survey.
> 
> +1 good plan, as Ian was saying initial target will be Design Colleges and 
> oither such educational institutions.  Any others that may be interested 
> could 
> be reached by community contact.  The initial contact will ideally be 
> concentrated, so we publicise that the RFP will be available on a  specific 
> date and the submissions will close on another date.  Otherwise it will drag 
> on.  
> 
> Experience shows however that logos will continue to come long past the 
> closing as people seem to think that their new version is greater than 
> anything that has come before and that the whole process will be dumped just 
> so we can bathe in the light at the feet of the new Michaelangelo!  :)
> 
> Cheers
> GL
> 
>> 
>>> Create a survey to gauge general public impressions/feelings with regard
>>> to certain branding criteria: Uniqueness, Impact, Impression and
>>> Representation.
>>> 
>>> Reduce and Repeat.
>>> 
>>> If no clear "winner" emerges then PMC becomes the tiebreaker
>>> 
>>> Lazy consensus 5 days seeing as how the weekend is nearly upon us
>>> 
>>> Cheers
>>> GL

Re: [RELEASE] Releasing new languages for 3.4.1

[Andrea Pescetti]

Rob Weir wrote:

1) release new languages via lang packs only for now
2) release full installs, but for only these new languages


I don't see a big difference between a langpack and a full install in 
this case, so I'd go for full installs, unless releasing langpacks helps 
in communicating that these are "late" additions and that full installs 
will come with the next release.



Can we really skip the release process?  PO files == source, right?


Yes, not exactly but quite (PO files are not taken verbatim into source, 
but they are imported and influence resource files which are in the 
source tree).



Maybe a question for legal-discuss if we're not certain.


If in the end we have consensus on releasing new languages for 3.4.1 
instead of making a new release, indeed we will ask.



How do we want to handle this on an ongoing basis?  New point release
for every new language?  Every 5 new languages?  It is certainly good
for volunteers to get the encouragement of a fast turnaround for their
work.  But this is the same for a C++ programmer.


There are big differences here, that are also the reason for me to 
consider releasing these new languages as soon as possible:
- A translation is often done by a team; if we can publish it 
immediately, the team can the be involved in other activities like 
revamping the N-L website, local promotion and so on; if we wait too 
much, we risk to have no volunteers for the following release.
- 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.



In the end, I wonder whether the best solution is to get into a steady
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 (3.4 or 3.5? probably we would ask new 
volunteers to focus on strings that will be in the next release, even 
though they aren't frozen yet).


Regards,
  Andrea.

Re: [proposal] Outdated articles in Wiki

[jan iversen]

So if an article is outdated, then it is ready for deletionor ???

Is it wise to have outdated articles alongside the correct/newer ones,
thinking of e.g. building instructions it would at least confuse me.

but I have no problem using {{Delete}} thanks for advicing me.

jan.

On 26 October 2012 19:03, Keith N. McKenna wrote:

> Jan;
>
> No the outdated symbol is different. {{Delete}} Is a template that puts
> the article in a special category to be deleted by an admin or by a bot.
>
> Keith
>
>
> jan iversen wrote:
>
>> Do you mean the "outdated" symbol, which should do just fine ??
>>
>> Jan.
>>
>> On 26 October 2012 17:18, Jürgen Schmidt  wrote:
>>
>>  On 10/25/12 9:19 PM, jan iversen wrote:
>>>
 Maybe we could move them to an archive ??

>>>
>>> I think we can find probably common consensus that we want to delete
>>> pages to clean up this old stuff.
>>>
>>> For example nobody needs today the old building guides. Let us focus on
>>> the future and here I think less but correct and up-to-date information
>>> is more.
>>>
>>> When I remember correct there exist a template that could be used to
>>> mark a page for deletion.
>>>
>>> Simply put {{Delete}} on top of the page
>>>
>>> Or we can create our own delete template with further instructions how
>>> to proceed.
>>>
>>> Administrator can for this from time to time and can delete stuff. Or we
>>> can try to cleanup such pages via a wiki bot.
>>>
>>> Juergen
>>>
>>>
>>>
 jan

 On 25 October 2012 21:12, Alexandro Colorado  wrote:

  Nobody want to delete information and wiki pages only admin can
> actually delete pages. Even then there might be some rights about
> ownership. Is like sourceforge dont delete inactive projects.
>
> Still good conversation to debate.
>
> On 10/25/12, jan iversen  wrote:
>
>> To my knowledge, articles that are marked outdated with a reference to
>>
> a
>>>
 newer article stays in Wiki.
>>
>> Would it not be a good idea to remove such pages, in order not to
>>
> confuse
>>>
 users ??
>>
>> There are however no means, which I can find, to do that ?
>>
>> Reason for my idea/question is that I am looking at localization
>>
> (l10n),
>>>
 and there are a bit of old information.
>>
>> Jan.
>>
>>
>
> --
> Alexandro Colorado
> PPMC Apache OpenOffice
> http://es.openoffice.org
>
>

>>>
>>>
>>
>
>

Re: [RELEASE] Releasing new languages for 3.4.1

[jan iversen]

just two small comments.

have a nice weekend.
Jan.

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

> Rob Weir wrote:
>
>> 1) release new languages via lang packs only for now
>> 2) release full installs, but for only these new languages
>>
>
> I don't see a big difference between a langpack and a full install in this
> case, so I'd go for full installs, unless releasing langpacks helps in
> communicating that these are "late" additions and that full installs will
> come with the next release.
>
>
>  Can we really skip the release process?  PO files == source, right?
>>
>
> Yes, not exactly but quite (PO files are not taken verbatim into source,
> but they are imported and influence resource files which are in the source
> tree).
>
>
>  Maybe a question for legal-discuss if we're not certain.
>>
>
> If in the end we have consensus on releasing new languages for 3.4.1
> instead of making a new release, indeed we will ask.
>
>
>  How do we want to handle this on an ongoing basis?  New point release
>> for every new language?  Every 5 new languages?  It is certainly good
>> for volunteers to get the encouragement of a fast turnaround for their
>> work.  But this is the same for a C++ programmer.
>>
>
> There are big differences here, that are also the reason for me to
> consider releasing these new languages as soon as possible:
> - A translation is often done by a team; if we can publish it immediately,
> the team can the be involved in other activities like revamping the N-L
> website, local promotion and so on; if we wait too much, we risk to have no
> volunteers for the following release.
> - 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.

>
>
>  In the end, I wonder whether the best solution is to get into a steady
>> 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 (3.4 or 3.5? probably we would ask new
> volunteers to focus on strings that will be in the next release, even
> though they aren't frozen yet).
>
- 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. In my experience the risk for changed
messages are relatively low.

>
> Regards,
>   Andrea.
>

Re: [RELEASE]: new snapshot base don revision r1400866

[RGB ES]

2012/10/26 Ariel Constenla-Haile 

> On Wed, Oct 24, 2012 at 05:27:41PM +0200, Jürgen Schmidt wrote:
> > Hi,
> >
> > a new snapshot build is available for MacOS and Windows. Linux will be
> > available later.
>
> They are now available.
>
> 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.
>
>
> > See
> >
> https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds
> >
> > I have called it 3.5 snapshot but we haven't really confirmed if our
> > next release will be a 3.5 or 4.0. That can be discussed and decided
> > when we have finalized our plans.
> >
> > The snapshot is build on top of revision r1400866.
> >
> > I have provided full install set for all supported languages and a
> > further language pack for en-US + the SDK and src release.
>
> It seems you've built SDKs that install as normal version, not as
> OOo-Dev, please check (this is the impression I get from their file
> name, they gave me an error when I generated the wiki page with my
> script).
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>

On the forums we are testing the ES version and I have a doubt about non
translated text on the UI: while there are some strings that comes from new
code (new functions on Calc) there are other strings that are identical to
the ones on 3.4.1... but on 3.5dev are not translated! For example, under
"Insertar" (Insert) there is an entry "Movie and Sound" that it is not
translated on 3.5  (on 3.4.1 says "Vídeo y sonido"). Is this something to
worry about or it is better to wait until 3.5 is on Pootle and everything
is correctly integrated?

Regards
Ricardo

Re: [PROPOSAL] "difficulty" field for Bugzilla

[Marcus (OOo)]

Am 10/24/2012 09:08 PM, schrieb Rob Weir:

As you have probably noticed, I'm engaged in a variety of initiatives
to grow the community, bring in more volunteers, etc.  One additional
piece that I think would be useful is to add a new field to Bugzilla
to indicate the difficulty level of the bug.  Of course, this will
often not be known.  But in some cases, we do know, and where we do
know we can indicate this.

What this allows us to do is then have search filters that return only
open easy bugs.  These are ideal for new developer volunteers on the
project who are looking for items that match their lesser familiarity
with the code.  It also allows a developer to step up to more
challenging bugs over time.

A similar approach, which they called "easy hacks", was successfully
used by LibreOffice.

If there are no objections, I'll add a new field to Bugzilla called
"cf_difficulty_level", and which a drop down UI with the following
choices:

UNKNOWN (default)
TRIVIAL
EASY
MODERATE
HARD
WIZARD

(I'm certainly open to variations on the names)

I'd then rely on other developers to help "seed" the database with
some TRIVIAL and EASY bugs, so new volunteers will have something to
work with as they familiarize themselves with the project.

I'll wait 72 hours, etc.


Even if it was not really 3 days ;-) and I'm a bit late, I just wanted 
to tell that this seems good idea to attract more new volunteers to get 
an entry point into our project.


Marcus

Re: [RELEASE]: new snapshot base don revision r1400866

[Ariel Constenla-Haile]

Hi Ricardo,

On Fri, Oct 26, 2012 at 08:24:26PM +0200, RGB ES wrote:
> On the forums we are testing the ES version and I have a doubt about non
> translated text on the UI: while there are some strings that comes from new
> code (new functions on Calc) there are other strings that are identical to
> the ones on 3.4.1... but on 3.5dev are not translated! For example, under
> "Insertar" (Insert) there is an entry "Movie and Sound" that it is not
> translated on 3.5  (on 3.4.1 says "Vídeo y sonido"). Is this something to
> worry about or it is better to wait until 3.5 is on Pootle and everything
> is correctly integrated?

you can expect this with strings that are retrieved using the UNO
command, the UNO command is what identifies every UI feature in the application
framework; you can find them in the XML files that define menu bars and
toolbars in the office installation, for example

grep -r ".uno:InsertAVMedia" 
/opt/openoffice.org/basis3.4/share/config/soffice.cfg/modules/

Labels for these commands are stored in configuration files. In this
case, ".uno:InsertAVMedia" was moved to the right configuration place:

* 3.4 branch, under Popups:
  
http://opengrok.adfinis-sygroup.org/source/xref/aoo-AOO34/main/officecfg/registry/data/org/openoffice/Office/UI/GenericCommands.xcu#5352

* trunk under Commands:
  
http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/officecfg/registry/data/org/openoffice/Office/UI/GenericCommands.xcu#3075

Strings that were moved to the right category will appear untranslated,
because they are now in fact different strings.
There were also several commands that had the same string but were
placed in different configuration files, these were moved to
GenericCommands.xcu, but you shouldn't note a difference here (only when
translating: several duplicated strings will be removed in 3.5).

So, yes, the Pootle server is in 3.4, the developer snapshots are in
3.5, you'll have to wait until Pootle gets in sync with trunk.


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpvMUUxWOULx.pgp
Description: PGP signature

Re: [proposal] Outdated articles in Wiki

[Keith N. McKenna]

Jan;
{{Documentation/Outdated}} and {{delete}} are two seperate entities. 
Outdated merely says that some inormation is outdated and should be 
revised. {{delete}} is a special case that marks a file for speedy 
deletion by an wiki administrator.


At least with the user documentation we tend to add to the document for 
newer versions of the software rather than get rid of it as there are 
still people using older versions. This can however get carried to 
extremes. My personal opinion is that it is probably  time to start 
seriously considering purging version 2.x stuff, but that is a 
discussion for another thread.


Regards
Keith


jan iversen wrote:

So if an article is outdated, then it is ready for deletionor ???

Is it wise to have outdated articles alongside the correct/newer ones,
thinking of e.g. building instructions it would at least confuse me.

but I have no problem using {{Delete}} thanks for advicing me.

jan.

On 26 October 2012 19:03, Keith N. McKenna wrote:


Jan;

No the outdated symbol is different. {{Delete}} Is a template that puts
the article in a special category to be deleted by an admin or by a bot.

Keith


jan iversen wrote:


Do you mean the "outdated" symbol, which should do just fine ??

Jan.

On 26 October 2012 17:18, Jürgen Schmidt  wrote:

  On 10/25/12 9:19 PM, jan iversen wrote:



Maybe we could move them to an archive ??



I think we can find probably common consensus that we want to delete
pages to clean up this old stuff.

For example nobody needs today the old building guides. Let us focus on
the future and here I think less but correct and up-to-date information
is more.

When I remember correct there exist a template that could be used to
mark a page for deletion.

Simply put {{Delete}} on top of the page

Or we can create our own delete template with further instructions how
to proceed.

Administrator can for this from time to time and can delete stuff. Or we
can try to cleanup such pages via a wiki bot.

Juergen




jan

On 25 October 2012 21:12, Alexandro Colorado  wrote:

  Nobody want to delete information and wiki pages only admin can

actually delete pages. Even then there might be some rights about
ownership. Is like sourceforge dont delete inactive projects.

Still good conversation to debate.

On 10/25/12, jan iversen  wrote:


To my knowledge, articles that are marked outdated with a reference to


a



newer article stays in Wiki.


Would it not be a good idea to remove such pages, in order not to


confuse



users ??


There are however no means, which I can find, to do that ?

Reason for my idea/question is that I am looking at localization


(l10n),



and there are a bit of old information.


Jan.




--
Alexandro Colorado
PPMC Apache OpenOffice
http://es.openoffice.org

Re: [RELEASE]: new snapshot base don revision r1400866

[Ariel Constenla-Haile]

On Fri, Oct 26, 2012 at 02:28:42PM -0300, Ariel Constenla-Haile wrote:
> On Wed, Oct 24, 2012 at 05:27:41PM +0200, Jürgen Schmidt wrote:
> > Hi,
> > 
> > a new snapshot build is available for MacOS and Windows. Linux will be
> > available later.
> 
> They are now available.
> 
> Once thing to pay attention for the next release is the increasing size:
> more than 14 Gb 

more than 14 Gb with all the language packs, with only en-US lang.
packs it's 13 Gb:

du -sh \
/home/jsc/public_html/developer-snapshots/r1400866/ \
/home/arielch/public_html/packages/r1400866/  \
/www/www.apache.org/dist/incubator/ooo/files/stable/3.4.1/ \
/www/www.apache.org/dist/incubator/ooo/files/localized/*/3.4.1/

7.6G/home/jsc/public_html/developer-snapshots/r1400866/
 13G/home/arielch/public_html/packages/r1400866/
1.0G/www/www.apache.org/dist/incubator/ooo/files/stable/3.4.1/
945M/www/www.apache.org/dist/incubator/ooo/files/localized/ar/3.4.1/
876M/www/www.apache.org/dist/incubator/ooo/files/localized/cs/3.4.1/
1.1G/www/www.apache.org/dist/incubator/ooo/files/localized/de/3.4.1/
900M/www/www.apache.org/dist/incubator/ooo/files/localized/en-GB/3.4.1/
888M/www/www.apache.org/dist/incubator/ooo/files/localized/es/3.4.1/
966M/www/www.apache.org/dist/incubator/ooo/files/localized/fi/3.4.1/
896M/www/www.apache.org/dist/incubator/ooo/files/localized/fr/3.4.1/
958M/www/www.apache.org/dist/incubator/ooo/files/localized/gl/3.4.1/
882M/www/www.apache.org/dist/incubator/ooo/files/localized/hu/3.4.1/
925M/www/www.apache.org/dist/incubator/ooo/files/localized/it/3.4.1/
949M/www/www.apache.org/dist/incubator/ooo/files/localized/ja/3.4.1/
933M/www/www.apache.org/dist/incubator/ooo/files/localized/km/3.4.1/
917M/www/www.apache.org/dist/incubator/ooo/files/localized/nl/3.4.1/
877M/www/www.apache.org/dist/incubator/ooo/files/localized/pt-BR/3.4.1/
919M/www/www.apache.org/dist/incubator/ooo/files/localized/ru/3.4.1/
866M/www/www.apache.org/dist/incubator/ooo/files/localized/sk/3.4.1/
886M/www/www.apache.org/dist/incubator/ooo/files/localized/sl/3.4.1/
891M/www/www.apache.org/dist/incubator/ooo/files/localized/zh-CN/3.4.1/
893M/www/www.apache.org/dist/incubator/ooo/files/localized/zh-TW/3.4.1/


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgp2D4wjvzZ3a.pgp
Description: PGP signature

Re: [RELEASE]: new snapshot base don revision r1400866

[RGB ES]

2012/10/26 Ariel Constenla-Haile 

>
> Hi Ricardo,
>
> On Fri, Oct 26, 2012 at 08:24:26PM +0200, RGB ES wrote:
> > On the forums we are testing the ES version and I have a doubt about non
> > translated text on the UI: while there are some strings that comes from
> new
> > code (new functions on Calc) there are other strings that are identical
> to
> > the ones on 3.4.1... but on 3.5dev are not translated! For example, under
> > "Insertar" (Insert) there is an entry "Movie and Sound" that it is not
> > translated on 3.5  (on 3.4.1 says "Vídeo y sonido"). Is this something to
> > worry about or it is better to wait until 3.5 is on Pootle and everything
> > is correctly integrated?
>
> you can expect this with strings that are retrieved using the UNO
> command, the UNO command is what identifies every UI feature in the
> application
> framework; you can find them in the XML files that define menu bars and
> toolbars in the office installation, for example
>
> grep -r ".uno:InsertAVMedia" /opt/
> openoffice.org/basis3.4/share/config/soffice.cfg/modules/
>
> Labels for these commands are stored in configuration files. In this
> case, ".uno:InsertAVMedia" was moved to the right configuration place:
>
> * 3.4 branch, under Popups:
>
> http://opengrok.adfinis-sygroup.org/source/xref/aoo-AOO34/main/officecfg/registry/data/org/openoffice/Office/UI/GenericCommands.xcu#5352
>
> * trunk under Commands:
>
> http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/officecfg/registry/data/org/openoffice/Office/UI/GenericCommands.xcu#3075
>
> Strings that were moved to the right category will appear untranslated,
> because they are now in fact different strings.
> There were also several commands that had the same string but were
> placed in different configuration files, these were moved to
> GenericCommands.xcu, but you shouldn't note a difference here (only when
> translating: several duplicated strings will be removed in 3.5).
>
> So, yes, the Pootle server is in 3.4, the developer snapshots are in
> 3.5, you'll have to wait until Pootle gets in sync with trunk.
>

Perfectly clear. Thanks!

Regards
Ricardo



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

Re: [RELEASE]: new snapshot base don revision r1400866

[jan iversen]

Please allow a "side-question".

Can the UNO command also be used to identify where a string is used in the
UI framework and not only the source code where it is programmed ?

my problem is that I was told that it would be of high value to language QA
if the system could provide screenshots showing where a string was used.
But today I can relate a string to a source, and not to how I access/see it
in a running AOO.

I know I can build AOO to show the key identifiers which helps a lot, but
it still does not help to find the string.

Thanks for your help in advance.
Jan.


On 26 October 2012 21:16, Ariel Constenla-Haile  wrote:

>
> Hi Ricardo,
>
> On Fri, Oct 26, 2012 at 08:24:26PM +0200, RGB ES wrote:
> > On the forums we are testing the ES version and I have a doubt about non
> > translated text on the UI: while there are some strings that comes from
> new
> > code (new functions on Calc) there are other strings that are identical
> to
> > the ones on 3.4.1... but on 3.5dev are not translated! For example, under
> > "Insertar" (Insert) there is an entry "Movie and Sound" that it is not
> > translated on 3.5  (on 3.4.1 says "Vídeo y sonido"). Is this something to
> > worry about or it is better to wait until 3.5 is on Pootle and everything
> > is correctly integrated?
>
> you can expect this with strings that are retrieved using the UNO
> command, the UNO command is what identifies every UI feature in the
> application
> framework; you can find them in the XML files that define menu bars and
> toolbars in the office installation, for example
>
> grep -r ".uno:InsertAVMedia" /opt/
> openoffice.org/basis3.4/share/config/soffice.cfg/modules/
>
> Labels for these commands are stored in configuration files. In this
> case, ".uno:InsertAVMedia" was moved to the right configuration place:
>
> * 3.4 branch, under Popups:
>
> http://opengrok.adfinis-sygroup.org/source/xref/aoo-AOO34/main/officecfg/registry/data/org/openoffice/Office/UI/GenericCommands.xcu#5352
>
> * trunk under Commands:
>
> http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/officecfg/registry/data/org/openoffice/Office/UI/GenericCommands.xcu#3075
>
> Strings that were moved to the right category will appear untranslated,
> because they are now in fact different strings.
> There were also several commands that had the same string but were
> placed in different configuration files, these were moved to
> GenericCommands.xcu, but you shouldn't note a difference here (only when
> translating: several duplicated strings will be removed in 3.5).
>
> So, yes, the Pootle server is in 3.4, the developer snapshots are in
> 3.5, you'll have to wait until Pootle gets in sync with trunk.
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>

Re: [proposal] Outdated articles in Wiki

[jan iversen]

Thanks for clearing that up. I have just been searching for build
instructions (again), and in the search response I cannot see if an article
is outdated, so I had to open some before I got the correct one.

Would it be an idea (if possible) to have "outdated" as a category, and
extend the search to say with/without outdated, if possible that would work
fine for me since I would hit the recent one when searching.

regards
Jan.

On 26 October 2012 21:16, Keith N. McKenna wrote:

> Jan;
> {{Documentation/Outdated}} and {{delete}} are two seperate entities.
> Outdated merely says that some inormation is outdated and should be
> revised. {{delete}} is a special case that marks a file for speedy deletion
> by an wiki administrator.
>
> At least with the user documentation we tend to add to the document for
> newer versions of the software rather than get rid of it as there are still
> people using older versions. This can however get carried to extremes. My
> personal opinion is that it is probably  time to start seriously
> considering purging version 2.x stuff, but that is a discussion for another
> thread.
>
> Regards
> Keith
>
>
>
> jan iversen wrote:
>
>> So if an article is outdated, then it is ready for deletionor ???
>>
>> Is it wise to have outdated articles alongside the correct/newer ones,
>> thinking of e.g. building instructions it would at least confuse me.
>>
>> but I have no problem using {{Delete}} thanks for advicing me.
>>
>> jan.
>>
>> On 26 October 2012 19:03, Keith N. McKenna **
>> wrote:
>>
>>  Jan;
>>>
>>> No the outdated symbol is different. {{Delete}} Is a template that puts
>>> the article in a special category to be deleted by an admin or by a bot.
>>>
>>> Keith
>>>
>>>
>>> jan iversen wrote:
>>>
>>>  Do you mean the "outdated" symbol, which should do just fine ??

 Jan.

 On 26 October 2012 17:18, Jürgen Schmidt  wrote:

   On 10/25/12 9:19 PM, jan iversen wrote:

>
>  Maybe we could move them to an archive ??
>>
>>
> I think we can find probably common consensus that we want to delete
> pages to clean up this old stuff.
>
> For example nobody needs today the old building guides. Let us focus on
> the future and here I think less but correct and up-to-date information
> is more.
>
> When I remember correct there exist a template that could be used to
> mark a page for deletion.
>
> Simply put {{Delete}} on top of the page
>
> Or we can create our own delete template with further instructions how
> to proceed.
>
> Administrator can for this from time to time and can delete stuff. Or
> we
> can try to cleanup such pages via a wiki bot.
>
> Juergen
>
>
>
>  jan
>>
>> On 25 October 2012 21:12, Alexandro Colorado  wrote:
>>
>>   Nobody want to delete information and wiki pages only admin can
>>
>>> actually delete pages. Even then there might be some rights about
>>> ownership. Is like sourceforge dont delete inactive projects.
>>>
>>> Still good conversation to debate.
>>>
>>> On 10/25/12, jan iversen  wrote:
>>>
>>>  To my knowledge, articles that are marked outdated with a reference
 to

  a
>>>
>>
>  newer article stays in Wiki.
>>
>>>
 Would it not be a good idea to remove such pages, in order not to

  confuse
>>>
>>
>  users ??
>>
>>>
 There are however no means, which I can find, to do that ?

 Reason for my idea/question is that I am looking at localization

  (l10n),
>>>
>>
>  and there are a bit of old information.
>>
>>>
 Jan.



>>> --
>>> Alexandro Colorado
>>> PPMC Apache OpenOffice
>>> http://es.openoffice.org
>>>
>>>
>>>
>>
>
>

>>>
>>>
>>
>
>

Re: [proposal] Outdated articles in Wiki

[RGB ES]

2012/10/26 jan iversen 

> Thanks for clearing that up. I have just been searching for build
> instructions (again), and in the search response I cannot see if an article
> is outdated, so I had to open some before I got the correct one.
>
> Would it be an idea (if possible) to have "outdated" as a category, and
> extend the search to say with/without outdated, if possible that would work
> fine for me since I would hit the recent one when searching.
>

AFAIK, the "outdated" template also apply the outdated category:

http://wiki.openoffice.org/wiki/Category:Outdated

Regard
Ricardo



>
> regards
> Jan.
>
> On 26 October 2012 21:16, Keith N. McKenna  >wrote:
>
> > Jan;
> > {{Documentation/Outdated}} and {{delete}} are two seperate entities.
> > Outdated merely says that some inormation is outdated and should be
> > revised. {{delete}} is a special case that marks a file for speedy
> deletion
> > by an wiki administrator.
> >
> > At least with the user documentation we tend to add to the document for
> > newer versions of the software rather than get rid of it as there are
> still
> > people using older versions. This can however get carried to extremes. My
> > personal opinion is that it is probably  time to start seriously
> > considering purging version 2.x stuff, but that is a discussion for
> another
> > thread.
> >
> > Regards
> > Keith
> >
> >
> >
> > jan iversen wrote:
> >
> >> So if an article is outdated, then it is ready for deletionor ???
> >>
> >> Is it wise to have outdated articles alongside the correct/newer ones,
> >> thinking of e.g. building instructions it would at least confuse me.
> >>
> >> but I have no problem using {{Delete}} thanks for advicing me.
> >>
> >> jan.
> >>
> >> On 26 October 2012 19:03, Keith N. McKenna  >**
> >> wrote:
> >>
> >>  Jan;
> >>>
> >>> No the outdated symbol is different. {{Delete}} Is a template that puts
> >>> the article in a special category to be deleted by an admin or by a
> bot.
> >>>
> >>> Keith
> >>>
> >>>
> >>> jan iversen wrote:
> >>>
> >>>  Do you mean the "outdated" symbol, which should do just fine ??
> 
>  Jan.
> 
>  On 26 October 2012 17:18, Jürgen Schmidt 
> wrote:
> 
>    On 10/25/12 9:19 PM, jan iversen wrote:
> 
> >
> >  Maybe we could move them to an archive ??
> >>
> >>
> > I think we can find probably common consensus that we want to delete
> > pages to clean up this old stuff.
> >
> > For example nobody needs today the old building guides. Let us focus
> on
> > the future and here I think less but correct and up-to-date
> information
> > is more.
> >
> > When I remember correct there exist a template that could be used to
> > mark a page for deletion.
> >
> > Simply put {{Delete}} on top of the page
> >
> > Or we can create our own delete template with further instructions
> how
> > to proceed.
> >
> > Administrator can for this from time to time and can delete stuff. Or
> > we
> > can try to cleanup such pages via a wiki bot.
> >
> > Juergen
> >
> >
> >
> >  jan
> >>
> >> On 25 October 2012 21:12, Alexandro Colorado  wrote:
> >>
> >>   Nobody want to delete information and wiki pages only admin can
> >>
> >>> actually delete pages. Even then there might be some rights about
> >>> ownership. Is like sourceforge dont delete inactive projects.
> >>>
> >>> Still good conversation to debate.
> >>>
> >>> On 10/25/12, jan iversen  wrote:
> >>>
> >>>  To my knowledge, articles that are marked outdated with a
> reference
>  to
> 
>   a
> >>>
> >>
> >  newer article stays in Wiki.
> >>
> >>>
>  Would it not be a good idea to remove such pages, in order not to
> 
>   confuse
> >>>
> >>
> >  users ??
> >>
> >>>
>  There are however no means, which I can find, to do that ?
> 
>  Reason for my idea/question is that I am looking at localization
> 
>   (l10n),
> >>>
> >>
> >  and there are a bit of old information.
> >>
> >>>
>  Jan.
> 
> 
> 
> >>> --
> >>> Alexandro Colorado
> >>> PPMC Apache OpenOffice
> >>> http://es.openoffice.org
> >>>
> >>>
> >>>
> >>
> >
> >
> 
> >>>
> >>>
> >>
> >
> >
>

Re: [proposal] Outdated articles in Wiki

[jan iversen]

So it is "just" a matter of having a checkbox next to the the search (upper
corner) ?

but I assume the setup of wiki is INFRA and not something we control
locally, so a change is not very easy (or how to request such a change) ?

jan.

On 26 October 2012 21:36, RGB ES  wrote:

> 2012/10/26 jan iversen 
>
> > Thanks for clearing that up. I have just been searching for build
> > instructions (again), and in the search response I cannot see if an
> article
> > is outdated, so I had to open some before I got the correct one.
> >
> > Would it be an idea (if possible) to have "outdated" as a category, and
> > extend the search to say with/without outdated, if possible that would
> work
> > fine for me since I would hit the recent one when searching.
> >
>
> AFAIK, the "outdated" template also apply the outdated category:
>
> http://wiki.openoffice.org/wiki/Category:Outdated
>
> Regard
> Ricardo
>
>
>
> >
> > regards
> > Jan.
> >
> > On 26 October 2012 21:16, Keith N. McKenna  > >wrote:
> >
> > > Jan;
> > > {{Documentation/Outdated}} and {{delete}} are two seperate entities.
> > > Outdated merely says that some inormation is outdated and should be
> > > revised. {{delete}} is a special case that marks a file for speedy
> > deletion
> > > by an wiki administrator.
> > >
> > > At least with the user documentation we tend to add to the document for
> > > newer versions of the software rather than get rid of it as there are
> > still
> > > people using older versions. This can however get carried to extremes.
> My
> > > personal opinion is that it is probably  time to start seriously
> > > considering purging version 2.x stuff, but that is a discussion for
> > another
> > > thread.
> > >
> > > Regards
> > > Keith
> > >
> > >
> > >
> > > jan iversen wrote:
> > >
> > >> So if an article is outdated, then it is ready for deletionor ???
> > >>
> > >> Is it wise to have outdated articles alongside the correct/newer ones,
> > >> thinking of e.g. building instructions it would at least confuse me.
> > >>
> > >> but I have no problem using {{Delete}} thanks for advicing me.
> > >>
> > >> jan.
> > >>
> > >> On 26 October 2012 19:03, Keith N. McKenna  > >**
> > >> wrote:
> > >>
> > >>  Jan;
> > >>>
> > >>> No the outdated symbol is different. {{Delete}} Is a template that
> puts
> > >>> the article in a special category to be deleted by an admin or by a
> > bot.
> > >>>
> > >>> Keith
> > >>>
> > >>>
> > >>> jan iversen wrote:
> > >>>
> > >>>  Do you mean the "outdated" symbol, which should do just fine ??
> > 
> >  Jan.
> > 
> >  On 26 October 2012 17:18, Jürgen Schmidt 
> > wrote:
> > 
> >    On 10/25/12 9:19 PM, jan iversen wrote:
> > 
> > >
> > >  Maybe we could move them to an archive ??
> > >>
> > >>
> > > I think we can find probably common consensus that we want to
> delete
> > > pages to clean up this old stuff.
> > >
> > > For example nobody needs today the old building guides. Let us
> focus
> > on
> > > the future and here I think less but correct and up-to-date
> > information
> > > is more.
> > >
> > > When I remember correct there exist a template that could be used
> to
> > > mark a page for deletion.
> > >
> > > Simply put {{Delete}} on top of the page
> > >
> > > Or we can create our own delete template with further instructions
> > how
> > > to proceed.
> > >
> > > Administrator can for this from time to time and can delete stuff.
> Or
> > > we
> > > can try to cleanup such pages via a wiki bot.
> > >
> > > Juergen
> > >
> > >
> > >
> > >  jan
> > >>
> > >> On 25 October 2012 21:12, Alexandro Colorado 
> wrote:
> > >>
> > >>   Nobody want to delete information and wiki pages only admin can
> > >>
> > >>> actually delete pages. Even then there might be some rights about
> > >>> ownership. Is like sourceforge dont delete inactive projects.
> > >>>
> > >>> Still good conversation to debate.
> > >>>
> > >>> On 10/25/12, jan iversen  wrote:
> > >>>
> > >>>  To my knowledge, articles that are marked outdated with a
> > reference
> >  to
> > 
> >   a
> > >>>
> > >>
> > >  newer article stays in Wiki.
> > >>
> > >>>
> >  Would it not be a good idea to remove such pages, in order not
> to
> > 
> >   confuse
> > >>>
> > >>
> > >  users ??
> > >>
> > >>>
> >  There are however no means, which I can find, to do that ?
> > 
> >  Reason for my idea/question is that I am looking at localization
> > 
> >   (l10n),
> > >>>
> > >>
> > >  and there are a bit of old information.
> > >>
> > >>>
> >  Jan.
> > 
> > 
> > 
> > >>> --
> > >>> Alexandro Colorado
> > >>> PPMC Apache OpenOffice
> > >>> http://es.openoffice.org
> > >>>
> > >

Re: [proposal] Outdated articles in Wiki

[Keith N. McKenna]

Thanks or that Ricardo, I had forgotten that outdated also assigned the 
category.


Regards
Keith

RGB ES wrote:

2012/10/26 jan iversen 


Thanks for clearing that up. I have just been searching for build
instructions (again), and in the search response I cannot see if an article
is outdated, so I had to open some before I got the correct one.

Would it be an idea (if possible) to have "outdated" as a category, and
extend the search to say with/without outdated, if possible that would work
fine for me since I would hit the recent one when searching.



AFAIK, the "outdated" template also apply the outdated category:

http://wiki.openoffice.org/wiki/Category:Outdated

Regard
Ricardo





regards
Jan.

On 26 October 2012 21:16, Keith N. McKenna 
wrote:



Jan;
{{Documentation/Outdated}} and {{delete}} are two seperate entities.
Outdated merely says that some inormation is outdated and should be
revised. {{delete}} is a special case that marks a file for speedy

deletion

by an wiki administrator.

At least with the user documentation we tend to add to the document for
newer versions of the software rather than get rid of it as there are

still

people using older versions. This can however get carried to extremes. My
personal opinion is that it is probably  time to start seriously
considering purging version 2.x stuff, but that is a discussion for

another

thread.

Regards
Keith



jan iversen wrote:


So if an article is outdated, then it is ready for deletionor ???

Is it wise to have outdated articles alongside the correct/newer ones,
thinking of e.g. building instructions it would at least confuse me.

but I have no problem using {{Delete}} thanks for advicing me.

jan.

On 26 October 2012 19:03, Keith N. McKenna 
**

wrote:

  Jan;


No the outdated symbol is different. {{Delete}} Is a template that puts
the article in a special category to be deleted by an admin or by a

bot.


Keith


jan iversen wrote:

  Do you mean the "outdated" symbol, which should do just fine ??


Jan.

On 26 October 2012 17:18, Jürgen Schmidt 

wrote:


   On 10/25/12 9:19 PM, jan iversen wrote:



  Maybe we could move them to an archive ??




I think we can find probably common consensus that we want to delete
pages to clean up this old stuff.

For example nobody needs today the old building guides. Let us focus

on

the future and here I think less but correct and up-to-date

information

is more.

When I remember correct there exist a template that could be used to
mark a page for deletion.

Simply put {{Delete}} on top of the page

Or we can create our own delete template with further instructions

how

to proceed.

Administrator can for this from time to time and can delete stuff. Or
we
can try to cleanup such pages via a wiki bot.

Juergen



  jan


On 25 October 2012 21:12, Alexandro Colorado  wrote:

   Nobody want to delete information and wiki pages only admin can


actually delete pages. Even then there might be some rights about
ownership. Is like sourceforge dont delete inactive projects.

Still good conversation to debate.

On 10/25/12, jan iversen  wrote:

  To my knowledge, articles that are marked outdated with a

reference

to

  a





  newer article stays in Wiki.





Would it not be a good idea to remove such pages, in order not to

  confuse





  users ??





There are however no means, which I can find, to do that ?

Reason for my idea/question is that I am looking at localization

  (l10n),





  and there are a bit of old information.





Jan.




--
Alexandro Colorado
PPMC Apache OpenOffice
http://es.openoffice.org

Re: svn commit: r1402586 - /incubator/ooo/site/trunk/content/openofficeorg/pmc-faqs.mdtext

[Kay Schenk]

On 10/26/2012 10:28 AM, Dave Fisher wrote:

I have access to the current list and will make the full update by early next 
week.


that would be great!



Sent from my iPhone

On Oct 26, 2012, at 10:19 AM, b...@apache.org wrote:


Author: bmcs
Date: Fri Oct 26 17:19:31 2012
New Revision: 1402586

URL: http://svn.apache.org/viewvc?rev=1402586&view=rev
Log:
Updated moderators

Modified:
incubator/ooo/site/trunk/content/openofficeorg/pmc-faqs.mdtext

Modified: incubator/ooo/site/trunk/content/openofficeorg/pmc-faqs.mdtext
URL: 
http://svn.apache.org/viewvc/incubator/ooo/site/trunk/content/openofficeorg/pmc-faqs.mdtext?rev=1402586&r1=1402585&r2=1402586&view=diff
==
--- incubator/ooo/site/trunk/content/openofficeorg/pmc-faqs.mdtext (original)
+++ incubator/ooo/site/trunk/content/openofficeorg/pmc-faqs.mdtext Fri Oct 26 
17:19:31 2012
@@ -40,10 +40,10 @@ contact first, before escalating to Apac

Each mailing list has one or more moderators.

-  - ooo-dev moderators are Rob Weir,
-  - ooo-users moderators are Rob Weir, Simon Phipps,
+  - ooo-dev moderators are Rob Weir, Dave Barton
+  - ooo-users moderators are Rob Weir, Simon Phipps, Dave Barton
   - ooo-qa moderators are Rob Weir,
-  - ooo-marketing moderators are Rob Weir,
+  - ooo-marketing moderators are Rob Weir, Dave Barton
   - ooo-private (restricted access) moderators are Rob Weir,
   - ooo-security (restricted access)with Rob Weir, Dennis Hamilton, Wolf Halton
and Juergen Schmidt as members.  New members can be added by consensus of the 
PMC




--

MzK

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

Re: svn commit: r1402586 - /incubator/ooo/site/trunk/content/openofficeorg/pmc-faqs.mdtext

[Dave Barton]

Is this the same list per your email Sept 23
https://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201209.mbox/%3CD3A520E4-AD53-43D6-9E3B-43CA10E6D54A%40comcast.net%3E
If there haven't been any other changes since then I would be happy to
make the update.

 Original Message  
From: Dave Fisher 
To: ooo-dev@incubator.apache.org 
Date: Fri, 26 Oct 2012 10:28:49 -0700

> I have access to the current list and will make the full update by early next 
> week.
> 
> Sent from my iPhone
> 
> On Oct 26, 2012, at 10:19 AM, b...@apache.org wrote:
> 
>> Author: bmcs
>> Date: Fri Oct 26 17:19:31 2012
>> New Revision: 1402586
>>
>> URL: http://svn.apache.org/viewvc?rev=1402586&view=rev
>> Log:
>> Updated moderators
>>
>> Modified:
>>incubator/ooo/site/trunk/content/openofficeorg/pmc-faqs.mdtext
>>
>> Modified: incubator/ooo/site/trunk/content/openofficeorg/pmc-faqs.mdtext
>> URL: 
>> http://svn.apache.org/viewvc/incubator/ooo/site/trunk/content/openofficeorg/pmc-faqs.mdtext?rev=1402586&r1=1402585&r2=1402586&view=diff
>> ==
>> --- incubator/ooo/site/trunk/content/openofficeorg/pmc-faqs.mdtext (original)
>> +++ incubator/ooo/site/trunk/content/openofficeorg/pmc-faqs.mdtext Fri Oct 
>> 26 17:19:31 2012
>> @@ -40,10 +40,10 @@ contact first, before escalating to Apac
>>
>> Each mailing list has one or more moderators.  
>>
>> -  - ooo-dev moderators are Rob Weir,
>> -  - ooo-users moderators are Rob Weir, Simon Phipps, 
>> +  - ooo-dev moderators are Rob Weir, Dave Barton
>> +  - ooo-users moderators are Rob Weir, Simon Phipps, Dave Barton
>>   - ooo-qa moderators are Rob Weir,
>> -  - ooo-marketing moderators are Rob Weir,
>> +  - ooo-marketing moderators are Rob Weir, Dave Barton
>>   - ooo-private (restricted access) moderators are Rob Weir,
>>   - ooo-security (restricted access)with Rob Weir, Dennis Hamilton, Wolf 
>> Halton 
>> and Juergen Schmidt as members.  New members can be added by consensus of 
>> the PMC
>>
>>
> 
> 

Re: [RELEASE] Releasing new languages for 3.4.1

[Marcus (OOo)]

Am 10/26/2012 07:43 PM, schrieb Andrea Pescetti:

Rob Weir wrote:

1) release new languages via lang packs only for now
2) release full installs, but for only these new languages


I don't see a big difference between a langpack and a full install in
this case, so I'd go for full installs, unless releasing langpacks helps
in communicating that these are "late" additions and that full installs
will come with the next release.


Can we really skip the release process? PO files == source, right?


Yes, not exactly but quite (PO files are not taken verbatim into source,
but they are imported and influence resource files which are in the
source tree).


Maybe a question for legal-discuss if we're not certain.


If in the end we have consensus on releasing new languages for 3.4.1
instead of making a new release, indeed we will ask.


How do we want to handle this on an ongoing basis? New point release
for every new language? Every 5 new languages? It is certainly good
for volunteers to get the encouragement of a fast turnaround for their
work. But this is the same for a C++ programmer.


There are big differences here, that are also the reason for me to
consider releasing these new languages as soon as possible:
- A translation is often done by a team; if we can publish it
immediately, the team can the be involved in other activities like
revamping the N-L website, local promotion and so on; if we wait too
much, we risk to have no volunteers for the following release.


Really? I'm not that convinced that this would happen. When we 
communicate from the beginning when new loalizations will be released 
then everybody should be able to understand and handle this.



- 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.


Besides the comment from Jan I remember a case from the old OOo project. 
There were some translations for the names of Calc functions that got 
the same name but had to get (slightly) different names. The result was 
that there were 2-3 sum, 2-3 average, etc. functions. This was also - 
more or less the only - reason for another respin for a OOo RC; 3.2.1, 
3.3.0, I don't remember anymore.


So, the risk of new languages may not be high but I wouldn't say it's 
totally risk-free.



In the end, I wonder whether the best solution is to get into a steady
release cycle of quarterly releases (every 3 or 4 months)?


+1

IMHO a regular release schedule is a very good idea. Then everybody can 
cope with this, can see when the next version will come and we can plan 
with a regular release plan (when to branch, freeze, localize, etc.).


Of course the timeframe will need some discussions to find the right one.

Previously it was tried to release every 6 months a new major release 
and every 6 months a point release. So, with overlapping there was a new 
release every 3 month. Maybe a good timeframe to continue?



This could be a solution too. In this case we would have the problem of
choosing what to translate (3.4 or 3.5? probably we would ask new
volunteers to focus on strings that will be in the next release, even
though they aren't frozen yet).


In any case we should continue to release new languages; regardless if 
major or point versions.


Marcus

[DISCUSS] Cleanup installation files, make them more modular

[Marcus (OOo)]

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


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.


Example:
For every platform, we have exactly the same files in every full 
install, except for the language resource files. So, when we can make it 
that only the core (languages-independent) files are once on the mirrors 
and then the language resource files besides, then it would be possible 
to do the installation process completely new - with the following rough 
steps:


1. Create a new basis installer: little, tiny and already localized.
2. The user can choose what he wants: applications, languages, 
templates, extensions.

3. The basis installer downloads this file set from the mirrors.
4. It does the installation on the PC.
5. Finally AOO is ready to use.

And as goody maybe it's possible to create an install file, so that the 
user can re-install his AOO version whenever he wants, without to 
download everything again from the mirrors.


Marcus

The Impossible Question

[Louis Suárez-Potts]

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?

Thanks
Louis

Re: [RELEASE] Releasing new languages for 3.4.1

[jan iversen]

On 26 October 2012 23:06, Marcus (OOo)  wrote:

> Am 10/26/2012 07:43 PM, schrieb Andrea Pescetti:
>
>  Rob Weir wrote:
>>
>>> 1) release new languages via lang packs only for now
>>> 2) release full installs, but for only these new languages
>>>
>>
>> I don't see a big difference between a langpack and a full install in
>> this case, so I'd go for full installs, unless releasing langpacks helps
>> in communicating that these are "late" additions and that full installs
>> will come with the next release.
>>
>>  Can we really skip the release process? PO files == source, right?
>>>
>>
>> Yes, not exactly but quite (PO files are not taken verbatim into source,
>> but they are imported and influence resource files which are in the
>> source tree).
>>
>>  Maybe a question for legal-discuss if we're not certain.
>>>
>>
>> If in the end we have consensus on releasing new languages for 3.4.1
>> instead of making a new release, indeed we will ask.
>>
>>  How do we want to handle this on an ongoing basis? New point release
>>> for every new language? Every 5 new languages? It is certainly good
>>> for volunteers to get the encouragement of a fast turnaround for their
>>> work. But this is the same for a C++ programmer.
>>>
>>
>> There are big differences here, that are also the reason for me to
>> consider releasing these new languages as soon as possible:
>> - A translation is often done by a team; if we can publish it
>> immediately, the team can the be involved in other activities like
>> revamping the N-L website, local promotion and so on; if we wait too
>> much, we risk to have no volunteers for the following release.
>>
>
> Really? I'm not that convinced that this would happen. When we communicate
> from the beginning when new loalizations will be released then everybody
> should be able to understand and handle this.
>
>
>  - 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.
>>
>
> Besides the comment from Jan I remember a case from the old OOo project.
> There were some translations for the names of Calc functions that got the
> same name but had to get (slightly) different names. The result was that
> there were 2-3 sum, 2-3 average, etc. functions. This was also - more or
> less the only - reason for another respin for a OOo RC; 3.2.1, 3.3.0, I
> don't remember anymore.
>
> So, the risk of new languages may not be high but I wouldn't say it's
> totally risk-free.
>
>
>  In the end, I wonder whether the best solution is to get into a steady
>>> release cycle of quarterly releases (every 3 or 4 months)?
>>>
>>
> +1
>
> IMHO a regular release schedule is a very good idea. Then everybody can
> cope with this, can see when the next version will come and we can plan
> with a regular release plan (when to branch, freeze, localize, etc.).
>
> Of course the timeframe will need some discussions to find the right one.
>
> Previously it was tried to release every 6 months a new major release and
> every 6 months a point release. So, with overlapping there was a new
> release every 3 month. Maybe a good timeframe to continue?

+1 to a relatively fixed time frame for new releases. Not only developers
benefit from that but also end-users !

However do we have the logistic in place to handle ideas/request/bug fixes
with these short intervals. It would mean (in my opinion) that we have an
open catalog (new development) for 2-3 releases and have to prioritize
within a limited timeframe what goes where ? We should also consider to
apply a field in bugzilla, "targeted for version".

I really like the idea, but it has a tendency of killing long term
developments, because they are hard to put into this framework, so we need
something in the middle.


>
>  This could be a solution too. In this case we would have the problem of
>> choosing what to translate (3.4 or 3.5? probably we would ask new
>> volunteers to focus on strings that will be in the next release, even
>> though they aren't frozen yet).
>>
>
> In any case we should continue to release new languages; regardless if
> major or point versions.
>
> Marcus
>

Re: The Impossible Question

[Rob Weir]

On Fri, Oct 26, 2012 at 5: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?
>

I can't think of anything less confusing than a prominent link on our
home page saying "I need help with my OpenOffice".

The "befuddled" users who end up in other places might in some cases
be crazy like a fox.  They know the tricks to get one-on-one
attention. They are the ones who know how to press *0 on the phone to
get a real human.  They know the secret support number for Amazon
customer service, etc.

That said, it might make sense to give new users some tips and do this
repeatedly, since a since mention will not sink in.   We have a few
opportunities:

1) While downloading

2) While installing

3) Immediately after installing

4) A "start up tips" dialog that could display a new tip every day or week

5) A "new user" email autoresponder that users could sign up for to
get a helpful tips for their first X weeks using AOO.

6) Similar information sent to announce list

7) Maybe make the FAQ's directly linked from the home page

Obviously one of the hints could include a hint about support.

Of course, the real question, Louis, is what do *you* want to do?

-Rob

> Thanks
> Louis
>

Re: The Impossible Question

[jan iversen]

Just an idea, which once helped me.

Typically users dont think things will go wrong so they dont pay attention
to whatever we write, but one apache project had a quite clever solution
(if I remember right it was Axis, but dont depend on my memory), when the
installation failed it did not just tell you failed, it came up with the
link to FAQ, right when the user needed it, simple but very effective.

jan.

On 26 October 2012 23:06, 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?
>
> Thanks
> Louis
>
>

Re: [PROPOSAL] "difficulty" field for Bugzilla

[Kay Schenk]

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?


>
>> -Andre
>>

-- 

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-26, at 17:25 , Rob Weir  wrote:

> Of course, the real question, Louis, is what do *you* want to do?

Be cynical, or I mean, more cynical.

Seriously, I have the same objections and observations as you do but I've also 
spent 11 years dealing with people who don't. No one thing will work. That's 
why I suggest multiple redundancies, and to place the instances alerting users 
of opportunities in key areas—the download, for instance (where we also used to 
locate contribution options), but also the Help, About, etc. But what's usually 
best is to follow what others have done, and to figure that the path has been 
torched, it's the one that will be followed, so let's use it.

As I don't use MSFT Office and the last time I did found myself deep in the sea 
of thick frustration, I'm the last person to ask about this.

louis

Re: The Impossible Question

[Jörg Schmidt]

Hello, 

> -Original Message-
> From: Louis Suárez-Potts [mailto:lui...@gmail.com] On Behalf 

> Ideas?

What do you mean? Better design or more/better content?

If you feel content, maybe even local resources would be useful. For example, I 
am
since over 8 years moderator in the largest German speaking forum (for OOo / 
AOO /
LO):
 http://de.openoffice.info

(Notice: my nickname in this forum is "Stephan")



Greetings,

Jörg

Re: [RELEASE] Releasing new languages for 3.4.1

[Rob Weir]

On Fri, Oct 26, 2012 at 5:06 PM, Marcus (OOo)  wrote:
> Am 10/26/2012 07:43 PM, schrieb Andrea Pescetti:
>
>> Rob Weir wrote:
>>>
>>> 1) release new languages via lang packs only for now
>>> 2) release full installs, but for only these new languages
>>
>>
>> I don't see a big difference between a langpack and a full install in
>> this case, so I'd go for full installs, unless releasing langpacks helps
>> in communicating that these are "late" additions and that full installs
>> will come with the next release.
>>
>>> Can we really skip the release process? PO files == source, right?
>>
>>
>> Yes, not exactly but quite (PO files are not taken verbatim into source,
>> but they are imported and influence resource files which are in the
>> source tree).
>>
>>> Maybe a question for legal-discuss if we're not certain.
>>
>>
>> If in the end we have consensus on releasing new languages for 3.4.1
>> instead of making a new release, indeed we will ask.
>>
>>> How do we want to handle this on an ongoing basis? New point release
>>> for every new language? Every 5 new languages? It is certainly good
>>> for volunteers to get the encouragement of a fast turnaround for their
>>> work. But this is the same for a C++ programmer.
>>
>>
>> There are big differences here, that are also the reason for me to
>> consider releasing these new languages as soon as possible:
>> - A translation is often done by a team; if we can publish it
>> immediately, the team can the be involved in other activities like
>> revamping the N-L website, local promotion and so on; if we wait too
>> much, we risk to have no volunteers for the following release.
>
>
> Really? I'm not that convinced that this would happen. When we communicate
> from the beginning when new loalizations will be released then everybody
> should be able to understand and handle this.
>
>
>> - 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.
>
>
> Besides the comment from Jan I remember a case from the old OOo project.
> There were some translations for the names of Calc functions that got the
> same name but had to get (slightly) different names. The result was that
> there were 2-3 sum, 2-3 average, etc. functions. This was also - more or
> less the only - reason for another respin for a OOo RC; 3.2.1, 3.3.0, I
> don't remember anymore.
>
> So, the risk of new languages may not be high but I wouldn't say it's
> totally risk-free.
>

Certainly the risk is reduced.  But there are two areas:

1) Risk of defects caused by interaction between the core product and
the translated strings

2) Risk of a "bad build", for whatever reason, say due to change in a
system library, leading to an undetected new defect.

>
>>> In the end, I wonder whether the best solution is to get into a steady
>>> release cycle of quarterly releases (every 3 or 4 months)?
>
>
> +1
>
> IMHO a regular release schedule is a very good idea. Then everybody can cope
> with this, can see when the next version will come and we can plan with a
> regular release plan (when to branch, freeze, localize, etc.).
>
> Of course the timeframe will need some discussions to find the right one.
>
> Previously it was tried to release every 6 months a new major release and
> every 6 months a point release. So, with overlapping there was a new release
> every 3 month. Maybe a good timeframe to continue?
>

Did you do betas for all releases?  Or only major ones?  Or was this a
case-by-case decision?

We have the ability to do betas if we want.  From an Apache
perspective they would still be releases, but we could set the right
expectations with users.  For example, we wouldn't send update
notifications for beta releases.

>
>> This could be a solution too. In this case we would have the problem of
>> choosing what to translate (3.4 or 3.5? probably we would ask new
>> volunteers to focus on strings that will be in the next release, even
>> though they aren't frozen yet).
>
>
> In any case we should continue to release new languages; regardless if major
> or point versions.
>
> Marcus

Re: The Impossible Question

[Louis Suárez-Potts]

On 12-10-26, at 17:33 , Jörg Schmidt  wrote:

> Hello, 
> 
>> -Original Message-
>> From: Louis Suárez-Potts [mailto:lui...@gmail.com] On Behalf 
> 
>> Ideas?
> 
> What do you mean? Better design or more/better content?
> 
> If you feel content, maybe even local resources would be useful. For example, 
> I am
> since over 8 years moderator in the largest German speaking forum (for OOo / 
> AOO /
> LO):
> http://de.openoffice.info
> 
> (Notice: my nickname in this forum is "Stephan")
> 

hI stephan!
I don't mean anything specific. I don't think there is a simple solution—hence 
my subject line. I do think that there are multiple imperfect solutions, kind 
of like language if not math or code. 

But I think that it's worth appreciating that there is a problem for some (not 
all!) users and that having an approach that reads the user, however singular, 
as important, is good for us. See, I also see it as part of a campaign to 
differentiate, to characterize AOO as that set of tools that is best for all 
users, regardless of background, language, ability.

best
louis

> 
> 
> Greetings,
> 
> Jörg
> 

Re: [RELEASE] Releasing new languages for 3.4.1

[Marcus (OOo)]

Am 10/26/2012 11:20 PM, schrieb jan iversen:

On 26 October 2012 23:06, Marcus (OOo)  wrote:


Am 10/26/2012 07:43 PM, schrieb Andrea Pescetti:

  Rob Weir wrote:



1) release new languages via lang packs only for now
2) release full installs, but for only these new languages



I don't see a big difference between a langpack and a full install in
this case, so I'd go for full installs, unless releasing langpacks helps
in communicating that these are "late" additions and that full installs
will come with the next release.

  Can we really skip the release process? PO files == source, right?




Yes, not exactly but quite (PO files are not taken verbatim into source,
but they are imported and influence resource files which are in the
source tree).

  Maybe a question for legal-discuss if we're not certain.




If in the end we have consensus on releasing new languages for 3.4.1
instead of making a new release, indeed we will ask.

  How do we want to handle this on an ongoing basis? New point release

for every new language? Every 5 new languages? It is certainly good
for volunteers to get the encouragement of a fast turnaround for their
work. But this is the same for a C++ programmer.



There are big differences here, that are also the reason for me to
consider releasing these new languages as soon as possible:
- A translation is often done by a team; if we can publish it
immediately, the team can the be involved in other activities like
revamping the N-L website, local promotion and so on; if we wait too
much, we risk to have no volunteers for the following release.



Really? I'm not that convinced that this would happen. When we communicate
from the beginning when new loalizations will be released then everybody
should be able to understand and handle this.


  - 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.



Besides the comment from Jan I remember a case from the old OOo project.
There were some translations for the names of Calc functions that got the
same name but had to get (slightly) different names. The result was that
there were 2-3 sum, 2-3 average, etc. functions. This was also - more or
less the only - reason for another respin for a OOo RC; 3.2.1, 3.3.0, I
don't remember anymore.

So, the risk of new languages may not be high but I wouldn't say it's
totally risk-free.


  In the end, I wonder whether the best solution is to get into a steady

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




+1

IMHO a regular release schedule is a very good idea. Then everybody can
cope with this, can see when the next version will come and we can plan
with a regular release plan (when to branch, freeze, localize, etc.).

Of course the timeframe will need some discussions to find the right one.

Previously it was tried to release every 6 months a new major release and
every 6 months a point release. So, with overlapping there was a new
release every 3 month. Maybe a good timeframe to continue?


+1 to a relatively fixed time frame for new releases. Not only developers
benefit from that but also end-users !


Right


However do we have the logistic in place to handle ideas/request/bug fixes
with these short intervals. It would mean (in my opinion) that we have an


OK, maybe the following fitts better to our current situation. Every 6 
months a new major release and a point release on demand - enough new 
languages, urgent/severe bugfixes; that means outside a regular release 
plan.



open catalog (new development) for 2-3 releases and have to prioritize
within a limited timeframe what goes where ? We should also consider to
apply a field in bugzilla, "targeted for version".


That's already existing. Just look for the "Target Milestone" field.


I really like the idea, but it has a tendency of killing long term
developments, because they are hard to put into this framework, so we need
something in the middle.


When we plan which new and planned feature goes into what release should 
work.


Marcus




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

choosing what to translate (3.4 or 3.5? probably we would ask new
volunteers to focus on strings that will be in the next release, even
though they aren't frozen yet).



In any case we should continue to release new languages; regardless if
major or point versions.

Marcus

Re: The Impossible Question

[Kay Schenk]

On Fri, Oct 26, 2012 at 2:30 PM, Louis Suárez-Potts wrote:

>
> On 12-10-26, at 17:25 , Rob Weir  wrote:
>
> > Of course, the real question, Louis, is what do *you* want to do?
>
> Be cynical, or I mean, more cynical.
>
> Seriously, I have the same objections and observations as you do but I've
> also spent 11 years dealing with people who don't. No one thing will work.
> That's why I suggest multiple redundancies, and to place the instances
> alerting users of opportunities in key areas—the download, for instance
> (where we also used to locate contribution options), but also the Help,
> About, etc. But what's usually best is to follow what others have done, and
> to figure that the path has been torched, it's the one that will be
> followed, so let's use it.
>

Louis--

I see "Support" on the home page as it's own major link; "Support" as a tab
available from all pages; and "Support" (probably not best placed) on the
download page in Documentation. We could certainly move this to "Additional
Information" or its own category placement.

If you feel something additional might help, it would be best to state some
specific navigation areas or 


> As I don't use MSFT Office and the last time I did found myself deep in
> the sea of thick frustration, I'm the last person to ask about this.
>
> louis




-- 

MzK

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

Re: The Impossible Question

[Marcus (OOo)]

Am 10/26/2012 11:25 PM, schrieb jan iversen:

Just an idea, which once helped me.

Typically users dont think things will go wrong so they dont pay attention
to whatever we write, but one apache project had a quite clever solution


And when they remember that there was a banner talking about "How to get 
help in case of problems", hm, how to get this information back; as the 
user has of course not wrote it up.



(if I remember right it was Axis, but dont depend on my memory), when the
installation failed it did not just tell you failed, it came up with the
link to FAQ, right when the user needed it, simple but very effective.


That is good with problems while installing. However, when the install 
was fine but AOO is crashing every 5 seconds after every start is 
different. Even a link to the support webpage in the "Help" menu is not 
really helping the user.


OK, maybe an extrem case. ;-)

Marcus




On 26 October 2012 23:06, 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?

Thanks
Louis

Re: The Impossible Question

[Louis Suárez-Potts]

On 12-10-26, at 17:38 , Kay Schenk  wrote:

> On Fri, Oct 26, 2012 at 2:30 PM, Louis Suárez-Potts wrote:
> 
>> 
>> On 12-10-26, at 17:25 , Rob Weir  wrote:
>> 
>>> Of course, the real question, Louis, is what do *you* want to do?
>> 
>> Be cynical, or I mean, more cynical.
>> 
>> Seriously, I have the same objections and observations as you do but I've
>> also spent 11 years dealing with people who don't. No one thing will work.
>> That's why I suggest multiple redundancies, and to place the instances
>> alerting users of opportunities in key areas—the download, for instance
>> (where we also used to locate contribution options), but also the Help,
>> About, etc. But what's usually best is to follow what others have done, and
>> to figure that the path has been torched, it's the one that will be
>> followed, so let's use it.
>> 
> 
> Louis--
> 
> I see "Support" on the home page as it's own major link; "Support" as a tab
> available from all pages; and "Support" (probably not best placed) on the
> download page in Documentation. We could certainly move this to "Additional
> Information" or its own category placement.
> 
> If you feel something additional might help, it would be best to state some
> specific navigation areas or 

I see it too; and that was implicit in my initial point. My brief is that 
nothing will in and of itself work perfectly but that a multiple of approaches 
will probably work better than a single one, at least for users. You ought to 
know this: we went through this very discussion more than once with OpenOffice, 
and a resolution of it was the homepage we ended up with.

Kay, I'm not criticizing or deprecating the effort or the page we have now. Is 
that clear? I am rather alerting us to the fax that it's not perfect—but then 
nothing is. This is a persistent issue. Some solutions will work better than 
others but none is perfect. But, that does not mean we ought not to experiment 
with options.

Louis
> 
> 
>> As I don't use MSFT Office and the last time I did found myself deep in
>> the sea of thick frustration, I'm the last person to ask about this.
>> 
>> louis
> 
> 
> 
> 
> -- 
> 
> MzK
> 
> "Anyone who considers protocol unimportant has never
> dealt  with a cat."
>-- Robert Heinlein

Re: [RELEASE] Releasing new languages for 3.4.1

[jan iversen]

On 26 October 2012 23:38, Marcus (OOo)  wrote:

> Am 10/26/2012 11:20 PM, schrieb jan iversen:
>
>  On 26 October 2012 23:06, Marcus (OOo)  wrote:
>>
>>  Am 10/26/2012 07:43 PM, schrieb Andrea Pescetti:
>>>
>>>   Rob Weir wrote:
>>>

  1) release new languages via lang packs only for now
> 2) release full installs, but for only these new languages
>
>
 I don't see a big difference between a langpack and a full install in
 this case, so I'd go for full installs, unless releasing langpacks helps
 in communicating that these are "late" additions and that full installs
 will come with the next release.

   Can we really skip the release process? PO files == source, right?

>
>
 Yes, not exactly but quite (PO files are not taken verbatim into source,
 but they are imported and influence resource files which are in the
 source tree).

   Maybe a question for legal-discuss if we're not certain.

>
>
 If in the end we have consensus on releasing new languages for 3.4.1
 instead of making a new release, indeed we will ask.

   How do we want to handle this on an ongoing basis? New point release

> for every new language? Every 5 new languages? It is certainly good
> for volunteers to get the encouragement of a fast turnaround for their
> work. But this is the same for a C++ programmer.
>
>
 There are big differences here, that are also the reason for me to
 consider releasing these new languages as soon as possible:
 - A translation is often done by a team; if we can publish it
 immediately, the team can the be involved in other activities like
 revamping the N-L website, local promotion and so on; if we wait too
 much, we risk to have no volunteers for the following release.


>>> Really? I'm not that convinced that this would happen. When we
>>> communicate
>>> from the beginning when new loalizations will be released then everybody
>>> should be able to understand and handle this.
>>>
>>>
>>>   - 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.


>>> Besides the comment from Jan I remember a case from the old OOo project.
>>> There were some translations for the names of Calc functions that got the
>>> same name but had to get (slightly) different names. The result was that
>>> there were 2-3 sum, 2-3 average, etc. functions. This was also - more or
>>> less the only - reason for another respin for a OOo RC; 3.2.1, 3.3.0, I
>>> don't remember anymore.
>>>
>>> So, the risk of new languages may not be high but I wouldn't say it's
>>> totally risk-free.
>>>
>>>
>>>   In the end, I wonder whether the best solution is to get into a steady
>>>
 release cycle of quarterly releases (every 3 or 4 months)?
>
>
  +1
>>>
>>> IMHO a regular release schedule is a very good idea. Then everybody can
>>> cope with this, can see when the next version will come and we can plan
>>> with a regular release plan (when to branch, freeze, localize, etc.).
>>>
>>> Of course the timeframe will need some discussions to find the right one.
>>>
>>> Previously it was tried to release every 6 months a new major release and
>>> every 6 months a point release. So, with overlapping there was a new
>>> release every 3 month. Maybe a good timeframe to continue?
>>>
>>
>> +1 to a relatively fixed time frame for new releases. Not only developers
>> benefit from that but also end-users !
>>
>
> Right
>
>
>  However do we have the logistic in place to handle ideas/request/bug fixes
>> with these short intervals. It would mean (in my opinion) that we have an
>>
>
> OK, maybe the following fitts better to our current situation. Every 6
> months a new major release and a point release on demand - enough new
> languages, urgent/severe bugfixes; that means outside a regular release
> plan.

+1

>
>
>  open catalog (new development) for 2-3 releases and have to prioritize
>> within a limited timeframe what goes where ? We should also consider to
>> apply a field in bugzilla, "targeted for version".
>>
>
> That's already existing. Just look for the "Target Milestone" field.

I think it is not really used (I might be wrong) but with frequent releases
we should use it intensively, because today those who submit a bug must be
pretty disappointed, I looked at a bug the other day, dated 2007 which are
still a bug.

>
>
>  I really like the idea, but it has a tendency of killing long term
>> developments, because they are hard to put into this framework, so we need
>> something in the middle.
>>
>
> When we plan which new and planned feature goes into what release should
> work.
>
I think I did not express it correctly, resources tend to be used for short
term targets (next release, high motivation, lets make it folks, and after
that we do all the res

Re: The Impossible Question

[Marcus (OOo)]

Am 10/26/2012 11:38 PM, schrieb Kay Schenk:

On Fri, Oct 26, 2012 at 2:30 PM, Louis Suárez-Pottswrote:



On 12-10-26, at 17:25 , Rob Weir  wrote:


Of course, the real question, Louis, is what do *you* want to do?


Be cynical, or I mean, more cynical.

Seriously, I have the same objections and observations as you do but I've
also spent 11 years dealing with people who don't. No one thing will work.
That's why I suggest multiple redundancies, and to place the instances
alerting users of opportunities in key areas—the download, for instance
(where we also used to locate contribution options), but also the Help,
About, etc. But what's usually best is to follow what others have done, and
to figure that the path has been torched, it's the one that will be
followed, so let's use it.



Louis--

I see "Support" on the home page as it's own major link; "Support" as a tab
available from all pages; and "Support" (probably not best placed) on the
download page in Documentation. We could certainly move this to "Additional
Information" or its own category placement.


Hm, or an own colored button below a specific button, so not to put it 
at the bottom of the webpage. Then link it to 
"http://www.openoffice.org/support";.


Marcus





If you feel something additional might help, it would be best to state some
specific navigation areas or 



As I don't use MSFT Office and the last time I did found myself deep in
the sea of thick frustration, I'm the last person to ask about this.

louis

Re: [RELEASE] Releasing new languages for 3.4.1

[Marcus (OOo)]

Am 10/26/2012 11:35 PM, schrieb Rob Weir:

On Fri, Oct 26, 2012 at 5:06 PM, Marcus (OOo)  wrote:

Am 10/26/2012 07:43 PM, schrieb Andrea Pescetti:


Rob Weir wrote:


1) release new languages via lang packs only for now
2) release full installs, but for only these new languages



I don't see a big difference between a langpack and a full install in
this case, so I'd go for full installs, unless releasing langpacks helps
in communicating that these are "late" additions and that full installs
will come with the next release.


Can we really skip the release process? PO files == source, right?



Yes, not exactly but quite (PO files are not taken verbatim into source,
but they are imported and influence resource files which are in the
source tree).


Maybe a question for legal-discuss if we're not certain.



If in the end we have consensus on releasing new languages for 3.4.1
instead of making a new release, indeed we will ask.


How do we want to handle this on an ongoing basis? New point release
for every new language? Every 5 new languages? It is certainly good
for volunteers to get the encouragement of a fast turnaround for their
work. But this is the same for a C++ programmer.



There are big differences here, that are also the reason for me to
consider releasing these new languages as soon as possible:
- A translation is often done by a team; if we can publish it
immediately, the team can the be involved in other activities like
revamping the N-L website, local promotion and so on; if we wait too
much, we risk to have no volunteers for the following release.



Really? I'm not that convinced that this would happen. When we communicate
from the beginning when new loalizations will be released then everybody
should be able to understand and handle this.



- 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.



Besides the comment from Jan I remember a case from the old OOo project.
There were some translations for the names of Calc functions that got the
same name but had to get (slightly) different names. The result was that
there were 2-3 sum, 2-3 average, etc. functions. This was also - more or
less the only - reason for another respin for a OOo RC; 3.2.1, 3.3.0, I
don't remember anymore.

So, the risk of new languages may not be high but I wouldn't say it's
totally risk-free.



Certainly the risk is reduced.  But there are two areas:

1) Risk of defects caused by interaction between the core product and
the translated strings

2) Risk of a "bad build", for whatever reason, say due to change in a
system library, leading to an undetected new defect.




In the end, I wonder whether the best solution is to get into a steady
release cycle of quarterly releases (every 3 or 4 months)?



+1

IMHO a regular release schedule is a very good idea. Then everybody can cope
with this, can see when the next version will come and we can plan with a
regular release plan (when to branch, freeze, localize, etc.).

Of course the timeframe will need some discussions to find the right one.

Previously it was tried to release every 6 months a new major release and
every 6 months a point release. So, with overlapping there was a new release
every 3 month. Maybe a good timeframe to continue?



Did you do betas for all releases?  Or only major ones?  Or was this a
case-by-case decision?


Always for big major releases, here in a really public way (with 
announcements, etc.) and full blown install files. But also here and 
there also for chosen releases with en-US full install + langpacks. I 
think everybody remembers the last one - OOo 3.4.0. ;-)



We have the ability to do betas if we want.  From an Apache
perspective they would still be releases, but we could set the right
expectations with users.  For example, we wouldn't send update
notifications for beta releases.


Right.

And looking into my crystal ball, I predict that AOO 4.0 will start with 
a beta release.


Marcus




This could be a solution too. In this case we would have the problem of
choosing what to translate (3.4 or 3.5? probably we would ask new
volunteers to focus on strings that will be in the next release, even
though they aren't frozen yet).



In any case we should continue to release new languages; regardless if major
or point versions.

Marcus

Re: [RELEASE] Releasing new languages for 3.4.1

[Marcus (OOo)]

Am 10/26/2012 11:46 PM, schrieb jan iversen:

On 26 October 2012 23:38, Marcus (OOo)  wrote:


Am 10/26/2012 11:20 PM, schrieb jan iversen:

  On 26 October 2012 23:06, Marcus (OOo)   wrote:


  Am 10/26/2012 07:43 PM, schrieb Andrea Pescetti:


   Rob Weir wrote:



  1) release new languages via lang packs only for now

2) release full installs, but for only these new languages



I don't see a big difference between a langpack and a full install in
this case, so I'd go for full installs, unless releasing langpacks helps
in communicating that these are "late" additions and that full installs
will come with the next release.

   Can we really skip the release process? PO files == source, right?





Yes, not exactly but quite (PO files are not taken verbatim into source,
but they are imported and influence resource files which are in the
source tree).

   Maybe a question for legal-discuss if we're not certain.





If in the end we have consensus on releasing new languages for 3.4.1
instead of making a new release, indeed we will ask.

   How do we want to handle this on an ongoing basis? New point release


for every new language? Every 5 new languages? It is certainly good
for volunteers to get the encouragement of a fast turnaround for their
work. But this is the same for a C++ programmer.



There are big differences here, that are also the reason for me to
consider releasing these new languages as soon as possible:
- A translation is often done by a team; if we can publish it
immediately, the team can the be involved in other activities like
revamping the N-L website, local promotion and so on; if we wait too
much, we risk to have no volunteers for the following release.



Really? I'm not that convinced that this would happen. When we
communicate
from the beginning when new loalizations will be released then everybody
should be able to understand and handle this.


   - 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.



Besides the comment from Jan I remember a case from the old OOo project.
There were some translations for the names of Calc functions that got the
same name but had to get (slightly) different names. The result was that
there were 2-3 sum, 2-3 average, etc. functions. This was also - more or
less the only - reason for another respin for a OOo RC; 3.2.1, 3.3.0, I
don't remember anymore.

So, the risk of new languages may not be high but I wouldn't say it's
totally risk-free.


   In the end, I wonder whether the best solution is to get into a steady


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




  +1


IMHO a regular release schedule is a very good idea. Then everybody can
cope with this, can see when the next version will come and we can plan
with a regular release plan (when to branch, freeze, localize, etc.).

Of course the timeframe will need some discussions to find the right one.

Previously it was tried to release every 6 months a new major release and
every 6 months a point release. So, with overlapping there was a new
release every 3 month. Maybe a good timeframe to continue?



+1 to a relatively fixed time frame for new releases. Not only developers
benefit from that but also end-users !



Right


  However do we have the logistic in place to handle ideas/request/bug fixes

with these short intervals. It would mean (in my opinion) that we have an



OK, maybe the following fitts better to our current situation. Every 6
months a new major release and a point release on demand - enough new
languages, urgent/severe bugfixes; that means outside a regular release
plan.


+1




  open catalog (new development) for 2-3 releases and have to prioritize

within a limited timeframe what goes where ? We should also consider to
apply a field in bugzilla, "targeted for version".



That's already existing. Just look for the "Target Milestone" field.


I think it is not really used (I might be wrong) but with frequent releases
we should use it intensively, because today those who submit a bug must be
pretty disappointed, I looked at a bug the other day, dated 2007 which are
still a bug.


Ah, now I get it.

This problem comes from the migration from the old OOo's Issuezilla to 
Apache's Bugzilla. Here the old field disappeared and the information 
was not shown in Bugzilla.


The field you see now was added afterwards and has to be filled newly.

Marcus




  I really like the idea, but it has a tendency of killing long term

developments, because they are hard to put into this framework, so we need
something in the middle.



When we plan which new and planned feature goes into what release should
work.


I think I did not express it correctly, resources tend to be used for short
term targets (next release, high motivation, lets make it folks, and after
that we do all the rest).




Marcus




This could be a solution too. In this case we 

Re: [PROPOSAL] "difficulty" field for Bugzilla

[Rob Weir]

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.

-Rob

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

Re: [PROPOSAL] "difficulty" field for Bugzilla

[jan iversen]

Did I miss something, I thought we had the status "confirmed" to be used
not by the bug reporter but by a developer or likewise, and when
"confirmed" is set, that is the time to give the bug an easy/wizard level.

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 ??

rgds
jan

On 27 October 2012 00:09, 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.
>
> -Rob
>
> >
> >>
> >>> -Andre
> >>>
> >
> > --
> > 
> > MzK
> >
> > "Anyone who considers protocol unimportant has never
> >   dealt with a cat."
> > -- Robert Heinlein
>

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

[Ariel Constenla-Haile]

On Fri, Oct 26, 2012 at 11:06:45PM +0200, Marcus (OOo) wrote:
> I've modified the subject as I think this topic deserves its own,
> new thread.
> 
> 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.
> 
> Example:
> For every platform, we have exactly the same files in every full
> install, except for the language resource files. So, when we can
> make it that only the core (languages-independent) files are once on
> the mirrors and then the language resource files besides, then it
> would be possible to do the installation process completely new -
> with the following rough steps:
> 
> 1. Create a new basis installer: little, tiny and already localized.
> 2. The user can choose what he wants: applications, languages,
> templates, extensions.
> 3. The basis installer downloads this file set from the mirrors.

I've read this approach the other times this was discussed. While this
might be the current mainstream market trend, handy for those who send
their e-mails from their i-Phones and their i-Pads, it won't be suitable
for users from less-developed countries with bad internet connection.

Does OpenOffice user base come from this kind of countries? These
numbers don't seem to tell so:
http://www.openoffice.org/stats/countries.html But I've also read "why
would someone use OpenOffice if he/she can pay for MS Office?", meaning
that OpenOffice user base is made of people who can't afford MS Office,
we could also asume they can't afford a good internet connection, even
on developed countries like the top 7 in the list (this argument missed
the point than someone may want to use OpenOffice just because it's free
software, even if can pay for MS Office - or get an ilegal copy).


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpcLR0e0whSj.pgp
Description: PGP signature

extensions and translations.

[jan iversen]

While doing an update to the l10n workflow I think I found a slight problem.

Extensions offers the capability to integrate/extend our UI.

Assuming somebody writes an extension, and publishes it on
http://www.openoffice.org/extensions/ how does that get integrated into the
translation process ?

As far as I can see the sources are not integrated into our "build --all
--with-lang".

If I am right that they are not part of the general translation, then is
that per design so or should it be different ?

I might be following a wrong track here, but please forgive me for trying
to make the l10n process as complete as I can.

rgds
Jan I.

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

[Marcus (OOo)]

Am 10/27/2012 12:33 AM, schrieb Ariel Constenla-Haile:

On Fri, Oct 26, 2012 at 11:06:45PM +0200, Marcus (OOo) wrote:

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

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.

Example:
For every platform, we have exactly the same files in every full
install, except for the language resource files. So, when we can
make it that only the core (languages-independent) files are once on
the mirrors and then the language resource files besides, then it
would be possible to do the installation process completely new -
with the following rough steps:

1. Create a new basis installer: little, tiny and already localized.
2. The user can choose what he wants: applications, languages,
templates, extensions.
3. The basis installer downloads this file set from the mirrors.


I've read this approach the other times this was discussed. While this
might be the current mainstream market trend, handy for those who send
their e-mails from their i-Phones and their i-Pads, it won't be suitable
for users from less-developed countries with bad internet connection.

Does OpenOffice user base come from this kind of countries? These
numbers don't seem to tell so:
http://www.openoffice.org/stats/countries.html But I've also read "why
would someone use OpenOffice if he/she can pay for MS Office?", meaning
that OpenOffice user base is made of people who can't afford MS Office,
we could also asume they can't afford a good internet connection, even
on developed countries like the top 7 in the list (this argument missed
the point than someone may want to use OpenOffice just because it's free
software, even if can pay for MS Office - or get an ilegal copy).


I don't see the context to bad inet connections. Maybe you can tell with 
some other words?


When we do the restructure then we will have less content on the 
mirrors. But for the user there is no change as they still have to 
download all files that are necessary to do the installation; maybe less 
when they explicitely disables some applications and content that are 
currently be installed by default.


Marcus

Re: extensions and translations.

[Ariel Constenla-Haile]

On Sat, Oct 27, 2012 at 12:36:38AM +0200, jan iversen wrote:
> While doing an update to the l10n workflow I think I found a slight problem.
> 
> Extensions offers the capability to integrate/extend our UI.
> 
> Assuming somebody writes an extension, and publishes it on
> http://www.openoffice.org/extensions/ how does that get integrated into the
> translation process ?

They don't. They don't belong to OpenOffice source tree. Only the
Presenter Screen, the Presentation Minimizer and the Wiki Publisher are
the currently supported extensions by this Apache project (even though
the versions you find in the extensions site are rather old, the Wiki
Publisher has Sun's name in it!).

The source code for these extensions is located in main/sdext and
main/swext.

The Report Builder (main/reportbuilder), the MySQL SDBC driver
(main/mysqlc) and the PDF Import (main/sdext) extensions are in the
source tree but they can't be released by this Apache Project due to
license conflict in its dependencies. The extension code is under the
ALv2, but the dependencies are copy-left.

All other extensions in the extension site are third party extensions,
with all kind of licenses, and are unrelated to the Apache OpenOffice
project.

> As far as I can see the sources are not integrated into our "build --all
> --with-lang".

Because they are third party extensions.


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgp5ca2Wl6Xxe.pgp
Description: PGP signature

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

[Ariel Constenla-Haile]

On Sat, Oct 27, 2012 at 12:47:56AM +0200, Marcus (OOo) wrote:
> I don't see the context to bad inet connections. Maybe you can tell
> with some other words?
> 
> When we do the restructure then we will have less content on the
> mirrors. But for the user there is no change as they still have to
> download all files that are necessary to do the installation; maybe
> less when they explicitely disables some applications and content
> that are currently be installed by default.

If I understood this approach, the tiny installer downloads all the rest
at install time, that means you need a good internet connection at
install time.


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpok0YRp7m3D.pgp
Description: PGP signature

Re: extensions and translations.

[Marcus (OOo)]

Am 10/27/2012 12:36 AM, schrieb jan iversen:

While doing an update to the l10n workflow I think I found a slight problem.

Extensions offers the capability to integrate/extend our UI.

Assuming somebody writes an extension, and publishes it on
http://www.openoffice.org/extensions/ how does that get integrated into the
translation process ?


Simply, not at all.


As far as I can see the sources are not integrated into our "build --all
--with-lang".


Right.


If I am right that they are not part of the general translation, then is
that per design so or should it be different ?


Yes, this is by design.

Extensions are offered to extent your AOO install at any point of time. 
These are developed by people that do not have to belong to our project 
(when we put aside some exceptions). They can act independently. And 
therefore they are allowed to (or have to ;-) ) do all on their own; 
incl. translation.


That applies for all extensions and templates available on:

- http://extensions.services.openoffice.org
- http://templates.services.openoffice.org


I might be following a wrong track here, but please forgive me for trying
to make the l10n process as complete as I can.


Don't panic. That's a great goal and everybody is thankful to you for 
doing this task.


Marcus

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

[Marcus (OOo)]

Am 10/27/2012 12:58 AM, schrieb Ariel Constenla-Haile:

On Sat, Oct 27, 2012 at 12:47:56AM +0200, Marcus (OOo) wrote:

I don't see the context to bad inet connections. Maybe you can tell
with some other words?

When we do the restructure then we will have less content on the
mirrors. But for the user there is no change as they still have to
download all files that are necessary to do the installation; maybe
less when they explicitely disables some applications and content
that are currently be installed by default.


If I understood this approach, the tiny installer downloads all the rest
at install time, that means you need a good internet connection at
install time.


Not really, the installer can first download everything that is 
necessary and then start the installation. It should be technically also 
possible to continue a download where it stopped due to an interrupted 
inet connection.


So, at the end it's up to us how to design the tiny installer.

Marcus

Re: extensions and translations.

[jan iversen]

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).

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 ?

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

Maybe the right way is somewhere in the middle.

jan.


On 27 October 2012 00:58, Marcus (OOo)  wrote:

> Am 10/27/2012 12:36 AM, schrieb jan iversen:
>
>  While doing an update to the l10n workflow I think I found a slight
>> problem.
>>
>> Extensions offers the capability to integrate/extend our UI.
>>
>> Assuming somebody writes an extension, and publishes it on
>> http://www.openoffice.org/**extensions/how
>>  does that get integrated into the
>> translation process ?
>>
>
> Simply, not at all.
>
>
>  As far as I can see the sources are not integrated into our "build --all
>> --with-lang".
>>
>
> Right.
>
>
>  If I am right that they are not part of the general translation, then is
>> that per design so or should it be different ?
>>
>
> Yes, this is by design.
>
> Extensions are offered to extent your AOO install at any point of time.
> These are developed by people that do not have to belong to our project
> (when we put aside some exceptions). They can act independently. And
> therefore they are allowed to (or have to ;-) ) do all on their own; incl.
> translation.
>
> That applies for all extensions and templates available on:
>
> - 
> http://extensions.services.**openoffice.org
> - 
> http://templates.services.**openoffice.org
>
>
>  I might be following a wrong track here, but please forgive me for trying
>> to make the l10n process as complete as I can.
>>
>
> Don't panic. That's a great goal and everybody is thankful to you for
> doing this task.
>
> Marcus
>

Re: [RELEASE] Releasing new languages for 3.4.1

[Dave Fisher]

On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote:
> ...  it would probably allow to skip the release process and voting, since we 
> would merely be adding 3-5 binary artifacts (built for different platforms).

It is an interesting question if we should only vote for source releases. 
Certainly these are the only "official" release. I think that the practice is 
to vote for binary packages as well. Clearly those have a different bar. It is 
worth discussing, but I am inclined to think that we do need to VOTE on these 
packages, but in this case we are voting at a certain level of trust for the 
packager and translations.

Regards,
Dave

Re: [RELEASE] Releasing new languages for 3.4.1

[jan iversen]

+1, being a non-native english speakng person, I want to ensure that we
keep the AOO stability in language versions and not just see them as nice
to have add-on !!
jan

On 27 October 2012 01:48, Dave Fisher  wrote:

>
> On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote:
> > ...  it would probably allow to skip the release process and voting,
> since we would merely be adding 3-5 binary artifacts (built for different
> platforms).
>
> It is an interesting question if we should only vote for source releases.
> Certainly these are the only "official" release. I think that the practice
> is to vote for binary packages as well. Clearly those have a different bar.
> It is worth discussing, but I am inclined to think that we do need to VOTE
> on these packages, but in this case we are voting at a certain level of
> trust for the packager and translations.
>
> Regards,
> Dave

Re: The Impossible Question

[Dave Fisher]

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.

Regards,
Dave

> 
> Thanks
> Louis
> 

Re: extensions and translations.

[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.

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


pgp5xJdU39Y2o.pgp
Description: PGP signature

Re: [RELEASE] Releasing new languages for 3.4.1

[Rob Weir]

On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher  wrote:
>
> On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote:
>> ...  it would probably allow to skip the release process and voting, since 
>> we would merely be adding 3-5 binary artifacts (built for different 
>> platforms).
>
> It is an interesting question if we should only vote for source releases. 
> Certainly these are the only "official" release. I think that the practice is 
> to vote for binary packages as well. Clearly those have a different bar. It 
> is worth discussing, but I am inclined to think that we do need to VOTE on 
> these packages, but in this case we are voting at a certain level of trust 
> for the packager and translations.
>

But the point is we need to release the source that the binaries
depend on, where that source is from this project.

It would be one thing if we were just releasing a new platform port of
existing source packages.  But we're not.

We're talking about new translations resources, where such resources
are in SVN and are required as part of the build process in order to
build the localized binaries.  No downstream consumer of the source
will be able to build these localizations without having access to the
translated resources.  Therefore these resources should be reviewed,
voted on and released.

Remember, the translations are non-trivial creative works,
translations of not only UI strings, but larger text passages from the
help files.  They are under copyright and made available under
license.  So we need to do our due diligence via the release process
before we distribute such materials.

-Rob

> Regards,
> Dave

Re: [RELEASE] Releasing new languages for 3.4.1

[Rob Weir]

On Fri, Oct 26, 2012 at 9:55 PM, Rob Weir  wrote:
> On Fri, Oct 26, 2012 at 7:48 PM, Dave Fisher  wrote:
>>
>> On Oct 26, 2012, at 12:07 AM, Andrea Pescetti wrote:
>>> ...  it would probably allow to skip the release process and voting, since 
>>> we would merely be adding 3-5 binary artifacts (built for different 
>>> platforms).
>>
>> It is an interesting question if we should only vote for source releases. 
>> Certainly these are the only "official" release. I think that the practice 
>> is to vote for binary packages as well. Clearly those have a different bar. 
>> It is worth discussing, but I am inclined to think that we do need to VOTE 
>> on these packages, but in this case we are voting at a certain level of 
>> trust for the packager and translations.
>>
>
> But the point is we need to release the source that the binaries
> depend on, where that source is from this project.
>
> It would be one thing if we were just releasing a new platform port of
> existing source packages.  But we're not.
>
> We're talking about new translations resources, where such resources
> are in SVN and are required as part of the build process in order to
> build the localized binaries.  No downstream consumer of the source
> will be able to build these localizations without having access to the
> translated resources.  Therefore these resources should be reviewed,
> voted on and released.
>
> Remember, the translations are non-trivial creative works,
> translations of not only UI strings, but larger text passages from the
> help files.  They are under copyright and made available under
> license.  So we need to do our due diligence via the release process
> before we distribute such materials.
>

Should say, "before we distribute such materials in source OR source
and binary form".  The issues are the same.

Remember, the source package is canonical.  I'm surprised to hear talk
now of releasing only binaries.

-Rob

> -Rob
>
>> Regards,
>> Dave

Uninstalling Open Office

[Dave Whitehouse]

I wish to uninstall and then re-install Open Office.
The reason is I am unable to open the Open Office because I have a drop-down 
box which tells me I need to 'restore windows of open office' and rfe-reghister 
or something similar.
I cannot get rid of this drop-down and cannot open the application.
I am not very happy at the moment and the iMac (I use) has an application 
called 'Pages' which is looking pretty good at the moment.

Please tell me how to uninstall open office. I do not have an 'uninstall' icon 
anywhere.

Help!
Regards
Dave


Dave & Anna Whitehouse
33 Parkside Drive,
Orewa, Auckland 0931
New Zealand
64-09-959-0203
daveandan...@xnet.co.nz

Re: Uninstalling Open Office

[Larry Gusaas]

On 2012-10-26 6:59 PM Dave Whitehouse wrote:

I wish to uninstall and then re-install Open Office.
The reason is I am unable to open the Open Office because I have a drop-down 
box which tells me I need to 'restore windows of open office' and rfe-reghister 
or something similar.
I cannot get rid of this drop-down and cannot open the application.


See this thread on the OpenOffice community forum for the solution to your 
problem.
http://forum.openoffice.org/en/forum/viewtopic.php?f=17&t=55755


I am not very happy at the moment and the iMac (I use) has an application 
called 'Pages' which is looking pretty good at the moment.

Please tell me how to uninstall open office. I do not have an 'uninstall' icon 
anywhere.


The same way you uninstall most programs on a Mac. Delete the app from your 
Applications folder.

No need to though. Just follow the instructions on the link I posted above.

--

As a courtesy I have sent a copy of this reply to you as well as to the mailing list. Do Not 
reply to me personally but just to the list at  - replies to my 
personal email address will be ignored.


Since you are not subscribed to this list you may not see all the replies to your query. To 
subscribe Apache OpenOffice mailing lists go to

http://incubator.apache.org/openofficeorg/mailing-lists.html

For user support you can also use The OpenOffice.org Community Forum
http://user.services.openoffice.org/en/forum/

_

Larry I. Gusaas
Moose Jaw, Saskatchewan Canada
Website: http://larry-gusaas.com
"An artist is never ahead of his time but most people are far behind theirs." - 
Edgard Varese

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

[Graham Lauder]

On Friday 26 Oct 2012 10:41:04 Dave Fisher wrote:
> Sent from my iPhone
> 
> On Oct 26, 2012, at 9:59 AM, Graham Lauder  wrote:
> > On Friday 26 Oct 2012 11:04:46 Rob Weir wrote:
> >> On Fri, Oct 26, 2012 at 4:36 AM, Graham Lauder  
wrote:
> >>> The launch of 4.0 is a unique opportunity in the life of AOO both
> >>> now
> >>> and
> >>> far into the future.
> >>> 
> >>> The branding needs to position us in the market place, be
> >>> distinctive
> >>> and
> >>> unique and makes a statement about the product.
> >>> 
> >>> The creation of this requires a skillset that we do not have an over
> >>> abundance of in the project.
> >>> 
> >>> The proposal therefore is to initiate a contest to create this new
> >>> branding, this would have multiple benefits in terms of community
> >>> outreach, marketing and raising brand awareness.
> >>> 
> >>> The contest would be source of the eventual branding of AOO 4.0
> >> 
> >> +1
> >> 
> >> The devil is in the details, but I think a contest can be a great way
> >> of getting many ideas, but also promoting AOO 4.0.  It makes it "an
> >> event".
> >> 
> >> I think Dave mentioned that another Apache project had a logo contest
> >> and received a large number of entries.
> > 
> > Which is why we go with "Branding", it's much broader than just a
> > graphic
> > logo.  there's color pallet, overall style, message, tenor,
> > presentation.
> > Those who just present a logo in isolation will be filtered early. 
> > Those that have a grasp of the full depth of the brand but without the
> > whole package will show early which is why we go back to the responders
> > for more detail later on. Initial  proposals will to show understanding
> > of the task first up.


> For Apache Flex there were over 50 submissions of varying quality, style and
> presentation including a video. Everything was handled on the dev list.
> There was an understanding that branding would be involved. There were two
> rounds of voting and the community and the PPMC were in close agreement.
> The PPMC chose the community's second choice, but it was a very close
> second.

Firstly, I like the Flex logo, however I don't see it as whole branding 
policy.

second, they have a small, specific, knowledgeable target market.

Third and once again I'll get shot at for making the statement, AOO is a 
consumer product that counts it's users in the hundreds of millions which 
makes things a little different.  Flex's logo is a personal thing that 
reflects the community that develop it, there is no requirement for the brand  
to excite new users.  Flex's best branding attribute is how well it does what 
it's designed to do.  There is little subjective in the reasoning for a 
developer to use a particular SDK and a Visual Brand Element is unlikely to 
make a huge difference to expanding the user base.  It can however engender a 
feeling of community and that is great.  Certainly there will be an element of 
that in AOO's branding.  However, in the consumer space there is a strong 
corelation between Brand Visualisation and the way the consumer feels about a 
product.  Good branding engenders loyalty,  encourages users to give-it-a-try 
and raises the dissatisfaction threshold.

We know that it does the job it sets out to do.  When I do change management 
jobs and training and I demonstrate what OOo can do people go wow and are 
always impressed, especially when I concentrate on the things that the 
opposition can't do.  However our opposition has a higher threshold before 
people get dissatisfied as evidenced by the number of support calls to OOo 
that are basically problems caused by inadequacies in the other product not 
with OOo.  

Good branding and a bunch of other things surrounding the project will 
mitigate that by building trust.  

The people in this community are not our customers or at least are a small 
subset of, it is the wider customer base or future customers that will (and 
should) guide us as to the best branding policies.

Community votes don't work in a consumer product, votes are too subjective.  
The community needs to be completely objective and divorce itself from likes 
or dislikes and consider only the feelings of the market,  the market will 
provide the subjective bit.


> 
> The licensing required was made clear and the submissions were gathered on
> the podling site.
> 
> For this contest we should be very clear  about the contexts that
> submissions should show. Site, splash screen, tshirt, etc.
> 

All that is a given, however your headings are far too simplistic those are 
just items.  This branding will colour the whole look and feel of the product 
and will steer everything from stationery, webpresence to future icons to the 
way we communicate with our users and potential users.

There are two overriding considerations:
Building Brand trust and 
Building Brand recognition

This proposal is to "Initiate", there is a lot of work to do and discussions 
to be had before the final RFP is relea

Ambiguous paths for module hunspell

[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?

-- 
Cheers,

Ian C