date:20130318

On Mon, Mar 18, 2013 at 5:02 PM, Alexandro Colorado  wrote:
> *Google Summer of Code* is a global program that offers students stipends
> to write code for open source projects. We have worked with the open source
> community to identify and fund exciting projects for the upcoming summer.
>
> http://www.google-melange.com/gsoc/homepage/google/gsoc2013
>
> Mentoring Organization Applications Now Being Accepted for Google Summer of
> Code 
> 2013!
> http://google-opensource.blogspot.mx/2013/03/mentoring-organization-applications-now.html
>

Cool!If it works like it did last year, the ASF will apply as a
"mentoring organization" and will be allocated a number of slots, and
then individual mentor/volunteers apply within Apache for one of these
slots.

-Rob

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

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Tutorial: dedicated website

2013-03-18 Thread Kay Schenk

On Thu, Mar 14, 2013 at 4:41 PM, Andrea Pescetti wrote:

> FR web forum wrote:
>
>> I don't see a big advantage in terms of usability between the MWiki we
>>> already have and any other CMS.
>>>
>> Well, why Extensions or Templates website don't use MWiki in this case?
>>
>
> It is a different use case (even leaving historical reasons aside). For
> example, tutorials are something that people could cooperate in writing and
> that may get updated often, and this is best done on a wiki (or forum; at
> least this is my understanding of it), while extensions for example are
> closer to software releases.
>
>
>  You must think to end-users that have write a tutorial.
>>
>
> I'm trying to, but, again, do you have a few examples? Maybe tutorials
> that you wrote yourself and that would be difficult to upload to one of the
> existing resources?
>
>
>  A Wiki need to have specific skill to publish.
>>
>
> You are right if you mean that on MWiki it is unnecessarily long and
> complex, for example, to upload attachments. Actually, it seems that the
> Forum currently offers good possibilities for those who want to publish
> tutorials: pages like
> http://forum.openoffice.org/**en/forum/viewtopic.php?f=7&t=**67
> http://forum.openoffice.org/**en/forum/viewtopic.php?f=74&t=**12426
> are done quite easily on the Forum, are very visible from search engines
> and can be updated as often as needed. And if someone wants to attach a PDF
> version this can be done easily.
>
> What would the biggest advantage be for you? Ease of use (for users who
> wrote a tutorial and want to publish it) or visibility (like having a
> dedicated tutorials.openoffice.org website where we consolidate all
> tutorials)? And how many tutorials could it be reasonable to have? Could we
> reach hundreds of tutorials, for example?
>
> Regards,
>   Andrea.
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
Even though I do find the wiki cumbersome at times, I also often wonder if
we installed some different/navigation tools (I asked about this a long
time ago and maybe now's the time to go exploring) that would help with
some of this.
This is why I like the cwiki navigation -- you don't need to link TO
anything. Just put whatever it is under a category and it's relatively easy
to find.

In reference to establishing a link to "tutorials.openoffice.org". Could
this be done with a rewrite to a specific area on the wiki? I think maybe
it could.

At this point, given the services like this we already use, Confluence,
MediaWiki, thinking about yet another one doesn't seem like a good approach
to me. Converting from one  to something else might be reasonable but not
introducing something else. We have quite a collection of tutorials already
on wiki.openoffice.org. I think we  need to consider our current
resources  -- platforms, people -- carefully.


-- 

MzK

"Achieving happiness requires the right combination of Zen and Zin."

my config experience/woes

2013-03-18 Thread Kay Schenk

A couple of weeks ago I tired to get going on a build to JUST test out
hsqldb 2.2.9 and my now Oracle Java
1.7.0_17 version. (opensuse 12.2 Linux). Yes, this was the first time I
actually tried to do an AOO build, but, decided it was time. :}

I wanted  to setup the config to eliminate as many the bells and whistles,
so I disabled a bunch of stuff.
(More about that in another post soonish.)

Long story short, I had a difficult time getting "configure" to find
libraries I have installed. It seems the script uses pkg-config to find
libraries. Unfortunately, in my case, only about a third of the libraries I
have installed conform to pkg-config, i.e. have the proper ".pc" meta
files. So, my local jpeg library, for example, was not found.

I could have had a VERY exasperating time putting in all the specs for the
libraries not found. So those that weren't were pulled from "extras", etc.
but I'm wondering if there's something we could use to replace the
pkg-config calls. Any ideas?

We could use "whereis" to find them I guess, but I don't know if this is
sufficient.



-- 

MzK

"Achieving happiness requires the right combination of Zen and Zin."

Re: FormatArea Draw

2013-03-18 Thread jorge ivan poot diaz

I already found the dialogue box code:
http://imagebin.org/250778

http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/cui/source/dialogs/dlgname.src

46 

   Edit 

EDT_STRING 
47

   {48 

   HelpID 

= "cui:Edit:RID_SVXDLG_NAME:EDT_STRING";49

   Border 

= TRUE 

;50 

   Pos 

= MAP_APPFONT 

( 6 , 17 ) ;51 

   Size 

= MAP_APPFONT 

( 112 , 12 ) ;52

   TabStop 

= TRUE 

;53 

   };54 

   OKButton 

BTN_OK 



where's the code that registers the new color?


2013/3/18 jorge ivan poot diaz 

> Hello,
>
> in
>
> http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/cui/source/tabpages/tabarea.src
>
> 1420 
> 
> PushButton 
> 
>  BTN_ADD 
> 1421
>  
> 
> {1422 
> 
> HelpID 
>  
> = "cui:PushButton:RID_SVXPAGE_COLOR:BTN_ADD";1423 
> 
> Pos 
>  = 
> MAP_APPFONT 
> 
>  ( 197 , 14 ) ;1424 
> 
> Size 
>  = 
> MAP_APPFONT 
> 
>  ( 50 , 14 ) ;1425 
> 
> Text 
>  [ 
> en 
> -US 
>  ] = 
> "~Add" ;1426 
> 
> TabStop 
>  
> = TRUE 
>  
> ;1427 
> 
> };
>
>
> The button to add colors, now I want to know where is the code that
> registers the colors.
>
>
>
> 2013/3/18 Ariel Constenla-Haile 
>
>> On Mon, Mar 18, 2013 at 10:54:39AM -0600, jorge ivan poot diaz wrote:
>> > >  If you want to locate the source code for a dialog/tab page/control,
>> > you  can export HELP_DEBUG=1 and enable  extended too

Re: Apache OpenOffice Extensions Website 2.0 (beta)

2013-03-18 Thread Roberto Galoppini

On Mon, Mar 18, 2013 at 9:35 AM, Jürgen Schmidt  wrote:
> On 3/15/13 9:44 PM, hagar.del...@laposte.net wrote:
>> Really AWESOME!
>> A huge step forward regarding the interface.
>> Many thanks for this improved site.
>
> yes indeed, I like it as well and it looks good.

Thanks guys, it's rewarding to know you appreciate that.

> We still don't have the extension update notification feature working as
> far as I know. Do you have any plans to make it working on the
> repository site? Or better what is necessary to bring it back on the
> repo site and in the office?

The new Extensions website will have it! The actual beta site doesn't
have it yet, though. Downloads won't happen automatically as for AOO
updates, yet another opportunity to interact with end-users then.

Roberto

>
> Juergen
>
>>
>> Hagar
>>
>>> Message du 15/03/13 19:53
>>> De : "Roberto Galoppini"
>>> A : dev@openoffice.apache.org
>>> Copie à :
>>> Objet : Apache OpenOffice Extensions Website 2.0 (beta)
>>>
>>> As announced back at the end of December we have been working on
>>> enhancing AOO Extensions website, you might want to have a look at
>>> http://aoo-extbeta.sourceforge.net/
>>>
>>> Keep in mind that the final layout would depend on AOO 4.0, and
>>> counters are set to zero because downloads don't happen over there.
>>> So said, all accounts and extensions have been imported, so releases
>>> and comments.
>>>
>>> If you want to make your mind about the new features have a look at
>>> the following URLs:
>>> http://aoo-extbeta.sourceforge.net/
>>> http://aoo-extbeta.sourceforge.net/search
>>> http://aoo-extbeta.sourceforge.net/project/oracle-pdf-import-extension
>>>
>>> Comments and feedback are welcome as usual.
>>>
>>> Roberto
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>
>>>
>>
>> Une messagerie gratuite, garantie à vie et des services en plus, ça vous 
>> tente ?
>> Je crée ma boîte mail www.laposte.net

-- 

This e- mail message is intended only for the named recipient(s) above. It 
may contain confidential and privileged information. If you are not the 
intended recipient you are hereby notified that any dissemination, 
distribution or copying of this e-mail and any attachment(s) is strictly 
prohibited. If you have received this e-mail in error, please immediately 
notify the sender by replying to this e-mail and delete the message and any 
attachment(s) from your system. Thank you.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: A question about existing practices

2013-03-18 Thread Andrea Pescetti


Dave Fisher wrote:

There is no consensus here to eliminate or reset the votes. Some who
are more in touch with users have stated that it would be harmful. I
trust their judgement.


Indeed. No reasons to elaborate further. We have votes in Bugzilla; we 
can only keep them and, in case we want to use them as binding 
indications rather than suggestions (e.g., if we commit to fix the top 
three issues, sorted by votes), new votes will quickly supersede the old 
ones. Until then, it's harmless to keep them around.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Exit moderator mailing

On Fri, Mar 15, 2013 at 8:33 AM, Albino Biasutti Neto  wrote:
> Hi
>
> I am moderator of mailing doc,api @ o.a.o.
>
> Today I am out of time to moderate, I ask to remove moderation. Thanks.
>

What address are you using for moderation?  Your apache.org email address?

I think you will need to enter a JIRA issue for Infra to be removed as
a moderator.

It would be good also if there was another volunteer for the doc and
api mailing lists, to help with that.

-Rob

> Albino
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: A question about existing practices

2013-03-18 Thread Dave Fisher

Top post.

There is no consensus here to eliminate or reset the votes. Some who are more 
in touch with users have stated that it would be harmful. I trust their 
judgement.

Issues that are recent that get votes should be discernible by developers 
looking at BZ. Any issue with a lot of votes might be interesting for a new 
developer. Reveal codes could become reveal ODF someone with a C++ programming 
dog and a java programming cat might do it someday.

Sent from my iPhone

On Mar 18, 2013, at 10:08 AM, Jürgen Schmidt  wrote:

