Re: Norwegian translation for website

[Marcus]

Am 01/17/2016 08:01 PM, schrieb Kay Schenk:

On Sun, Jan 17, 2016 at 6:10 AM, Marcus  wrote:


Am 01/15/2016 07:37 PM, schrieb Marcus:


Am 01/14/2016 12:09 AM, schrieb Marcus:


Am 01/13/2016 11:59 PM, schrieb Andrea Pescetti:


On 13/01/2016 Marcus wrote:


I've seen that the CMS buildbot has still the faild build as last entry
[1]. Have you got any response from Infra how and when to solve this?



No, but I actually recommend that you commit your changes anyway since a
commit with many file deletions/additions is apparently more likely to
cause a race condition in the CMS and block it. So my advice is: go
ahead and commit the Norwegian site too (if you haven't already), then
I'll chat with Infra again and ask for a full rebuild. At that stage, we
will only have minor (read: safer) changes to commit.



I cannot convince the buildbot to start working with a small change. So,
I will try to commit my bigger changes tomorrow.



I've now committed all files from Jan.



is there anything more I should do to get the CMS buildbot to work again?

Thanks

Marcus



​Maybe not...see message on Service Status page re CMS:
​
http://status.apache.org/

​but this was a few days ago...


here [1] the last build attempt was still failing. So, I'm waiting for 
Infra to resolve this. AFAIK Andrea wanted to ping them again.


[1] https://ci.apache.org/builders/ooo-site-site-staging

Marcus


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

Re: Remove comments in English Dictionaries?

[Andrea Pescetti]

Marco A.G.Pinto wrote:

I am writing to ask if it is okay for me to remove (hide) the comments
in the English Dictionaries extension site.


(Why is the QA list in the recipients? I'm putting l10n and QA in BCC, 
let's follow up on dev if needed)


I prefer, as a user, to see comments on extensions, since from time to 
time I read useful information there and they are a good channel for 
contacting the author. An external link would not be the same (while 
mentioning your site in the extension description is surely useful). But 
this is just a personal opinion.


Regards,
  Andrea.

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

Re: Norwegian translation for website

[Kay Schenk]

On Sun, Jan 17, 2016 at 6:10 AM, Marcus  wrote:

> Am 01/15/2016 07:37 PM, schrieb Marcus:
>
>> Am 01/14/2016 12:09 AM, schrieb Marcus:
>>
>>> Am 01/13/2016 11:59 PM, schrieb Andrea Pescetti:
>>>
 On 13/01/2016 Marcus wrote:

> I've seen that the CMS buildbot has still the faild build as last entry
> [1]. Have you got any response from Infra how and when to solve this?
>

 No, but I actually recommend that you commit your changes anyway since a
 commit with many file deletions/additions is apparently more likely to
 cause a race condition in the CMS and block it. So my advice is: go
 ahead and commit the Norwegian site too (if you haven't already), then
 I'll chat with Infra again and ask for a full rebuild. At that stage, we
 will only have minor (read: safer) changes to commit.

>>>
>>> I cannot convince the buildbot to start working with a small change. So,
>>> I will try to commit my bigger changes tomorrow.
>>>
>>
>> I've now committed all files from Jan.
>>
>
> is there anything more I should do to get the CMS buildbot to work again?
>
> Thanks
>
> Marcus
>

​Maybe not...see message on Service Status page re CMS:
​
http://status.apache.org/

​but this was a few days ago...



-- 
--
MzK

"Though no one can go back and make a brand new start,
 anyone can start from now and make a brand new ending."
  -- Carl Bard

RE: Remove comments in English Dictionaries?

[Dennis E. Hamilton]

+1 about comments, etc.

> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org]
> Sent: Sunday, January 17, 2016 14:54
> To: dev@openoffice.apache.org
> Subject: Re: Remove comments in English Dictionaries?
> 
> Marco A.G.Pinto wrote:
> > I am writing to ask if it is okay for me to remove (hide) the comments
> > in the English Dictionaries extension site.
> 
> (Why is the QA list in the recipients? I'm putting l10n and QA in BCC,
> let's follow up on dev if needed)
> 
> I prefer, as a user, to see comments on extensions, since from time to
> time I read useful information there and they are a good channel for
> contacting the author. An external link would not be the same (while
> mentioning your site in the extension description is surely useful). But
> this is just a personal opinion.
> 
> Regards,
>Andrea.
> 
> -
> 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

Remove comments in English Dictionaries?

[Marco A.G.Pinto]

Hello!

I am writing to ask if it is okay for me to remove (hide) the comments 
in the English Dictionaries extension site.


This happens because I have just added the text to the description, 
below the visit the "Proofing Tool GUI project for help blah blah":

"Or use the mailing lists."

The thing is the comments are always the same which is annoying and they 
fill the page with garbage.


Anyway, if someone asks how to install, just give them the direct URL 
with the help steps:

http://marcoagpinto.cidadevirtual.pt/en_installing.html

What is your opinion? Should I hide the comments?

Thanks!

Kind regards,
   >Marco A.G.Pinto
 

--

Re: Norwegian translation for website

[Marcus]

Am 01/15/2016 07:37 PM, schrieb Marcus:

Am 01/14/2016 12:09 AM, schrieb Marcus:

Am 01/13/2016 11:59 PM, schrieb Andrea Pescetti:

On 13/01/2016 Marcus wrote:

I've seen that the CMS buildbot has still the faild build as last entry
[1]. Have you got any response from Infra how and when to solve this?


No, but I actually recommend that you commit your changes anyway since a
commit with many file deletions/additions is apparently more likely to
cause a race condition in the CMS and block it. So my advice is: go
ahead and commit the Norwegian site too (if you haven't already), then
I'll chat with Infra again and ask for a full rebuild. At that stage, we
will only have minor (read: safer) changes to commit.


I cannot convince the buildbot to start working with a small change. So,
I will try to commit my bigger changes tomorrow.


I've now committed all files from Jan.


is there anything more I should do to get the CMS buildbot to work again?

Thanks

Marcus

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

Re: [REPORT] Issue Clearance Quality + Technical Debt

[Rob Weir]

On Fri, Jan 15, 2016 at 2:22 PM, Dennis E. Hamilton  wrote:
> [BCC to Project Management Committee and users@ oo.a.o]
>
> SUMMARY
>
> The top-level analysis of Bugzilla issue handling has been completed for all 
> issues opened on the project through December 31, 2015.
>
> The complete tabulation is in the PDF document at .
>
> It remains the case that since the establishment of Apache OpenOffice as an 
> ASF Top Level Project in November, 2012, the accrual of unresolved issues 
> exceeds 40%.  That is, for every 100 new issues, on the average more than 40 
> of them will be unresolved indefinitely.
>
> In contrast, although there is a very large number of unresolved issues that 
> remain in the Bugzilla from its history as part of OpenOffice.org, that 
> previous technical debt was, proportionally, under 20%.
>

It is entirely unfounded to equate unresolved "issues" in Bugzilla
with "technical debt." When I was "leading" a group of QA volunteers a
few years ago to resolve BZ issues it was clear that only a small
percentage of them were actual reports of new bugs in the product.  A
very small fraction.  Most of them fit into other categories:

1) Questions on how to use to product, or misunderstandings about how
the product worked.

2) General system-wide issues and user was reaching out to us for free
computer technical support.

3) Redundant reports of already known bugs or already requested enhancements,

4) Vague reports which could not be reproduced and which the original
submitter was unresponsive to requests for clarification.