> On 3/18/13 5:34 PM, Rob Weir wrote:
>> On Mon, Mar 18, 2013 at 11:32 AM, RGB ES  wrote:
>>> 2013/3/18 Rob Weir 
>>> 
 On Mon, Mar 18, 2013 at 10:11 AM, RGB ES  wrote:
> 2013/3/18 Jörg Schmidt 
> 
>> 
>> 
>>> -Original Message-
>>> From: Rob Weir [mailto:robw...@apache.org]
>> 
>>> I'd say, "Thanks for the suggestion.  We take all suggestions
>>> seriously, and user suggestions are often the source of ideas that
>>> make it into the product.  Thank you for using AOO."
>> 
>> Sounds fine for me.
>> 
>>> The title of the tread is "A question about existing practices".  I
>>> think the facts are quite clear.  If we have many 10 year old
>>> untouched BZ issues then fixing these issues is not part of our
>>> existing practice, whether you define that as mandatory, voluntary or
>>> whatever.
>> 
>> No problem.
>> 
>>> "Practice" is what we do, not what we talk about doing.
>> 
>> Yes, but what we must be as clearly defined this user can foresee it.
>> 
>> Why?
>> If I as a user know any bug in the program, it may be important for me
 to
>> know _approximately_ when this will be fixed.
>> 
>>> you want to argue that we talk a lot about fixing old issues, and say
>>> many solemn things about how important they are, then I would agree
>>> with you 100%.  But we don't actually do anything about them.
>> 
>> I do not know how to define something should, but I know that you have
 to
>> make it transparent.
>> 
>> For example, a road map for developing the program is important because
 it
>> clarifies what new features AOO will have in the future. That's right,
>> that's a good thing.
>> 
>> But it is also important to clarify how to deal with bugs and feature
>> wishes of users.
>> There was the suggestion to delete all old votes, only we must still
>> clarify how we handle new votes. I think.
>> 
> 
> +1.
> 
> There is an old joke: "I'm only responsible for what I say not for what
 you
> understand", but the fact is that being AOO an end user application what
> our users understand IS important for us. And what will people understand
> if they know all those votes are being deleted? IMO, users will take this
> as "they do not care about our votes, why should I vote again? Why
 should I
> fill a bug report that nobody reads?" and that's a really bad thing.
> 
 
 They'll believe what we tell them.  If we say that we're "resetting"
 the vote counts in order to determine what is most relevant to users
 today, starting with an unbiased and fresh view of today's users
 priorities, and not to over-advantage the dead hand of decade-old
 votes from users who may or may not even still be using OpenOffice
 today, then this will be seen as a good thing.
 
> If you want to know how relevant old issues are, once we have a working
> survey system we can start a series of surveys about most wanted features
> requests. IMO, the only valid way to delete votes, the only way that show
> respect to our users is to close the corresponding issues.
> 
 
 The fact that there are decade old issues demonstrates that they are
 not relevant at all.
>>> 
>>> 
>>> The fact that there are decade old issues only demonstrate they are still
>>> unresolved: nothing more, nothing less. Are you saying the request to
>>> provide support for opentype features is obsolete only because nobody
>>> solved it since the issue was filled on 2003, and that we need to trash the
>>> more than 200 votes for it? Sorry, but that makes no sense...
>> 
>> 
>> Yes, that is exactly what I am saying.   If you want to argue the
>> contrary you would need to explain what the relevance is of issues
>> that are 10-years old and have not been touched and probably never
>> will be.  I might as well keep in a box my letters to Santa Claus from
>> when I was a child, in hopes that they may be someday delivered.  If
>> something has not been touched for 10 years this is an extremely
>> strong indication that it is irrelevant.  Things that are important
>> tend to be done.  Things that are not important do not get done.   I
>> know of no other measure for determining this.
> 
> I don't think that it help us forward if we nitpicking further about
>

Re: A question about existing practices

2013-03-18 Thread Dave Fisher



Sent from my iPhone

On Mar 18, 2013, at 8:22 AM, Rob Weir  wrote:

> On Mon, Mar 18, 2013 at 11:12 AM, Dennis E. Hamilton  
> wrote:
>> From my perspective, Jörg's concern is very simple.
>> 
>> There are actions and arrangements that have been made that encourage 
>> certain expectations in the mind of persons who participate and contribute 
>> in various ways.  And when those expectations are unsatisfied, that leads to 
>> assessments and opinions about the project.
>> 
>> The Apache OpenOffice project could take responsibility for the fact that 
>> some aspects of our structures do encourage such expectations.  A possible 
>> approach is to remove something that establishes expectations that there is 
>> no desire to see as creating any commitment on the part of the project.   
>> Having voting buttons is an example.  Another possibility would be to add 
>> more transparency and visibility to the stuck issues that have received many 
>> votes and that are not going anywhere (and the rationale for that).
> 
> Oh, no.  Buttons are very useful, even if they do nothing.  This has
> been experimentally verified.  In fact, some towns now have buttons at
> crosswalks that do absolutely nothing.  But the people waiting for the
> light to change are happier having a button to press, thinking that it
> actually makes the light change faster.  So expectations are
> important.  I don't doubt that.

In California you will wait along time to cross at some intersections if you 
fail to press the button. Some of these are dummies or are broken, but a lot 
work.


> 
>> In other situations, there is immediate action and sometimes abrupt action 
>> taken to clarify a mistaken expectation.  Someone who wants telephone 
>> contact from a support person, or who has some other demand is usually 
>> straightened-out immediately, even though bouncing someone to the Forums or 
>> users @o.a.o for "support" is sometimes rather circumspect.  Folks who think 
>> posts to lists are private communications are dissuaded of that.
>> 
>> Of course, participants and observers take away whatever impressions of the 
>> AOO project that they do.  In some case, it is important to accept that our 
>> arrangements contribute to some of those and that it is in our hands to find 
>> a responsible adjustment.
>> 
>> I am not lobbying for a particular resolution (no guessing, please).  I do 
>> think that the situation deserves recognition and not deflection.
>> 
>> - Dennis
>> 
>> PS: My all-time favorite unreconcilable voted-for issue is the request for 
>> "Reveal Codes" in the manner of WordPerfect.
>> 
>> -Original Message-
>> From: Rob Weir [mailto:robw...@apache.org]
>> Sent: Monday, March 18, 2013 06:13
>> To: dev@openoffice.apache.org
>> Subject: Re: A question about existing practices
>> 
>> On Mon, Mar 18, 2013 at 8:49 AM, Jörg Schmidt  wrote:
>>> 
 From: Rob Weir [mailto:robw...@apache.org]
 A promise to do what?
>>> 
>>> The opinion of the user to be taken seriously because you have asked him to 
>>> speak his mind.
>>> 
 But a feature request?
>>> 
>>> This is an opinion of our users. It should be important to us.
>> [ ... ]
>>> It's about respect for what we bring to our users, because it is a 
>>> fundamental difference between what we need to do and what we should do so 
>>> voluntarily.
>> 
>> The title of the tread is "A question about existing practices".  I
>> think the facts are quite clear.  If we have many 10 year old
>> untouched BZ issues then fixing these issues is not part of our
>> existing practice, whether you define that as mandatory, voluntary or
>> whatever.  "Practice" is what we do, not what we talk about doing.  If
>> you want to argue that we talk a lot about fixing old issues, and say
>> many solemn things about how important they are, then I would agree
>> with you 100%.  But we don't actually do anything about them.
>> 
>> [ ... ]
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: A question about existing practices

On Mon, Mar 18, 2013 at 1:08 PM, Jürgen Schmidt  wrote:
> On 3/18/13 5:34 PM, Rob Weir wrote:
>> On Mon, Mar 18, 2013 at 11:32 AM, RGB ES  wrote:
>>> 2013/3/18 Rob Weir 
>>>
 On Mon, Mar 18, 2013 at 10:11 AM, RGB ES  wrote:
> 2013/3/18 Jörg Schmidt 
>
>>
>>
>>> -Original Message-
>>> From: Rob Weir [mailto:robw...@apache.org]
>>
>>> I'd say, "Thanks for the suggestion.  We take all suggestions
>>> seriously, and user suggestions are often the source of ideas that
>>> make it into the product.  Thank you for using AOO."
>>
>> Sounds fine for me.
>>
>>> The title of the tread is "A question about existing practices".  I
>>> think the facts are quite clear.  If we have many 10 year old
>>> untouched BZ issues then fixing these issues is not part of our
>>> existing practice, whether you define that as mandatory, voluntary or
>>> whatever.
>>
>> No problem.
>>
>>> "Practice" is what we do, not what we talk about doing.
>>
>> Yes, but what we must be as clearly defined this user can foresee it.
>>
>> Why?
>> If I as a user know any bug in the program, it may be important for me
 to
>> know _approximately_ when this will be fixed.
>>
>>> you want to argue that we talk a lot about fixing old issues, and say
>>> many solemn things about how important they are, then I would agree
>>> with you 100%.  But we don't actually do anything about them.
>>
>> I do not know how to define something should, but I know that you have
 to
>> make it transparent.
>>
>> For example, a road map for developing the program is important because
 it
>> clarifies what new features AOO will have in the future. That's right,
>> that's a good thing.
>>
>> But it is also important to clarify how to deal with bugs and feature
>> wishes of users.
>> There was the suggestion to delete all old votes, only we must still
>> clarify how we handle new votes. I think.
>>
>
> +1.
>
> There is an old joke: "I'm only responsible for what I say not for what
 you
> understand", but the fact is that being AOO an end user application what
> our users understand IS important for us. And what will people understand
> if they know all those votes are being deleted? IMO, users will take this
> as "they do not care about our votes, why should I vote again? Why
 should I
> fill a bug report that nobody reads?" and that's a really bad thing.
>

 They'll believe what we tell them.  If we say that we're "resetting"
 the vote counts in order to determine what is most relevant to users
 today, starting with an unbiased and fresh view of today's users
 priorities, and not to over-advantage the dead hand of decade-old
 votes from users who may or may not even still be using OpenOffice
 today, then this will be seen as a good thing.

> If you want to know how relevant old issues are, once we have a working
> survey system we can start a series of surveys about most wanted features
> requests. IMO, the only valid way to delete votes, the only way that show
> respect to our users is to close the corresponding issues.
>

 The fact that there are decade old issues demonstrates that they are
 not relevant at all.