At that time we reduced these numbers by quite a bit.  But note that
this was done without changing a single line of code.  It was a paper
exercise of reducing the of open BZ issues only.   If closing BZ
issues in these categories does not magically improve product quality,
hopefully you can see how not closing such issues (due to less
organization in the QA activity) does not magically decrease product
quality, or technical debt for that matter.

Anyone familiar with the discipline of SQE understands that the
meaningful comparison can only be done after triaging issues,
eliminating those that are not reporting bugs, deduplicating bug
reports and attempting to confirm them.   That might indicate
"technical debt".  But what you're reporting is not that, but "bug
triaging debt" if you feel the need to give it a label.  This
distinction is important.

Regards,

-Rob



> Some highlights:
>
>  * Even though the monthly rate of new issues and comments on issues has been 
> decreasing significantly since mid-2014, the rate of technical debt as the 
> proportion of unresolved issues has not improved.
>
>  * Although a reduction to 35% unresolved-issue is seen in the last 5 months 
> of 2015, this may be distorted by issues created and then resolved in the 
> staging of AOO 4.1.2 release candidates and QA on the candidates.  Results 
> for the first-quarter of 2016 are needed to determine if this is a new trend 
> or a hiccup.
>
> DETAIL AND QUALITY MATTERS
>
> This is a rough analysis, although the consistent trend is difficult to 
> explain away.
>
> Refinement requires a closer look at the nature of issues and understanding 
> of exactly what resolution means, not just what being left unresolved means.
>
> There is also a suspected disconnect with regard to what is considered an 
> issue and how the ways of closing an issue are actually applied.
>
>  * Closing of a new issue as a duplicate qualifies as a resolution.  The 
> incidence of long-standing issues that continue to receive duplicate reports 
> is useful to understand in this case, and that requires more detail.
>
>  * Some issues are closed as Resolved Fixed when the fact of the matter is 
> that there was insufficient detail to understand and confirm the issue and 
> the reporting party failed to provide additional information (if it was even 
> requested).
>
>  * Some comments on issues tailgate possibly-different problems onto known 
> ones, although the resemblance may be superficial and the issues need to be 
> split.
>
>  * Enhancement/feature requests are not distinguished.
>
>  * Resolved issues are sometimes closed without obtaining confirmation that 
> incorporation of the identified resolution in distributed code actually 
> addresses the originally-reported difficulty.
>
>  * Some issue reports are closed as not issues because they are declared user 
> problems and kicked to the Community Forum.
>
> These may all have small effects.  We will know only by looking more closely 
> into Bugzilla details.
>
> The last case deserves more careful attention.
>
> The next-in-line users of Apache OpenOffice distributions consist of around 
> 50 million users who are mainly individuals and 87% of whom are using 
> Microsoft Windows.  Such casual users, whatever their limited experience in 
> trouble-shooting and describing problems, are the main users of this 
> software.  The 

RE: [REPORT] Issue Clearance Quality + Technical Debt

[Dennis E. Hamilton]

FYI, the searches I've done for unresolved issues excludes all issues that have 
been identified as duplicates and those having any form of resolution, 
including being closed.  It does not distinguish between unresolved extension 
requests and defect reports, and between unresolved confirmed and unconfirmed 
incident reports.  

Agreed, finer-grained analysis can provide some clarity on this, and it will be 
interesting how much noise happens to be removed.

Of course, technical debt can be more than known and uncorrected bugs in the 
code.  It has more forms and symptoms, some of which are reflected in bug 
reports of a different nature.  

For those playing along at home, what I have relied on in my use of the 
*metaphorical* term, "technical debt": 

 Martin Fowler.  Technical Debt Quadrant.  Web site article, 2009-10-14.  
Available at
  
 and the earlier paper linked there.

I use the open bugs as an indicator of technical debt.  Whether it is a very 
good one or not is a different matter.  It strikes me that digging deeper is 
the avenue to clarity on that.  

What we have here is evidence that there is something being accrued and that 
needs to be dug into.  We can worry about what best to call it when we know 
more about what it is.  

My concern is that it is a debt that our users and the supporters of the 
user-facing lists are paying the interest on [;<).

 - Dennis

> -Original Message-
> From: Rob Weir [mailto:r...@robweir.com]
> Sent: Sunday, January 17, 2016 06:29
> To: dev@openoffice.apache.org;  
> Subject: Re: [REPORT] Issue Clearance Quality + Technical Debt
> 
> On Fri, Jan 15, 2016 at 2:22 PM, Dennis E. Hamilton 
> wrote:
> > [BCC to Project Management Committee and users@ oo.a.o]
> >
> > SUMMARY
> >
> > The top-level analysis of Bugzilla issue handling has been completed
> for all issues opened on the project through December 31, 2015.
> >
> > The complete tabulation is in the PDF document at
> .
> >
> > It remains the case that since the establishment of Apache OpenOffice
> as an ASF Top Level Project in November, 2012, the accrual of unresolved
> issues exceeds 40%.  That is, for every 100 new issues, on the average
> more than 40 of them will be unresolved indefinitely.
> >
> > In contrast, although there is a very large number of unresolved
> issues that remain in the Bugzilla from its history as part of
> OpenOffice.org, that previous technical debt was, proportionally, under
> 20%.
> >
> 
> It is entirely unfounded to equate unresolved "issues" in Bugzilla
> with "technical debt." When I was "leading" a group of QA volunteers a
> few years ago to resolve BZ issues it was clear that only a small
> percentage of them were actual reports of new bugs in the product.  A
> very small fraction.  Most of them fit into other categories:
> 
> 1) Questions on how to use to product, or misunderstandings about how
> the product worked.
> 
> 2) General system-wide issues and user was reaching out to us for free
> computer technical support.
> 
> 3) Redundant reports of already known bugs or already requested
> enhancements,
> 
> 4) Vague reports which could not be reproduced and which the original
> submitter was unresponsive to requests for clarification.
> 
> At that time we reduced these numbers by quite a bit.  But note that
> this was done without changing a single line of code.  It was a paper
> exercise of reducing the of open BZ issues only.   If closing BZ
> issues in these categories does not magically improve product quality,
> hopefully you can see how not closing such issues (due to less
> organization in the QA activity) does not magically decrease product
> quality, or technical debt for that matter.
> 
> Anyone familiar with the discipline of SQE understands that the
> meaningful comparison can only be done after triaging issues,
> eliminating those that are not reporting bugs, deduplicating bug
> reports and attempting to confirm them.   That might indicate
> "technical debt".  But what you're reporting is not that, but "bug
> triaging debt" if you feel the need to give it a label.  This
> distinction is important.
> 
> Regards,
> 
> -Rob
> 
> 
> 
> > Some highlights:
> >
> >  * Even though the monthly rate of new issues and comments on issues
> has been decreasing significantly since mid-2014, the rate of technical
> debt as the proportion of unresolved issues has not improved.
> >
> >  * Although a reduction to 35% unresolved-issue is seen in the last 5
> months of 2015, this may be distorted by issues created and then
> resolved in the staging of AOO 4.1.2 release candidates and QA on the
> candidates.  Results for the first-quarter of 2016 are needed to
> determine if this is a new trend or a hiccup.
> >
> > DETAIL AND QUALITY MATTERS
> >
> > This is a rough analysis, although the consistent trend is difficult
> to explain 