>>>
>>>
>>> The fact that there are decade old issues only demonstrate they are still
>>> unresolved: nothing more, nothing less. Are you saying the request to
>>> provide support for opentype features is obsolete only because nobody
>>> solved it since the issue was filled on 2003, and that we need to trash the
>>> more than 200 votes for it? Sorry, but that makes no sense...
>>
>>
>> Yes, that is exactly what I am saying.   If you want to argue the
>> contrary you would need to explain what the relevance is of issues
>> that are 10-years old and have not been touched and probably never
>> will be.  I might as well keep in a box my letters to Santa Claus from
>> when I was a child, in hopes that they may be someday delivered.  If
>> something has not been touched for 10 years this is an extremely
>> strong indication that it is irrelevant.  Things that are important
>> tend to be done.  Things that are not important do not get done.   I
>> know of no other measure for determining this.
>
> I don't think that it help us forward if we nitpicking further about
> different understanding if something is still relevant or obsolete.
>
> The point is that Rob is correct to assume that if a 10 year old
> issue/RFE is not yet addressed it will be likely not addressed in the
> next 10 years if not a huge bunch of developers fall down of heaven.
>
> The question is if we want to use the voting feature in the future if it
> is useful to reset the current votes or at least review the current
> issues with high votes and mark them as invalid/won't fix or whatever to
> ge

Re: A question about existing practices

On 3/18/13 5:34 PM, Rob Weir wrote:
> On Mon, Mar 18, 2013 at 11:32 AM, RGB ES  wrote:
>> 2013/3/18 Rob Weir 
>>
>>> On Mon, Mar 18, 2013 at 10:11 AM, RGB ES  wrote:
 2013/3/18 Jörg Schmidt 

>
>
>> -Original Message-
>> From: Rob Weir [mailto:robw...@apache.org]
>
>> I'd say, "Thanks for the suggestion.  We take all suggestions
>> seriously, and user suggestions are often the source of ideas that
>> make it into the product.  Thank you for using AOO."
>
> Sounds fine for me.
>
>> The title of the tread is "A question about existing practices".  I
>> think the facts are quite clear.  If we have many 10 year old
>> untouched BZ issues then fixing these issues is not part of our
>> existing practice, whether you define that as mandatory, voluntary or
>> whatever.
>
> No problem.
>
>> "Practice" is what we do, not what we talk about doing.
>
> Yes, but what we must be as clearly defined this user can foresee it.
>
> Why?
> If I as a user know any bug in the program, it may be important for me
>>> to
> know _approximately_ when this will be fixed.
>
>> you want to argue that we talk a lot about fixing old issues, and say
>> many solemn things about how important they are, then I would agree
>> with you 100%.  But we don't actually do anything about them.
>
> I do not know how to define something should, but I know that you have
>>> to
> make it transparent.
>
> For example, a road map for developing the program is important because
>>> it
> clarifies what new features AOO will have in the future. That's right,
> that's a good thing.
>
> But it is also important to clarify how to deal with bugs and feature
> wishes of users.
> There was the suggestion to delete all old votes, only we must still
> clarify how we handle new votes. I think.
>

 +1.

 There is an old joke: "I'm only responsible for what I say not for what
>>> you
 understand", but the fact is that being AOO an end user application what
 our users understand IS important for us. And what will people understand
 if they know all those votes are being deleted? IMO, users will take this
 as "they do not care about our votes, why should I vote again? Why
>>> should I
 fill a bug report that nobody reads?" and that's a really bad thing.

>>>
>>> They'll believe what we tell them.  If we say that we're "resetting"
>>> the vote counts in order to determine what is most relevant to users
>>> today, starting with an unbiased and fresh view of today's users
>>> priorities, and not to over-advantage the dead hand of decade-old
>>> votes from users who may or may not even still be using OpenOffice
>>> today, then this will be seen as a good thing.
>>>
 If you want to know how relevant old issues are, once we have a working
 survey system we can start a series of surveys about most wanted features
 requests. IMO, the only valid way to delete votes, the only way that show
 respect to our users is to close the corresponding issues.

>>>
>>> The fact that there are decade old issues demonstrates that they are
>>> not relevant at all.
>>
>>
>> The fact that there are decade old issues only demonstrate they are still
>> unresolved: nothing more, nothing less. Are you saying the request to
>> provide support for opentype features is obsolete only because nobody
>> solved it since the issue was filled on 2003, and that we need to trash the
>> more than 200 votes for it? Sorry, but that makes no sense...
> 
> 
> Yes, that is exactly what I am saying.   If you want to argue the
> contrary you would need to explain what the relevance is of issues
> that are 10-years old and have not been touched and probably never
> will be.  I might as well keep in a box my letters to Santa Claus from
> when I was a child, in hopes that they may be someday delivered.  If
> something has not been touched for 10 years this is an extremely
> strong indication that it is irrelevant.  Things that are important
> tend to be done.  Things that are not important do not get done.   I
> know of no other measure for determining this.

I don't think that it help us forward if we nitpicking further about
different understanding if something is still relevant or obsolete.

The point is that Rob is correct to assume that if a 10 year old
issue/RFE is not yet addressed it will be likely not addressed in the
next 10 years if not a huge bunch of developers fall down of heaven.

The question is if we want to use the voting feature in the future if it
is useful to reset the current votes or at least review the current
issues with high votes and mark them as invalid/won't fix or whatever to
get a clean start point.

In general I would like to make use of the voting feature but with the
current state I am not sure if it make sense. Many issues that probably
nobody w

Re: [CODE/LEGAL] Status of odt2mediawiki.xsl (Wiki Publisher extension)

2013-03-18 Thread Ariel Constenla-Haile

On Mon, Mar 18, 2013 at 09:29:19AM +0100, Jürgen Schmidt wrote:
> I have contacted Bernard and he was very open minded regarding
> re-licensing and he was very cooperative.
> 
> He has reviewed the transformation (link From Ariel) and compared it
> to a version in his own repo. He has appended a new version with ALv2
> to issue https://issues.apache.org/ooo/show_bug.cgi?id=121907
> 
> 
> @Ariel, let me know if I can help further or do we need more?

No, that's enough, thanks. The rest of this code is already ALv2.


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpc8DHvV9Gcr.pgp
Description: PGP signature

Re: FormatArea Draw

2013-03-18 Thread Ariel Constenla-Haile

On Mon, Mar 18, 2013 at 10:54:39AM -0600, jorge ivan poot diaz wrote:
> >  If you want to locate the source code for a dialog/tab page/control,
> you  can export HELP_DEBUG=1 and enable  extended tooltips in the Tools
> Options dialog.
> 
> How I can do this?
> You could explain me step by step please.

You have to export this variable on the terminal you are going to run
OpenOffice, or add it to your ~/.bashrc

So, open a terminal, export the variable

export HELP_DEBUG=1

then launch OpenOffice from the command line, and enable extended tips:
Tools - Options - OpenOffice.org - General - Help - Tips - Extended tips


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgp1wyvbwoZgN.pgp
Description: PGP signature

Re: FormatArea Draw

2013-03-18 Thread jorge ivan poot diaz

>   What happened with this? Did you tried it?

no.


>  If you want to locate the source code for a dialog/tab page/control,
you  can export HELP_DEBUG=1 and enable  extended tooltips in the Tools
Options dialog.

How I can do this?
You could explain me step by step please.


2013/3/14 Ariel Constenla-Haile 

> On Thu, Mar 14, 2013 at 09:08:33PM -0600, jorge ivan poot diaz wrote:
> >Hello again,
> >
> >I have doubts about the Color dialog box: Attached the link below of
> the
> >color dialog
> >
> >http://imagebin.org/250306
>
> This seems the "Area" dialogs, it is made up of several tab pages. If
> you want to locate the source code for a dialog/tab page/control, you
> can export HELP_DEBUG=1 and enable extended tooltips in the Tools
> Options dialog. This way, when you rest the mouse on a control, you'll
> see the help id: http://people.apache.org/~arielch/images/HelpID_cui.png
> The help ID of this control in the screen shot,
> "cui:Edit:RID_SVXPAGE_COLOR:EDT_NAME", will help you find the src file:
>
>
> http://opengrok.adfinis-sygroup.org/source/search?q=%22cui%3AEdit%3ARID_SVXPAGE_COLOR%3AEDT_NAME%22&defs=&refs=&path=src&hist=&project=aoo-trunk
>
> Searching for the helpid of the whole tabe page, RID_SVXPAGE_COLOR you
> can find the src file, and the C++ code, if you narrow the search to the
> cui module:
>
>
> http://opengrok.adfinis-sygroup.org/source/search?q=RID_SVXPAGE_COLOR&defs=&refs=&path=cui&hist=&project=aoo-trunk
>
> So you see taht this Color tab page is implemented in the SvxColorTabPage
> class
>
> http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/cui/source/tabpages/tpcolor.cxx
>
>
> >I'm in the code window, so far I have this link:
> >
> >
> http://svn.services.openoffice.org/opengrok/xref/Current%20%28trunk%29/svtools/inc/svtools/colrdlg.hxx
> >
> >
> http://svn.services.openoffice.org/opengrok/xref/Current%20%28trunk%29/svtools/source/dialogs/colrdlg.cxx
>
> Don't use http://svn.services.openoffice.org/opengrok, is outdated. And
> this seems the code from the old color picker, not for the Color tab
> page.
>
> >
> >To register the colors,
> >What services are used?
>
> Debug the code in tpcolor.cxx, and pay attention to the part where you
> find the XColorTable.
>
>
> >If you want to see the creation of the other UI elements (menubar,
> >statusbar), break in framework::LayoutManager::createElement
>
> What happened with this? Did you tried it?
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>

Re: A question about existing practices