Re: [REPORT] Issue Clearance Quality + Technical Debt

[donaldupre .]

On Sat, Jan 16, 2016 at 8:22 PM, Dennis E. Hamilton 
wrote:

>
> [orcmid]
>
> I don't know.  I haven't looked for such information and I am not aware of
> any form it might be available in.
>
> Considering how different projects can be, I am not certain what lessons
> might transfer from one to another.
>
> Do you envision how having such information would be helpful in assessing
> the effectiveness of this project's handling of reported issues and how
> that is reflected in improvements to the product?
>
> The industry averages of the various parameters can serve us as quality
objectives.

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

Re: [REPORT] Issue Clearance Quality + Technical Debt

[Rob Weir]

On Sun, Jan 17, 2016 at 11:17 AM, Dennis E. Hamilton  wrote:
> FYI, the searches I've done for unresolved issues excludes all issues that 
> have been identified as duplicates and those having any form of resolution, 
> including being closed.  It does not distinguish between unresolved extension 
> requests and defect reports, and between unresolved confirmed and unconfirmed 
> incident reports.
>

The point, of course, is that we once make deliberate efforts to
identify duplicates, support questions, etc., and mark them
accordingly, an effort that is not occurring to the same degree today.
So your numbers are conflating this difference in BZ processing with a
difference in the product quality, which is inaccurate and unfair.