On Mon, Mar 18, 2013 at 11:32 AM, RGB ES  wrote:
> 2013/3/18 Rob Weir 
>
>> On Mon, Mar 18, 2013 at 10:11 AM, RGB ES  wrote:
>> > 2013/3/18 Jörg Schmidt 
>> >
>> >>
>> >>
>> >> > -Original Message-
>> >> > From: Rob Weir [mailto:robw...@apache.org]
>> >>
>> >> > I'd say, "Thanks for the suggestion.  We take all suggestions
>> >> > seriously, and user suggestions are often the source of ideas that
>> >> > make it into the product.  Thank you for using AOO."
>> >>
>> >> Sounds fine for me.
>> >>
>> >> > The title of the tread is "A question about existing practices".  I
>> >> > think the facts are quite clear.  If we have many 10 year old
>> >> > untouched BZ issues then fixing these issues is not part of our
>> >> > existing practice, whether you define that as mandatory, voluntary or
>> >> > whatever.
>> >>
>> >> No problem.
>> >>
>> >> > "Practice" is what we do, not what we talk about doing.
>> >>
>> >> Yes, but what we must be as clearly defined this user can foresee it.
>> >>
>> >> Why?
>> >> If I as a user know any bug in the program, it may be important for me
>> to
>> >> know _approximately_ when this will be fixed.
>> >>
>> >> > you want to argue that we talk a lot about fixing old issues, and say
>> >> > many solemn things about how important they are, then I would agree
>> >> > with you 100%.  But we don't actually do anything about them.
>> >>
>> >> I do not know how to define something should, but I know that you have
>> to
>> >> make it transparent.
>> >>
>> >> For example, a road map for developing the program is important because
>> it
>> >> clarifies what new features AOO will have in the future. That's right,
>> >> that's a good thing.
>> >>
>> >> But it is also important to clarify how to deal with bugs and feature
>> >> wishes of users.
>> >> There was the suggestion to delete all old votes, only we must still
>> >> clarify how we handle new votes. I think.
>> >>
>> >
>> > +1.
>> >
>> > There is an old joke: "I'm only responsible for what I say not for what
>> you
>> > understand", but the fact is that being AOO an end user application what
>> > our users understand IS important for us. And what will people understand
>> > if they know all those votes are being deleted? IMO, users will take this
>> > as "they do not care about our votes, why should I vote again? Why
>> should I
>> > fill a bug report that nobody reads?" and that's a really bad thing.
>> >
>>
>> They'll believe what we tell them.  If we say that we're "resetting"
>> the vote counts in order to determine what is most relevant to users
>> today, starting with an unbiased and fresh view of today's users
>> priorities, and not to over-advantage the dead hand of decade-old
>> votes from users who may or may not even still be using OpenOffice
>> today, then this will be seen as a good thing.
>>
>> > If you want to know how relevant old issues are, once we have a working
>> > survey system we can start a series of surveys about most wanted features
>> > requests. IMO, the only valid way to delete votes, the only way that show
>> > respect to our users is to close the corresponding issues.
>> >
>>
>> The fact that there are decade old issues demonstrates that they are
>> not relevant at all.
>
>
> The fact that there are decade old issues only demonstrate they are still
> unresolved: nothing more, nothing less. Are you saying the request to
> provide support for opentype features is obsolete only because nobody
> solved it since the issue was filled on 2003, and that we need to trash the
> more than 200 votes for it? Sorry, but that makes no sense...


Yes, that is exactly what I am saying.   If you want to argue the
contrary you would need to explain what the relevance is of issues
that are 10-years old and have not been touched and probably never
will be.  I might as well keep in a box my letters to Santa Claus from
when I was a child, in hopes that they may be someday delivered.  If
something has not been touched for 10 years this is an extremely
strong indication that it is irrelevant.  Things that are important
tend to be done.  Things that are not important do not get done.   I
know of no other measure for determining this.

-Rob


>
> The lack of a split view is also a very old issue that's still relevant, as
> well as the "reveal codes" mentioned by Dennis (even if I do not need it,
> many people want it and every now and then someone ask for that on the
> forums). Styles for tables? And for Math objects?... may I continue?
>
> The point is that all the above mentioned request are really difficult
> tasks, and that alone justify the fact they are still unresolved. Even if
> there are requests that are not valid any more, and it's quite possible
> that there are lots of such requests, dropping a nuke to kill user's
> feedback on every single old issue is not a good thing to do, IMO.
>
> Just my last 2¢ from today (taking a break from this thread)
>
> Regards
> Ricardo
>
>
>
>> I can't think of any test of irrelevan

Re: German conference on free office suites and on OpenDocument in April 2013 - "OpenDocument-Kongress für Wirtschaft und Verwaltung"

2013-03-18 Thread Oliver-Rainer Wittmann


Hi,

I am planning attend this event.
Who else from our project is planning to attend?

Best regards, Oliver.

On 26.02.2013 12:38, Oliver-Rainer Wittmann wrote:

Hi,

I just want to let you know the following:

On the 10th and 11th of April 2013 a German conference on free office
suites and on OpenDocument is taking place in Berlin [1] - it is the
"OpenDocument-Kongress für Wirtschaft und Verwaltung".
There conference language will be German and is refered to
representatives from German businesses and public authorities which are
using or want to use free office produtivity software and/or the
OpenDocument file format.
Topics of the conference according to the call for paper [2] are:
- LibreOffice/OpenOffice in the use at business and public administration
- Increase of the productivity via field-centric extensions for
LibreOffice/OpenOffice
- Decision process on chosing an office suite, decision support , Pros/Cons
- ODF or OOXML as the document format of the future?!
- Using LibreOffice/OpenOffice and Microsoft Office together in a company
- Support for LibreOffice/OpenOffice (Backend- and User-Support)
- Migration paths regarding office suites
- Collaboration with LibreOffice/OpenOffice (in the web)
- Document management and LibreOffice/OpenOffice
- Usage of LibreOffice/OpenOffice
- Trainings, Concepts, Experiences
- E-Learning offers (LibO/OO-training on demand)

The conference is organised by "Freies Office Deutschland e. V." - a
German non-profit association which is supporting free software in the
area of office productivity.

I had been personally contacted by one of the organisers regarding this
conference, but I thought that there might be more people from our
project interested to attend such an event.


[1] http://www.frodev.org/konferenz
[2] http://www.frodev.org/downloads/oeffentlich/CfP_OOoKWV_2013.pdf


Best regards, Oliver


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

[PUBLIC TALK] request for input for my talk "Apache OpenOffice - project status and release 4.0"

2013-03-18 Thread Oliver-Rainer Wittmann

Hi,

sorry for cross-posting - I want to reach all of you almost directly.
Please reply to dev@openoffice.apache.org.

I will give a talk on a German conference about Apache OpenOffice in mid
April 2013 in Berlin. I had already mentioned this German conference in
an earlier post [1]. The conference is about free office suite, mainly
focused on Apache OpenOffice and LibreOffice, and the OpenDocument file
format.
The title of my talk is "Apache OpenOffice - project status and release
4.0".

In the first part I will present the continuation of the project at
Apache and the actual project status. Some general remarks on the
project structure and processes ("The Apache Way") will be included, I
think. The main purpose of this part is to demonstrate how well
OpenOffice evolves at Apache since the change the project had suffered
in mid 2011. This will strengthen the confidence/trust in the project.

The second part is about our planned 4.0 release. The intention of this
part is to show how active the development of the product and the
project is by talking about the changes and improvements we had made/are
making for our planned 4.0 release.

Now my _big_ request to you _all_.
I am only one person and I have more or less a developer view on the
product and the project. E.g., I am not active on all our mailing lists.
On certain areas I have no deep insight.
Thus, please provide me with information about the stuff that is going
on in your area of interest.

What are the key milestones which you had achieved for the project?
What are your contributions for our coming 4.0 release?
[If wanted I can name the corresponding contributor(s) in the
presentation document.]
The talk's length is 45 min. (30 min talk, 15 min Q&A) - I am able to
fill the presentation with the stuff I know, but I strongly believe that
in this case certain important stuff and details about the
product/project will missing.

I will collect all your input and I will fill a wiki page with the
summarized information. My presentation document will of course be
available for further usage. If the presentation document will not be
created at the last minute, I will also provide drafts of it for review
and feedback.

I am looking forward for your input.

[1]
http://mail-archives.apache.org/mod_mbox/openoffice-dev/201302.mbox/%3C512C9ED2.70601%40googlemail.com%3E

Big Thanks in advance,
Oliver.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Forums down (SQL error: Too many connections [1040])

2013-03-18 Thread RGB ES

Right now, EN and ES forums are quite unstable, giving the "too many
connections" error every now and then, and being quite slow the rest of the
time.


2013/3/18 FR web forum 

> Still at the same period (since 11:00am this monday).
>
> >But, this morning 11:00am (UTC+1), the FR forum is slow again.
>
> >>> Maybe the MySQL max_connections parameter must be increase.
> >Do you have check this point?
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: A question about existing practices

2013-03-18 Thread RGB ES

2013/3/18 Rob Weir 

> On Mon, Mar 18, 2013 at 10:11 AM, RGB ES  wrote:
> > 2013/3/18 Jörg Schmidt 
> >
> >>
> >>
> >> > -Original Message-
> >> > From: Rob Weir [mailto:robw...@apache.org]
> >>
> >> > I'd say, "Thanks for the suggestion.  We take all suggestions
> >> > seriously, and user suggestions are often the source of ideas that
> >> > make it into the product.  Thank you for using AOO."
> >>
> >> Sounds fine for me.
> >>
> >> > The title of the tread is "A question about existing practices".  I
> >> > think the facts are quite clear.  If we have many 10 year old
> >> > untouched BZ issues then fixing these issues is not part of our
> >> > existing practice, whether you define that as mandatory, voluntary or
> >> > whatever.
> >>
> >> No problem.
> >>
> >> > "Practice" is what we do, not what we talk about doing.
> >>
> >> Yes, but what we must be as clearly defined this user can foresee it.
> >>
> >> Why?
> >> If I as a user know any bug in the program, it may be important for me
> to
> >> know _approximately_ when this will be fixed.
> >>
> >> > you want to argue that we talk a lot about fixing old issues, and say
> >> > many solemn things about how important they are, then I would agree
> >> > with you 100%.  But we don't actually do anything about them.
> >>
> >> I do not know how to define something should, but I know that you have
> to
> >> make it transparent.
> >>
> >> For example, a road map for developing the program is important because
> it
> >> clarifies what new features AOO will have in the future. That's right,
> >> that's a good thing.
> >>
> >> But it is also important to clarify how to deal with bugs and feature
> >> wishes of users.
> >> There was the suggestion to delete all old votes, only we must still
> >> clarify how we handle new votes. I think.
> >>
> >
> > +1.
> >
> > There is an old joke: "I'm only responsible for what I say not for what
> you
> > understand", but the fact is that being AOO an end user application what
> > our users understand IS important for us. And what will people understand
> > if they know all those votes are being deleted? IMO, users will take this
> > as "they do not care about our votes, why should I vote again? Why
> should I
> > fill a bug report that nobody reads?" and that's a really bad thing.
> >
>
> They'll believe what we tell them.  If we say that we're "resetting"
> the vote counts in order to determine what is most relevant to users
> today, starting with an unbiased and fresh view of today's users
> priorities, and not to over-advantage the dead hand of decade-old
> votes from users who may or may not even still be using OpenOffice
> today, then this will be seen as a good thing.
>
> > If you want to know how relevant old issues are, once we have a working
> > survey system we can start a series of surveys about most wanted features
> > requests. IMO, the only valid way to delete votes, the only way that show
> > respect to our users is to close the corresponding issues.
> >
>
> The fact that there are decade old issues demonstrates that they are
> not relevant at all.


The fact that there are decade old issues only demonstrate they are still
unresolved: nothing more, nothing less. Are you saying the request to
provide support for opentype features is obsolete only because nobody
solved it since the issue was filled on 2003, and that we need to trash the
more than 200 votes for it? Sorry, but that makes no sense...

The lack of a split view is also a very old issue that's still relevant, as
well as the "reveal codes" mentioned by Dennis (even if I do not need it,
many people want it and every now and then someone ask for that on the
forums). Styles for tables? And for Math objects?... may I continue?

The point is that all the above mentioned request are really difficult
tasks, and that alone justify the fact they are still unresolved. Even if
there are requests that are not valid any more, and it's quite possible
that there are lots of such requests, dropping a nuke to kill user's
feedback on every single old issue is not a good thing to do, IMO.

Just my last 2¢ from today (taking a break from this thread)

Regards
Ricardo



> I can't think of any test of irrelevancy more
> accurate than pointing out that they have been ignored for over 10
> years.
>
> My suggestion was merely a way of getting feedback that might be more
> relevant.  But that's fine.  If we're more comfortable claiming that
> decade-old untouched issues are sacred to the project, then that's OK.
>  They can just as easily be ignored for another decade.  We have
> better means, like Google Moderator, or surveys, for finding out what
> users actually think today.
>
> -Rob
>
> > Just my 2¢
> >
> > Regards
> > Ricardo
> >
> >
> >>
> >>
> >> Greetings,
> >> Jörg
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@op

Re: A question about existing practices

On Mon, Mar 18, 2013 at 11:12 AM, Dennis E. Hamilton  wrote:
> From my perspective, Jörg's concern is very simple.
>
> There are actions and arrangements that have been made that encourage certain 
> expectations in the mind of persons who participate and contribute in various 
> ways.  And when those expectations are unsatisfied, that leads to assessments 
> and opinions about the project.
>
> The Apache OpenOffice project could take responsibility for the fact that 
> some aspects of our structures do encourage such expectations.  A possible 
> approach is to remove something that establishes expectations that there is 
> no desire to see as creating any commitment on the part of the project.   
> Having voting buttons is an example.  Another possibility would be to add 
> more transparency and visibility to the stuck issues that have received many 
> votes and that are not going anywhere (and the rationale for that).
>

Oh, no.  Buttons are very useful, even if they do nothing.  This has
been experimentally verified.  In fact, some towns now have buttons at
crosswalks that do absolutely nothing.  But the people waiting for the
light to change are happier having a button to press, thinking that it
actually makes the light change faster.  So expectations are
important.  I don't doubt that.

> In other situations, there is immediate action and sometimes abrupt action 
> taken to clarify a mistaken expectation.  Someone who wants telephone contact 
> from a support person, or who has some other demand is usually 
> straightened-out immediately, even though bouncing someone to the Forums or 
> users @o.a.o for "support" is sometimes rather circumspect.  Folks who think 
> posts to lists are private communications are dissuaded of that.
>
> Of course, participants and observers take away whatever impressions of the 
> AOO project that they do.  In some case, it is important to accept that our 
> arrangements contribute to some of those and that it is in our hands to find 
> a responsible adjustment.
>
> I am not lobbying for a particular resolution (no guessing, please).  I do 
> think that the situation deserves recognition and not deflection.
>
>  - Dennis
>
> PS: My all-time favorite unreconcilable voted-for issue is the request for 
> "Reveal Codes" in the manner of WordPerfect.
>
> -Original Message-
> From: Rob Weir [mailto:robw...@apache.org]
> Sent: Monday, March 18, 2013 06:13
> To: dev@openoffice.apache.org
> Subject: Re: A question about existing practices
>
> On Mon, Mar 18, 2013 at 8:49 AM, Jörg Schmidt  wrote:
>>
>>> From: Rob Weir [mailto:robw...@apache.org]
>>> A promise to do what?
>>
>> The opinion of the user to be taken seriously because you have asked him to 
>> speak his mind.
>>
>>> But a feature request?
>>
>> This is an opinion of our users. It should be important to us.
> [ ... ]
>> It's about respect for what we bring to our users, because it is a 
>> fundamental difference between what we need to do and what we should do so 
>> voluntarily.
>>
>
> The title of the tread is "A question about existing practices".  I
> think the facts are quite clear.  If we have many 10 year old
> untouched BZ issues then fixing these issues is not part of our
> existing practice, whether you define that as mandatory, voluntary or
> whatever.  "Practice" is what we do, not what we talk about doing.  If
> you want to argue that we talk a lot about fixing old issues, and say
> many solemn things about how important they are, then I would agree
> with you 100%.  But we don't actually do anything about them.
>
> [ ... ]
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: A question about existing practices

2013-03-18 Thread Dennis E. Hamilton

>From my perspective, Jörg's concern is very simple.

There are actions and arrangements that have been made that encourage certain 
expectations in the mind of persons who participate and contribute in various 
ways.  And when those expectations are unsatisfied, that leads to assessments 
and opinions about the project.

The Apache OpenOffice project could take responsibility for the fact that some 
aspects of our structures do encourage such expectations.  A possible approach 
is to remove something that establishes expectations that there is no desire to 
see as creating any commitment on the part of the project.   Having voting 
buttons is an example.  Another possibility would be to add more transparency 
and visibility to the stuck issues that have received many votes and that are 
not going anywhere (and the rationale for that).

In other situations, there is immediate action and sometimes abrupt action 
taken to clarify a mistaken expectation.  Someone who wants telephone contact 
from a support person, or who has some other demand is usually straightened-out 
immediately, even though bouncing someone to the Forums or users @o.a.o for 
"support" is sometimes rather circumspect.  Folks who think posts to lists are 
private communications are dissuaded of that.

Of course, participants and observers take away whatever impressions of the AOO 
project that they do.  In some case, it is important to accept that our 
arrangements contribute to some of those and that it is in our hands to find a 
responsible adjustment.

I am not lobbying for a particular resolution (no guessing, please).  I do 
think that the situation deserves recognition and not deflection.

 - Dennis

PS: My all-time favorite unreconcilable voted-for issue is the request for 
"Reveal Codes" in the manner of WordPerfect.

-Original Message-
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Monday, March 18, 2013 06:13
To: dev@openoffice.apache.org
Subject: Re: A question about existing practices

On Mon, Mar 18, 2013 at 8:49 AM, Jörg Schmidt  wrote:
>
>> From: Rob Weir [mailto:robw...@apache.org]
>> A promise to do what?
>
> The opinion of the user to be taken seriously because you have asked him to 
> speak his mind.
>
>> But a feature request?
>
> This is an opinion of our users. It should be important to us.
[ ... ]
> It's about respect for what we bring to our users, because it is a 
> fundamental difference between what we need to do and what we should do so 
> voluntarily.
>

The title of the tread is "A question about existing practices".  I
think the facts are quite clear.  If we have many 10 year old
untouched BZ issues then fixing these issues is not part of our
existing practice, whether you define that as mandatory, voluntary or
whatever.  "Practice" is what we do, not what we talk about doing.  If
you want to argue that we talk a lot about fixing old issues, and say
many solemn things about how important they are, then I would agree
with you 100%.  But we don't actually do anything about them.

[ ... ]

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: A question about existing practices

On Mon, Mar 18, 2013 at 10:11 AM, RGB ES  wrote:
> 2013/3/18 Jörg Schmidt 
>
>>
>>
>> > -Original Message-
>> > From: Rob Weir [mailto:robw...@apache.org]
>>
>> > I'd say, "Thanks for the suggestion.  We take all suggestions
>> > seriously, and user suggestions are often the source of ideas that
>> > make it into the product.  Thank you for using AOO."
>>
>> Sounds fine for me.
>>
>> > The title of the tread is "A question about existing practices".  I
>> > think the facts are quite clear.  If we have many 10 year old
>> > untouched BZ issues then fixing these issues is not part of our
>> > existing practice, whether you define that as mandatory, voluntary or
>> > whatever.
>>
>> No problem.
>>
>> > "Practice" is what we do, not what we talk about doing.
>>
>> Yes, but what we must be as clearly defined this user can foresee it.
>>
>> Why?
>> If I as a user know any bug in the program, it may be important for me to
>> know _approximately_ when this will be fixed.
>>
>> > you want to argue that we talk a lot about fixing old issues, and say
>> > many solemn things about how important they are, then I would agree
>> > with you 100%.  But we don't actually do anything about them.
>>
>> I do not know how to define something should, but I know that you have to
>> make it transparent.
>>
>> For example, a road map for developing the program is important because it
>> clarifies what new features AOO will have in the future. That's right,
>> that's a good thing.
>>
>> But it is also important to clarify how to deal with bugs and feature
>> wishes of users.
>> There was the suggestion to delete all old votes, only we must still
>> clarify how we handle new votes. I think.
>>
>
> +1.
>
> There is an old joke: "I'm only responsible for what I say not for what you
> understand", but the fact is that being AOO an end user application what
> our users understand IS important for us. And what will people understand
> if they know all those votes are being deleted? IMO, users will take this
> as "they do not care about our votes, why should I vote again? Why should I
> fill a bug report that nobody reads?" and that's a really bad thing.
>

They'll believe what we tell them.  If we say that we're "resetting"
the vote counts in order to determine what is most relevant to users
today, starting with an unbiased and fresh view of today's users
priorities, and not to over-advantage the dead hand of decade-old
votes from users who may or may not even still be using OpenOffice
today, then this will be seen as a good thing.

> If you want to know how relevant old issues are, once we have a working
> survey system we can start a series of surveys about most wanted features
> requests. IMO, the only valid way to delete votes, the only way that show
> respect to our users is to close the corresponding issues.
>