-Rob


> Agreed, finer-grained analysis can provide some clarity on this, and it will 
> be interesting how much noise happens to be removed.
>
> Of course, technical debt can be more than known and uncorrected bugs in the 
> code.  It has more forms and symptoms, some of which are reflected in bug 
> reports of a different nature.
>
> For those playing along at home, what I have relied on in my use of the 
> *metaphorical* term, "technical debt":
>
>  Martin Fowler.  Technical Debt Quadrant.  Web site article, 2009-10-14.  
> Available at
>  
>  and the earlier paper linked there.
>
> I use the open bugs as an indicator of technical debt.  Whether it is a very 
> good one or not is a different matter.  It strikes me that digging deeper is 
> the avenue to clarity on that.
>
> What we have here is evidence that there is something being accrued and that 
> needs to be dug into.  We can worry about what best to call it when we know 
> more about what it is.
>
> My concern is that it is a debt that our users and the supporters of the 
> user-facing lists are paying the interest on [;<).
>
>  - Dennis
>
>> -Original Message-
>> From: Rob Weir [mailto:r...@robweir.com]
>> Sent: Sunday, January 17, 2016 06:29
>> To: dev@openoffice.apache.org;  
>> Subject: Re: [REPORT] Issue Clearance Quality + Technical Debt
>>
>> On Fri, Jan 15, 2016 at 2:22 PM, Dennis E. Hamilton 
>> wrote:
>> > [BCC to Project Management Committee and users@ oo.a.o]
>> >
>> > SUMMARY
>> >
>> > The top-level analysis of Bugzilla issue handling has been completed
>> for all issues opened on the project through December 31, 2015.
>> >
>> > The complete tabulation is in the PDF document at
>> .
>> >
>> > It remains the case that since the establishment of Apache OpenOffice
>> as an ASF Top Level Project in November, 2012, the accrual of unresolved
>> issues exceeds 40%.  That is, for every 100 new issues, on the average
>> more than 40 of them will be unresolved indefinitely.
>> >
>> > In contrast, although there is a very large number of unresolved
>> issues that remain in the Bugzilla from its history as part of
>> OpenOffice.org, that previous technical debt was, proportionally, under
>> 20%.
>> >
>>
>> It is entirely unfounded to equate unresolved "issues" in Bugzilla
>> with "technical debt." When I was "leading" a group of QA volunteers a
>> few years ago to resolve BZ issues it was clear that only a small
>> percentage of them were actual reports of new bugs in the product.  A
>> very small fraction.  Most of them fit into other categories:
>>
>> 1) Questions on how to use to product, or misunderstandings about how
>> the product worked.
>>
>> 2) General system-wide issues and user was reaching out to us for free
>> computer technical support.
>>
>> 3) Redundant reports of already known bugs or already requested
>> enhancements,
>>
>> 4) Vague reports which could not be reproduced and which the original
>> submitter was unresponsive to requests for clarification.
>>
>> At that time we reduced these numbers by quite a bit.  But note that
>> this was done without changing a single line of code.  It was a paper
>> exercise of reducing the of open BZ issues only.   If closing BZ
>> issues in these categories does not magically improve product quality,
>> hopefully you can see how not closing such issues (due to less
>> organization in the QA activity) does not magically decrease product
>> quality, or technical debt for that matter.
>>
>> Anyone familiar with the discipline of SQE understands that the
>> meaningful comparison can only be done after triaging issues,
>> eliminating those that are not reporting bugs, deduplicating bug
>> reports and attempting to confirm them.   That might indicate
>> "technical debt".  But what you're reporting is not that, but "bug
>> triaging debt" if you feel the need to give it a label.  This
>> distinction is important.
>>
>> Regards,
>>
>> -Rob
>>
>>
>>
>> > Some highlights:
>> >
>> >  * Even though the monthly rate of new issues and comments on issues
>> has been decreasing significantly since mid-2014, the rate of