The fact that there are decade old issues demonstrates that they are
not relevant at all.  I can't think of any test of irrelevancy more
accurate than pointing out that they have been ignored for over 10
years.

My suggestion was merely a way of getting feedback that might be more
relevant.  But that's fine.  If we're more comfortable claiming that
decade-old untouched issues are sacred to the project, then that's OK.
 They can just as easily be ignored for another decade.  We have
better means, like Google Moderator, or surveys, for finding out what
users actually think today.

-Rob

> Just my 2¢
>
> Regards
> Ricardo
>
>
>>
>>
>> Greetings,
>> Jörg
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: A question about existing practices

2013-03-18 Thread RGB ES

2013/3/18 Jörg Schmidt 

>
>
> > -Original Message-
> > From: Rob Weir [mailto:robw...@apache.org]
>
> > I'd say, "Thanks for the suggestion.  We take all suggestions
> > seriously, and user suggestions are often the source of ideas that
> > make it into the product.  Thank you for using AOO."
>
> Sounds fine for me.
>
> > The title of the tread is "A question about existing practices".  I
> > think the facts are quite clear.  If we have many 10 year old
> > untouched BZ issues then fixing these issues is not part of our
> > existing practice, whether you define that as mandatory, voluntary or
> > whatever.
>
> No problem.
>
> > "Practice" is what we do, not what we talk about doing.
>
> Yes, but what we must be as clearly defined this user can foresee it.
>
> Why?
> If I as a user know any bug in the program, it may be important for me to
> know _approximately_ when this will be fixed.
>
> > you want to argue that we talk a lot about fixing old issues, and say
> > many solemn things about how important they are, then I would agree
> > with you 100%.  But we don't actually do anything about them.
>
> I do not know how to define something should, but I know that you have to
> make it transparent.
>
> For example, a road map for developing the program is important because it
> clarifies what new features AOO will have in the future. That's right,
> that's a good thing.
>
> But it is also important to clarify how to deal with bugs and feature
> wishes of users.
> There was the suggestion to delete all old votes, only we must still
> clarify how we handle new votes. I think.
>

+1.

There is an old joke: "I'm only responsible for what I say not for what you
understand", but the fact is that being AOO an end user application what
our users understand IS important for us. And what will people understand
if they know all those votes are being deleted? IMO, users will take this
as "they do not care about our votes, why should I vote again? Why should I
fill a bug report that nobody reads?" and that's a really bad thing.

If you want to know how relevant old issues are, once we have a working
survey system we can start a series of surveys about most wanted features
requests. IMO, the only valid way to delete votes, the only way that show
respect to our users is to close the corresponding issues.

Just my 2¢

Regards
Ricardo


>
>
> Greetings,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: A question about existing practices

 

> -Original Message-
> From: Rob Weir [mailto:robw...@apache.org] 

> I'd say, "Thanks for the suggestion.  We take all suggestions
> seriously, and user suggestions are often the source of ideas that
> make it into the product.  Thank you for using AOO."

Sounds fine for me.

> The title of the tread is "A question about existing practices".  I
> think the facts are quite clear.  If we have many 10 year old
> untouched BZ issues then fixing these issues is not part of our
> existing practice, whether you define that as mandatory, voluntary or
> whatever. 

No problem.

> "Practice" is what we do, not what we talk about doing. 

Yes, but what we must be as clearly defined this user can foresee it.

Why?
If I as a user know any bug in the program, it may be important for me to know 
_approximately_ when this will be fixed.

> you want to argue that we talk a lot about fixing old issues, and say
> many solemn things about how important they are, then I would agree
> with you 100%.  But we don't actually do anything about them.

I do not know how to define something should, but I know that you have to make 
it transparent.

For example, a road map for developing the program is important because it 
clarifies what new features AOO will have in the future. That's right, that's a 
good thing.

But it is also important to clarify how to deal with bugs and feature wishes of 
users.
There was the suggestion to delete all old votes, only we must still clarify 
how we handle new votes. I think.


Greetings,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: A question about existing practices

On Mon, Mar 18, 2013 at 8:49 AM, Jörg Schmidt  wrote:
>
>> From: Rob Weir [mailto:robw...@apache.org]
>> A promise to do what?
>
> The opinion of the user to be taken seriously because you have asked him to 
> speak his mind.
>
>> But a feature request?
>
> This is an opinion of our users. It should be important to us.
>
>> I see zero obligation, legal, [...], social,
>> or otherwise, for us to do anything other than say, "Thank you for the
>> suggestion".
>
> Yes, this is formally correct, but you do not notice it much here depends on 
> the tone of voice?
>
> ("the tone of voice" --> in german i mean: es kommt auf den Tonfall an mit 
> dem wir öffentlich etwas sagen)
>
>> moral
>
> I think so.
> It's about respect for what we bring to our users, because it is a 
> fundamental difference between what we need to do and what we should do so 
> voluntarily.
>

The title of the tread is "A question about existing practices".  I
think the facts are quite clear.  If we have many 10 year old
untouched BZ issues then fixing these issues is not part of our
existing practice, whether you define that as mandatory, voluntary or
whatever.  "Practice" is what we do, not what we talk about doing.  If
you want to argue that we talk a lot about fixing old issues, and say
many solemn things about how important they are, then I would agree
with you 100%.  But we don't actually do anything about them.

>> > It is not the problem of the user in evaluating old Votes
>> Votes unlike new, because we have no contract with the user,
>> but it's about credibility, our credibility.
>> >
>>
>> We need to set the right expectations.  If we set expectations that we
>> are all supermen and can write C++ code in our sleep, and our cats can
>> write Java code while playing with balls of yarn, then yes we will
>> lose credibility.  But a different kind of credibility is the kind
>> that attracts developers, which is saying that developers on the
>> project work on the features that are important to them, and the
>> direction of the project is determined by the collective priorities of
>> those who are doing the actual work.  That kind of credibility is a
>> very important kind, since that is what helps us recruit developers.
>
> Once again: this is not controversial.
>
> Dispute seems to me that we should find right words to our users if we 
> justify that.
>

I'd say, "Thanks for the suggestion.  We take all suggestions
seriously, and user suggestions are often the source of ideas that
make it into the product.  Thank you for using AOO."

> There is (imho) a great difference whether we say we can not, or whether we 
> say the user would have no right.
>
> An example of what I mean:
> If I had a business and sell something, it may be I've just not all at the 
> warehouse thing a customer, the customer then I will _ask for understanding_, 
> but I will _not tell him he had no right_ to buy a certain product 
> immediately .
>
> In AOO we do not sell product, but we are still committed to our credibility, 
> and even a little for the credibility of free software.
>
> This is my opinion.
>
>> Of course, if we don't make a product that users want, then we become
>> irrelevant.
>
> Yes, that's the point.
>
>> But a look at our popularity via download numbers shows
>> that we are highly relevant,
>
> And how do we evaluate, for example, that one of the biggest public users of 
> OpenOffice, the city of Munich, has declared to want to switch to LibreOffice?
> (see: http://www.it-muenchen-blog.de/2012/10/libre-office-fur-munchen/)
>
> This is (imho) a big loss for AOO.
>

But I hope you would agree that what we did or did not do to 10-year
old Bugzilla issues was irrelevant to their decision.

-Rob

>
> Greetings,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: A question about existing practices

On 3/18/13 1:49 PM, Jörg Schmidt wrote:
>  
>> From: Rob Weir [mailto:robw...@apache.org] 
>> A promise to do what?   
> 
> The opinion of the user to be taken seriously because you have asked him to 
> speak his mind.
> 
>> But a feature request?  
> 
> This is an opinion of our users. It should be important to us.
> 
>> I see zero obligation, legal, [...], social,
>> or otherwise, for us to do anything other than say, "Thank you for the
>> suggestion".
> 
> Yes, this is formally correct, but you do not notice it much here depends on 
> the tone of voice?
> 
> ("the tone of voice" --> in german i mean: es kommt auf den Tonfall an mit 
> dem wir öffentlich etwas sagen)
> 
>> moral
> 
> I think so.
> It's about respect for what we bring to our users, because it is a 
> fundamental difference between what we need to do and what we should do so 
> voluntarily.
> 
>>> It is not the problem of the user in evaluating old Votes 
>> Votes unlike new, because we have no contract with the user, 
>> but it's about credibility, our credibility.
>>>
>>
>> We need to set the right expectations.  If we set expectations that we
>> are all supermen and can write C++ code in our sleep, and our cats can
>> write Java code while playing with balls of yarn, then yes we will
>> lose credibility.  But a different kind of credibility is the kind
>> that attracts developers, which is saying that developers on the
>> project work on the features that are important to them, and the
>> direction of the project is determined by the collective priorities of
>> those who are doing the actual work.  That kind of credibility is a
>> very important kind, since that is what helps us recruit developers.
> 
> Once again: this is not controversial.
> 
> Dispute seems to me that we should find right words to our users if we 
> justify that.
> 
> There is (imho) a great difference whether we say we can not, or whether we 
> say the user would have no right.
> 
> An example of what I mean:
> If I had a business and sell something, it may be I've just not all at the 
> warehouse thing a customer, the customer then I will _ask for understanding_, 
> but I will _not tell him he had no right_ to buy a certain product 
> immediately .
> 
> In AOO we do not sell product, but we are still committed to our credibility, 
> and even a little for the credibility of free software.
> 
> This is my opinion.
> 
>> Of course, if we don't make a product that users want, then we become
>> irrelevant.  
> 
> Yes, that's the point.
> 
>> But a look at our popularity via download numbers shows
>> that we are highly relevant, 
> 
> And how do we evaluate, for example, that one of the biggest public users of 
> OpenOffice, the city of Munich, has declared to want to switch to LibreOffice?
> (see: http://www.it-muenchen-blog.de/2012/10/libre-office-fur-munchen/)

this can happened at any time and it depends on the decision makers of
the related project. In this case the decision was probably made when
the future of OpenOffice was not so clear as it is at the moment. And
Munich paid for some development work to improve the OOXML support via
the OSBA initiative. We all know that these work is not available in AOO.

> 
> This is (imho) a big loss for AOO.

if we make the better product in the long term they will potentially
switch back. For now we have no complete story for OOXML and on the
other hand LO can pick all the nice improvements that we will introduce.
And I am sure they will, they mirror our repo on a regular basis and do
cherry picking. They will probably continue to deny this or at least not
mention it in public but that is a different issue that don't help open
source in general.

Juergen

> 
> 
> Greetings,
> Jörg
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: A question about existing practices

 
> From: Rob Weir [mailto:robw...@apache.org] 
> A promise to do what?   

The opinion of the user to be taken seriously because you have asked him to 
speak his mind.

> But a feature request?  

This is an opinion of our users. It should be important to us.

> I see zero obligation, legal, [...], social,
> or otherwise, for us to do anything other than say, "Thank you for the
> suggestion".

Yes, this is formally correct, but you do not notice it much here depends on 
the tone of voice?

("the tone of voice" --> in german i mean: es kommt auf den Tonfall an mit dem 
wir öffentlich etwas sagen)

> moral

I think so.
It's about respect for what we bring to our users, because it is a fundamental 
difference between what we need to do and what we should do so voluntarily.

> > It is not the problem of the user in evaluating old Votes 
> Votes unlike new, because we have no contract with the user, 
> but it's about credibility, our credibility.
> >
> 
> We need to set the right expectations.  If we set expectations that we
> are all supermen and can write C++ code in our sleep, and our cats can
> write Java code while playing with balls of yarn, then yes we will
> lose credibility.  But a different kind of credibility is the kind
> that attracts developers, which is saying that developers on the
> project work on the features that are important to them, and the
> direction of the project is determined by the collective priorities of
> those who are doing the actual work.  That kind of credibility is a
> very important kind, since that is what helps us recruit developers.

Once again: this is not controversial.

Dispute seems to me that we should find right words to our users if we justify 
that.

There is (imho) a great difference whether we say we can not, or whether we say 
the user would have no right.

An example of what I mean:
If I had a business and sell something, it may be I've just not all at the 
warehouse thing a customer, the customer then I will _ask for understanding_, 
but I will _not tell him he had no right_ to buy a certain product immediately .

In AOO we do not sell product, but we are still committed to our credibility, 
and even a little for the credibility of free software.

This is my opinion.

> Of course, if we don't make a product that users want, then we become
> irrelevant.  

Yes, that's the point.

> But a look at our popularity via download numbers shows
> that we are highly relevant, 

And how do we evaluate, for example, that one of the biggest public users of 
OpenOffice, the city of Munich, has declared to want to switch to LibreOffice?
(see: http://www.it-muenchen-blog.de/2012/10/libre-office-fur-munchen/)

This is (imho) a big loss for AOO.


Greetings,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [Call-for-Review] code changes for more powerful smarttag extensions

2013-03-18 Thread TJ Frazier



Feel free to cross-link or add comments.
/tj/

On 3/18/2013 03:45, Jürgen Schmidt wrote:

On 3/17/13 11:27 PM, TJ Frazier wrote:

... I also noticed that when you zoom a text document the lines for
redlining as well as for smarttags, etc. are not zoomed in the same way
and makes it less visible. But this seems to be a general issue.

Juergen


Hi, Jürgen,

This is one of my pet peeves. The major problem seems to be the line
thickness, which corresponds to the glyph property "stroke weight". The
un-zoomed skinny line just disappears at high zoom factors. Do you want
me to file an issue in BZ on this?


Having an issue for this is definitely a good idea.

Thanks

Juergen




/tj/




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: A question about existing practices

On Mon, Mar 18, 2013 at 7:03 AM, Jörg Schmidt  wrote:
>
>> -Original Message-
>> From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com]
>> Sent: Monday, March 18, 2013 11:41 AM
>> To: dev@openoffice.apache.org
>> Subject: Re: A question about existing practices
>>
>> Hi,
>>
>> sorry, for top-posting, but I have a general remark.
>>
>>  From my point of view the discussion on this thread went
>> into the wrong
>> direction.
>> I think Jörg just mentioned issue 3959 as an _example_ for
>> feedback from
>> users regarding feature requests via Bugzilla votes. I also
>> think that
>> Jörg mentioned Bugzilla votes also only as an _example_ for
>> such kind of
>> user feedback.
>
> Exactly.
>
> What is important for me to say that when we make promise users (directly or 
> indirectly) so we have to deliver.
>
> A vote button is an indirect promise (because why the user should vote, 
> except that it has the relevance).

A promise to do what?   I think the existing practice is rather
unambiguous.  If we have 10 year old issues with high vote counts,
that means that the project never treated votes as a promise to
implement the requests.

> Likewise, it is a promise that we BZ ever offer, because if we ask users to 
> tell us problems, we are also obliged to take care of their communications. 
> (not legally, but morally)
>

If a use has a problem with an existing feature, where it is not
working as it was designed to work, or intended to work, then yes, we
should help the user.  If there is a bug, then we should fix the bug.
Of course, with many defect reports we'll naturally focus on the most
severe ones.  And in practice this means that there may be some
trivial bugs that never get fixed.

But a feature request?  I see zero obligation, legal, moral, social,
or otherwise, for us to do anything other than say, "Thank you for the
suggestion".

> It is not the problem of the user in evaluating old Votes Votes unlike new, 
> because we have no contract with the user, but it's about credibility, our 
> credibility.
>

We need to set the right expectations.  If we set expectations that we
are all supermen and can write C++ code in our sleep, and our cats can
write Java code while playing with balls of yarn, then yes we will
lose credibility.  But a different kind of credibility is the kind
that attracts developers, which is saying that developers on the
project work on the features that are important to them, and the
direction of the project is determined by the collective priorities of
those who are doing the actual work.  That kind of credibility is a
very important kind, since that is what helps us recruit developers.

Of course, if we don't make a product that users want, then we become
irrelevant.  But a look at our popularity via download numbers shows
that we are highly relevant, even though some 10-year old feature
ideas are ignored.

In any case, "volunteers" and "obligations" do not match.  If we
really want to lose volunteers then we should tell them that they have
the obligation to follow the priorities of 10 year old votes.

-Rob

>
> Greetings,
> Jörg
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

[QA Report]Weekly Defect Analysis

2013-03-18 Thread Ji Yan

Hi all,

  Here is defect analysis for last week(3/10 ~ 3/17).

http://wiki.openoffice.org/wiki/QA/Report/DefectStatus/20130318

-- 


Thanks & Best Regards, Yan Ji

Re: A question about existing practices


> -Original Message-
> From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com] 
> Sent: Monday, March 18, 2013 11:41 AM
> To: dev@openoffice.apache.org
> Subject: Re: A question about existing practices
> 
> Hi,
> 
> sorry, for top-posting, but I have a general remark.
> 
>  From my point of view the discussion on this thread went 
> into the wrong 
> direction.
> I think Jörg just mentioned issue 3959 as an _example_ for 
> feedback from 
> users regarding feature requests via Bugzilla votes. I also 
> think that 
> Jörg mentioned Bugzilla votes also only as an _example_ for 
> such kind of 
> user feedback.

Exactly.

What is important for me to say that when we make promise users (directly or 
indirectly) so we have to deliver.

A vote button is an indirect promise (because why the user should vote, except 
that it has the relevance).
Likewise, it is a promise that we BZ ever offer, because if we ask users to 
tell us problems, we are also obliged to take care of their communications. 
(not legally, but morally)

It is not the problem of the user in evaluating old Votes Votes unlike new, 
because we have no contract with the user, but it's about credibility, our 
credibility.


Greetings,
Jörg



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Forums down (SQL error: Too many connections [1040])

2013-03-18 Thread FR web forum

Still at the same period (since 11:00am this monday).

>But, this morning 11:00am (UTC+1), the FR forum is slow again.

>>> Maybe the MySQL max_connections parameter must be increase.
>Do you have check this point?


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: A question about existing practices

2013-03-18 Thread Oliver-Rainer Wittmann


Hi,

sorry, for top-posting, but I have a general remark.

From my point of view the discussion on this thread went into the wrong 
direction.
I think Jörg just mentioned issue 3959 as an _example_ for feedback from 
users regarding feature requests via Bugzilla votes. I also think that 
Jörg mentioned Bugzilla votes also only as an _example_ for such kind of 
user feedback.


My perspective on Jörg's intention for starting this thread is to 
discuss the following questions:

- How should we handle feedback from users regarding feature requests?
- Should we define/establish one or more processes for users to provide 
their feedback for feature requests?
- If the users' feedback reflects their demands and if we think we 
should take these demands seriously, how can we support/show ways that 
these demands are fullfilled?


Thus, in my opinion we should not stress the one or the other issue or 
the Bugzilla voting system. We should more discuss the general issue 
regarding the users' feedback regarding feature requests to our product 
and how we want to react on it.



Best regards, Oliver.

On 14.03.2013 09:56, Jörg Schmidt wrote:

Hello,

By a request in the forum
(http://de.openoffice.info/viewtopic.php?f=1&t=61365), I get the
information, the Issue #3959 was not implemented since 2002, although
he has already received 355 votes.

(Note: the implementation of the issues is not particularly important
to me, I personally have not even voted for it.)

I know it, earlier in OpenOffice, org, not practice was unfortunately
votes cast for issues as direct, binding standard for their
implementation to consider, But how is that today?.

It is clear to me the AOO is created by volunteers who choose their
detailed tasks themselves, but should we not also be a concern comply
with the interests of the users of AOO? That would not only be of
practical benefit to users, but would also enhance the reputation of
AOO, as in the practice oriented project.

Why the latter is important? I think because of the positive
reputation of AOO in public grow the number of our supporters
(sponsors, supporters, developers) will be.

My view: We should not emulate LibreOffice because LibreOffice may be
innovative, but public statements about quality and consistency of
LibreOffice are devastating. For example, the chairman of the FroDeV
spoke (a German association for the promotion of free software) this
publicly recently plain text, see:
http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.discuss.german/13802



(Sorry only in German)




My questions are:

Are there any agreements which result to have the number of votes for
an issue? Is there some agreement that a high number of votes to be
reason, the implementation of Issues to be considered as a priority?

What is your basic view on this?


Greetings Jörg


-



To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org

For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: A question about existing practices


> -Original Message-
> From: Jürgen Schmidt [mailto:jogischm...@gmail.com] 

> This would be a very interesting approach that of course is indeed not
> completely new. If we wouldn't have useful patches in BZ I personally
> would of course support such an approach. Having a clean and fresh BZ
> would be an opportunity to focus the real problems we have and find a
> good balance between feature development and bugfixing.
> 
> But of course it's not really realistic :-(
> 
> The main problem with votes at the moment is that we don't 
> have a common
> understanding how to handle issue with votes. I would say at 
> the moment
> these votes are useless. We had focused on issue with high 
> votes in the
> past because it was the goal for developers at this time, managers
> pushed it but later on the priorities changed again and nobody really
> took care of these issues.
> 
> If we want to make use of this BZ feature we should first 
> think what we
> want to do with this issues and can we do it. Means we can't force
> developers to work on such high voted issues, we can only motivate to
> focus on these issues first. Or if some sponsors are interested to pay
> developers to work on such issues that could also work, I don't know.

There are certainly technical problems or problems of coordination, but what we
need, first and foremost, is the insight that we need to talk with users so that
they understand us.

Let me be clear:
our internal problems are users not care, they want a working software.
Where users give us Feadback, (for example write issues) they want something in
return for it, that we look seriously at their Feadback.

If our response should be to this user that we can not help them, because we do
not agree on how to deal with issues or votes, then that is unfortunately
insufficient.

This is not an accusation but only the truth, and we should do everything to
overcome these problems quickly.

> In general I think we should continue the discussion about 
> our long term
> goals for the project and the product first. We can't do 
> everything and
> it is important that we at least have all some common understanding
> about our strategy.
>
> We can start with thinking what office productivity suite really means
> and if we already fulfill these requirements...

Good, then I will begin by saying:

the interests of our users should be our most important goal. The minimum of 
this
is we listen to their problems and take it seriously.

AOO is not software experts, but for normal users and normal users want normal
responses.

Please let us understand together, that this is an important difference to the
Apache Web server (for example), as this is a software mainly for experts, AOO,
but for normal users.



Greetings,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Apache OpenOffice Extensions Website 2.0 (beta)

On 3/15/13 9:44 PM, hagar.del...@laposte.net wrote:
> Really AWESOME!
> A huge step forward regarding the interface.
> Many thanks for this improved site.

yes indeed, I like it as well and it looks good.

We still don't have the extension update notification feature working as
far as I know. Do you have any plans to make it working on the
repository site? Or better what is necessary to bring it back on the
repo site and in the office?

Juergen

> 
> Hagar
> 
>> Message du 15/03/13 19:53
>> De : "Roberto Galoppini"
>> A : dev@openoffice.apache.org
>> Copie à :
>> Objet : Apache OpenOffice Extensions Website 2.0 (beta)
>>
>> As announced back at the end of December we have been working on
>> enhancing AOO Extensions website, you might want to have a look at
>> http://aoo-extbeta.sourceforge.net/
>>
>> Keep in mind that the final layout would depend on AOO 4.0, and
>> counters are set to zero because downloads don't happen over there.
>> So said, all accounts and extensions have been imported, so releases
>> and comments.
>>
>> If you want to make your mind about the new features have a look at
>> the following URLs:
>> http://aoo-extbeta.sourceforge.net/
>> http://aoo-extbeta.sourceforge.net/search
>> http://aoo-extbeta.sourceforge.net/project/oracle-pdf-import-extension
>>
>> Comments and feedback are welcome as usual.
>>
>> Roberto
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>
> 
> Une messagerie gratuite, garantie à vie et des services en plus, ça vous 
> tente ?
> Je crée ma boîte mail www.laposte.net
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [CODE/LEGAL] Status of odt2mediawiki.xsl (Wiki Publisher extension)

On 3/13/13 8:12 PM, Ariel Constenla-Haile wrote:
> On Wed, Mar 13, 2013 at 12:57:16PM +0100, Oliver-Rainer Wittmann
> wrote:
>> 
>> Please have a lock at issue [1] 48409, esp. at attachment
>> "Revisoin 2639 of the odt2wiki transformation (formerly known as
>> odt2txt)" [2].
>> 
>> For me it looks like that XSL style sheet had been contributed
>> to OpenOffice. Thus, I expect that Bernard Haumacher (known as
>> haui with email address h...@haumacher.de in Bugzilla) is willing
>> to make it available under ALv2.
>> 
>> [1] https://issues.apache.org/ooo/show_bug.cgi?id=48409 [2]
>> https://issues.apache.org/ooo/attachment.cgi?id=45498&action=edit
>>
>>>
>> 
If not we will remove this code completely. The question is why this
>>> file is in the rat_exclude list?
>>> 
>> 
>> I assume it happened by error.
> 
> I already looked at the bug, and searched for Bernard in the 
> "Copyright-Approved Persons and Companies" 
> http://www.openoffice.org/copyright/copyrightapproved.html where he
> is listed.
> 
> But all these does not tell anything about the actual state of the 
> license of this file, so it's good to know that Jürgen contacted
> the author.

I have contacted Bernard and he was very open minded regarding
re-licensing and he was very cooperative.

He has reviewed the transformation (link From Ariel) and compared it
to a version in his own repo. He has appended a new version with ALv2
to issue https://issues.apache.org/ooo/show_bug.cgi?id=121907


@Ariel, let me know if I can help further or do we need more?

Juergen


> 
> 
> Regards
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: A question about existing practices

On 3/17/13 10:13 PM, Hagar Delest wrote:
> Any attempt to reset the votes would mean that once more, high scores
> are just ignored.
> Of course, nobody would browse the whole list of existing bugs, even to
> recast their own votes. So reseting the votes would only lead to forget
> about old bugs or old RFE.
> Have office suites really evolved so that most wanted features several
> years ago are now not relevant at all? If so, why not take the top 20
> and have a vote on the dev list for each of them and keep them or close
> them for the rationale that could emerge from the discussion?
> 
> My feeling is that you're trying to change the AOO agenda about RFE.
> Just ditch current history to rewrite your own history with OpenOffice.
> Same with your other message in my other mail in this topic. Of course
> old reports got more votes. If they had been closed earlier, the list of
> active reports would be different. And since RFE cannot implemented
> shortly, you'll always have this time bias.
> 
> Anyway, I don't want to engage further in this discussion. I've given my
> opinion, if the developers agree with your proposal then so be it. But
> if the votes are reset, I'll take it as a huge setback for the users
> decisions and won't hesitate to point to this topic in the forum to
> explain why I've lost the least interest in BZ. I would not see the
> point filing reports if in the future someone can delete the votes for
> whatever reason.
> If you want to go even further, why not just delete all the content of
> BZ and start from scratch?

This would be a very interesting approach that of course is indeed not
completely new. If we wouldn't have useful patches in BZ I personally
would of course support such an approach. Having a clean and fresh BZ
would be an opportunity to focus the real problems we have and find a
good balance between feature development and bugfixing.

But of course it's not really realistic :-(

The main problem with votes at the moment is that we don't have a common
understanding how to handle issue with votes. I would say at the moment
these votes are useless. We had focused on issue with high votes in the
past because it was the goal for developers at this time, managers
pushed it but later on the priorities changed again and nobody really
took care of these issues.

If we want to make use of this BZ feature we should first think what we
want to do with this issues and can we do it. Means we can't force
developers to work on such high voted issues, we can only motivate to
focus on these issues first. Or if some sponsors are interested to pay
developers to work on such issues that could also work, I don't know.

In general I think we should continue the discussion about our long term
goals for the project and the product first. We can't do everything and
it is important that we at least have all some common understanding
about our strategy.

We can start with thinking what office productivity suite really means
and if we already fulfill these requirements...


Juergen



> 
> Hagar
> 
> 
> Le 17/03/2013 15:32, Rob Weir a écrit :
> 
>> On Sat, Mar 16, 2013 at 6:55 PM, Hagar Delest
>>  wrote:
>>> Le 14/03/2013 15:10, Rob Weir a écrit :
>>>
 But if only a small minority of users know about voting, and we have a
 large collection of ancient votes, then the votes are less meaningful
 and relevant.  That's my main concern.  I don't believe that the vote
 counts necessarily reflect current reality.  Look at the requests we
 received when we did the Google Moderator feedback requests.  To me
 that is more meaningful, since it is more current.
>>>
>>>
>>> Argh, no!
>>> The Google moderator was a total mess. At least the BZ is very
>>> detailed, not
>>> that difficult to use, you can subscribe and have a discussion about the
>>> problem.
>>
>> Google Moderator was far easier to use for users than BZ is.  That is
>> why we received far more feedback with Moderator.  I'm sorry that the
>> troglodytes don't like that.
>>
>>> Voting in BZ is not more difficult than on Google Moderator.
>>> Why should ancient votes be less valid? They are still the expression
>>> of a
>>> large install base.
>>>
>>
>> They are less valid because they are ancient and do not necessarily
>> reflect what today's users want.
>>
>>>
>>>
 One way to improve this might be to remind users about voting via a
 blog post.  If we have more users involved in voting it becomes more
 meaningful.   Maybe even wipe out old votes, so we are looking at
 actual current user wants.  Then make votes more visible by creating
 periodic reports on issues with the most votes.  And when we fix an
 issue that had a lot of votes, maybe we blog about that.
>>>
>>>
>>> What nonsense! So because ASF took hold of the code they should
>>> restart from
>>> scratch and annihilate all the previous feedback?
>>
>> Yes.  That is an accurate statement of my belief here.  Feedback from
>> 2002 issues, no matter ho

Re: A question about existing practices

> -Original Message-
> From: Rob Weir [mailto:robw...@apache.org] 

> Sorry, I don't mean to say you did anything wrong.  Not at all.  But I
> do believe that there are only a small number real obligations for
> what kinds of issues we absolutely must address in the code:
> 
> 1) We must respond to security vulnerabilities, if any are found
> 
> 2) We must respond to any legal or licensing issues in the code, if
> any are found
> 
> If we fail on the above, then the responsible thing would be for the
> ASF to shut us down, right?

Yes, right.

> Votes are one source of user preferences, but not the only and not
> necessarily the best.  

Exactly. 
But in a modern world is listening to user votes not only what they demand, but 
also to get into conversations with users.

Users are not experts in software, they need our advice, but users also _need 
to feel their problems taken seriously_. Sometimes the feeling is to be taken 
seriously, even more important than technical changes.

In a modern world, we must understand that we have to sell AOO, not in terms of 
money, but in the sense of promoting our product.

Most users just want a good software and we have to convince them that this is 
AOO. To do AOO be technically good, but our communication with users must also 
be good.

For me there is not a specific problem with a specific issue, but I wanted to 
ask all of us to _respect_ only _with care_ to meet the needs of our users.



Greetings,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [Call-for-Review] code changes for more powerful smarttag extensions