Re: Minutes from the UX/design meeting 2023-Apr-24

[Eyal Rozenberg]

Sorry for missing a meeting with a few of "my own" bug reports...


On 24/04/2024 21:58, Heiko Tietze wrote:

  * Want indication of whether a master slide is in use or not
    + https://bugs.documentfoundation.org/show_bug.cgi?id=160403
    + MSO Powerpoints shows the number of slides in a tooltip (Stephane)
    + additional boolean indication would be nice (Eyal)
    + tooltip sounds good and is not harmful (John)
    + not much useful since "Delete Master" is only available if the
  slide master is not in use (Cor)


... but you only see that if you right-click the master. The boolean
indication suggestion would make you aware of this about all visible
masters at once. But I agree with the low priority.


    => no objection, low priority

  * When right-clicking a font family combo-box, offer font meta-data
    + https://bugs.documentfoundation.org/show_bug.cgi?id=152487
    + unclear use case and much likely off-topic being available in
  font management tools (Heiko)


I will have to make the use case clearer on the bug page. Again, sorry
for not being around to make that case.



    + info dialog sounds good but rather via special characters or
  in the character properties dialog (Stuart)
    + only use case is compatibility with some other font (John)


That's an interesting use case, but not what I had in mind.



  + likely not part of the meta data
    + the Internet returns all search results (Cor)


The point is to help the user select an item on a list, while the list
is open - so that the user doesn't have to search for information
elsewhere (e.g. the Internet).

>     => idea does not find support; WF>

  * Make possible 2 or more impress in fullscreen each on a dedicated
    monitor AND each seekable independently with user-defined hotkeys
    per each file
    + https://bugs.documentfoundation.org/show_bug.cgi?id=160242


First of all, I really think this bug report should have been split up
into several ones - and the issues were sort of mapped on the bug page:

A. run two presentations full-screen at same time (on two monitors)
B. Keyboard-navigate in two running full-screen presentation (i.e.
different shortcuts)
C. Same as B, but arbitrary number of presentations
D. Support per-presentation navigation shortcut choices, persisted in
the ODP file

>     + start Impress twice (Stephane)

When you start Impress twice you're still left with just the one
instance running. I guess you can force a second instance (with a
different profile folder perhaps?) but even then, IIANM, Impress is
"imperialistic" when in Full-Screen mode. Op claimed this doesn't work
right now.


workflow is supported with a third   monitor (John)


1. Is it? Can you elaborate on the bug page?
2. What about two monitors?

>     + too niche, better suited for an extension (Stephane, Sahil)

I partially disagree, considering the breakdown above:

A: Not so niche, in my opinion. Occasionally you want to show slides
from different presentations on different monitors - without having
combined them into a multi-monitor-targeting presentation (do we even
have that?). Happened to me already.

B: If Alt-Tab worked (which we can't know, since A is not possible yet),
then this would be kind of niche.

C, D: That's the niche part.


>     => WF

Disagree!

It looks like (some of) the ask changes app behavior rather than
enhancing it. The per-file shortcuts sounds like extension material to
me though.

Suggest breakup instead then INVALID (or MOVED) on this one. I would say

A - NEW
B - UNCONFIRMED (or LATER?)
C, D - WONTFIX

Re: ESC meeting minutes: 2024-04-04

[Eyal Rozenberg]

Shame on the BoD - current and previous - for carrying out the entire
hiring process for a RTL/CTL/CJK develop while completely shutting out
(*) the RTL language community, for the second time, despite the
explicit protest and demand not to do so.

And it is unfortunate that the ESC acknowledges this having occurred
without even hinting at an obligation to consult with the relevant
language communities/groups.

Eyal

(*) - I'm making the assumption that this was not discussed on the Farsi
Telegram channel, which I do not follow; otherwise it's "shutting out a
significant part of the RTL language community." Also, I would not be
surprised if the CJK community wasn't involved either.


On 04/04/2024 17:35, Miklos Vajna wrote:

* Present:
     + Cloph, Hossein, Michael W, Olivier, Caolan, Ilmari, Jonathan,
Michael S, Stephan, Xisco, Miklos, Heiko, Thorsten

* Completed Action Items:

* Pending Action Items:

* Release Engineering update (Cloph)
     + 7.6: 7.6.7 RC1 week 16
     + 24.2: 24.2.3 RC1 week 15

* Welcome Jonathan Clark

     - New RTL/CTL/CJK developer

     - working for TDF

     - reviewing bug backlog currently

     - preferred IRC nick? :-) (Xisco)

   - jclark or so

Re: Minutes from the UX/design meeting 2023-Feb-22

[Eyal Rozenberg]

On 22/02/2024 16:46, Heiko Tietze wrote:

  * Simplified options dialogs


You seem to have ignored the basic problem with how this bug has been
handled, which I pointed out in comment:
https://bugs.documentfoundation.org/show_bug.cgi?id=90989#c9


    + name, icons, interface, colors, ui lang, locale, and recovery should
  be sufficient (Heiko)


Sufficient for what? I don't know, that sounds fishy.


    + RTL/CTL/CJK is important (Hossein) but should follow the locale
(Heiko),


Nope, shouldn't follow the locale. And that's because:

1. Very often, RTL/CTL-focused language users use computers with a
non-RTL/CTL locale - either on their own computers or others' computers.
2. People may be reading, or even writing, RTL/CTL content despite that
not being their locale-relevant language (e.g. immigrants and the
language of their country of origin).


  and if a more complex setup is needed the advanced mode is a click
away


I am wary that relegating settings to "advanced mode" is a way of
avoiding the problem of dialog simplicity rather than actually tackling
it. That's generally. For RTL/CTL specifically, I _know_ that this is
the case - because all of those RTL/CTL(/CJK) users will need the
"advanced" mode even when they don't want to "advanced" thing.


    + could be done conditionally depending on locale setting (Sahil)


Again, not good enough.


    + more tabs might be required in future (Hossein); possibly easier
to use
  than a scrolling window (Sahil)


Let's start by separating out the app-wide & module-wide settings from
the document-specific settings.

And then, we should probably separate out the default-template-ish
settings out of there too, like default fonts and stuff.

Re: [libreoffice-design] Re: Minutes from the UX/design meeting 2023-Dec-20

[Eyal Rozenberg]

The font embedding is an example of a deeper issue:

If LibreOffice is a 'native' ODT editor;
and if you open an ODT in it;
and if you don't effect any changes in that ODT, but just save;
is it legitimate for the resulting ODT to be in any way different than
the original (other than meta-data regarding modification date etc.) ?


On 22/12/2023 9:11, Heiko Tietze wrote:

On 21.12.23 20:05, Eyal Rozenberg wrote:

"LibreOffice unexpectedly and strangely modifies an ODT file without
they user having done anything, and embedding unnecessary fonts nobody
asked it to."


Sounds like another facet of the font embedding. I would treat bug
158588 about what fonts are embedded (CTL/CJK/Lat and used) and handle
the situation of shared documents on another. I haven't tested what
happens when one checks the embed fonts option and shares this document
with another person. Assuming her fonts would also be included,
silently, this is at least a privacy issue.

Re: Minutes from the UX/design meeting 2023-Dec-20

[Eyal Rozenberg]

I want to draw our attention to the first bug which was on the agenda in
yesterday's design meeting:

https://bugs.documentfoundation.org/show_bug.cgi?id=158588

I would say that bug is misnamed. It should be called:

"LibreOffice unexpectedly and strangely modifies an ODT file without
they user having done anything, and embedding unnecessary fonts nobody
asked it to."

IMHO it's several non-trivial issues rolled into one:

* LO's "contract" with the user as an ODT editor
* Where does the UI regarding font embedding choices belong?
* Does LO "know" about the actual use of different languages in a document?

I've commented on the bug myself but would encourage more of us to have
another look at it.

Eyal

PS - Sorry for missing the meeting :-(

On 20/12/2023 23:00, Heiko Tietze wrote:

Present: Sahil, Rafael, John, Heiko
Comments: Dieter, Stuart

Tickets/Topics

  * Redesign font embedding options in
sfx2/uiconfig/ui/documentfontspage.ui
    + https://bugs.documentfoundation.org/show_bug.cgi?id=158588
    + improve help (Dieter, bug 130185)
    + dummy text with no embedded font = 28k, with all options on = 22000k
  with "only used" 927k, with all but limited to latin = 1800k
    + disable CTL & CJK depending on options and
    + check by default and disable the "Only used fonts" unless
  the first option "Embed fonts" is activated (Heiko)
    + if the document contains and CTL/CJK font it would be
  pointless to exclude them when saving used fonts only;
  and the other option makes not much sense alone (Rafael)
    + font scripts options needs a dev check
    => do it





  * FORMCONTROLS Enhancement: Fill Cell with Text Box in Calc
    + https://bugs.documentfoundation.org/show_bug.cgi?id=158273
    + check/enable anchor to cell (resize with cell) and fit to cell size
  by default (Heiko)
    + changing this makes users needy and they may ask for better chart
  positioning, for example; how about a dedicated command to
  achieve the goal (Rafael)
    + could also be done per macro (Sahil)
    + goal was here to insert/manipulate many form controls; the workflow
  with copy/paste is tedious as cursor down or enter does not
  behave like at normal cells; which could be changed (Heiko)
   => comment

  * Incorrectly export number 0 form calc to PDF
    + https://bugs.documentfoundation.org/show_bug.cgi?id=158533
    + option to show/include zero is on by default and one has to disable
  it intentionally
    + same behavior on Excel
    + dependency to some archived PDF format is unclear
    => ask the ESC

  * New sidebar deck for comments
    + https://bugs.documentfoundation.org/show_bug.cgi?id=106316
    + splitter to expand the comments margin (Jim)
    + comments in margin is sufficient for ordinary users (John)
    + vertical space in margin is not enough for academia; management
  is missing, eg. to find unresolved comments (Rafael)
    + sidebar has limited vertical space
  + but allows the list being unsynchronized ie. many comments on one
  single page overlapping each other
    + requirements: add filter by status, eg. resolved
  no urgent need for the procrastination option "hide temporarily"
    + mockup design: take the Onlyoffice example
https://bug-attachments.documentfoundation.org/attachment.cgi?id=191371;
sort is
  missing; referenced text should be visible in the sidebar pane
    + enhancements: predefined responses? might be useful for some
(Rafael),
  but should be done resp. the list filled by users (Sahil)
    + replace the comments in margin or amends it (John)
    => improve the mockup and ask the community in a blog post

Re: [Libreoffice-qa] Weekly focus: SVG / We ducked below 1000 unconfirmed bugs

[Eyal Rozenberg]

I just had a look at the UNCONFIRMED_set chart on BugZilla:

https://bugs.documentfoundation.org/chart.cgi?category=LibreOffice=UNCONFIRMED_set=2919=2919=All=wrap=1100=350

so, congrats on getting below 1000, but the behavior of that graph is
kind of weird:

* Perfectly linear increase in UNCONFIRMED for about 2 years
* Dramatic jump in 2020 and dramatic drop in 2021

I wonder if I can plot this chart alongside UNCOFIRMED bugs being
created, so that we can plot how many UNCONFIRMED were handled per unit
of time.

Eyal

On 07/11/2023 11:58, Stéphane Guillou wrote:

Hi all!

Last week, we kicked off a "Weekly Focus" with the topic of SVG, see the
blog post for more information:
https://qa.blog.documentfoundation.org/2023/10/30/qa-weekly-focus-svg/

We have made some progress on it, but if you want to keep contributing
to reviewing reports, the list is still available on our pad:
https://pad.documentfoundation.org/p/qa

Please feel free to pick a report, put your name in front of it, and
check if it is still current, missing some information, identified as a
regression, or can be closed.

Next Monday we'll continue with a new topic and hopefully get into a
rhythm of one focus area per week, announced on the mailing list.

Thanks everyone for your contributions – and last but not least:
congratulations getting from 1850 unconfirmed bugs a year ago, down to
below 1000 unconfirmed bugs! (The first time since July 2020.)

Re: [Libreoffice-qa] ESC meeting agenda: 2023-09-28 16:00 CEST

[Eyal Rozenberg]

The minutes item about the UI/UX aspect of dealing with security
vulnerabilities is something that, in the last design meeting, John and
myself specifically asked to be brought up at the ESC - assuming it
would be part of a larger discussion of this matter. I want to thank
Heiko for bringing the subject up and I'm glad this was discussed, but
Miklos' response suggests that the ESC is considering this as
weakly-related future enhancement rather than part of the response to
the (past and) current vulnerability.

About what we are currently doing:

1. I have not been prompted to upgrade to 7.6.2. Granted, I'm on Linux,
but that's still a significant percentage of our users; have Windows
users been prompted to upgrade? Even if they otherwise don't care about
upgrades?

2. When looking at "Check for updates..." I am told: "LibreOffice 7.6.2
is available" - not even a mention of the security issue, let alone a
warning that an update is highly advisable because of it, a link to
guidance about the vulnerability etc. Most users will probably not
bother: "Why should I switch from 7.6.0.3 to 7.6.2? It's not even a
second-level version number change. My LibreOffice works fine, let's not
waste time on this."

3. So, LibreOffice 7.4 is out of official support. Have old-LO-version
users been warned by the app about the security vulnerability? If not
specifically, have they been actively and intrusively warned on June
12th that they should upgrade LO, to avoid potential security
vulnerabilities? IIANM, the answer is negative.

Note that I am not suggesting we auto-update without user consent. That
is for others to decide (never auto-update, opt-in to auto-update,
auto-update by default with opt-out). But security warnings, while
auto-update is not in effect, are important. Of course some people might
want to opt out of any call-home behavior, even for security warnings,
and that should be respected as well.

Eyal

On 29/09/2023 10:52, Xisco Fauli wrote:

Hello,

This particular issue only affects users using LibreOffice 7.4,
LibreOffice 7.5 and LibreOffice 7.6 since the Webp support was added in
LibreOffice 7.4. See https://wiki.documentfoundation.org/ReleaseNotes/7.4

For those users still using LibreOffice 7.4, the official support of
this branch ended in June 12, 2023 ( See
https://wiki.documentfoundation.org/ReleasePlan/7.4 ) so if they are
still using it, we can't force them to upgrade their version to a newer
one. They have been suggested to upgrade it for a while now, even before
this vulnerability was known.

For 7.5 and 7.6 users, the autoupdater has been already bumped to 7.5.7
and 7.6.2 respectively so users will be suggested to upgrade the next
time they launch LibreOffice. It's also up to them to upgrade it or not.
Marketing is also spreading the word in different channels about the
importance of this release ( see
https://blog.documentfoundation.org/blog/2023/09/26/lo-762-and-lo-757/ )

For the future, it's possible there will be an automatic updater
mechanism in place, see the ESC minutes from yesterday (
https://lists.freedesktop.org/archives/libreoffice/2023-September/091022.html "The 
UI/UX aspect of how to deal with security vulnerabilities" topic)

Regards

On 28/9/23 23:26, Eyal Rozenberg wrote:

But Sophie, from the dev point of view, the problem is actually not
solved - until LO has a mechanism for pushing intrusive notifications of
required critical updates (with an opt-out for people who don't want
that). Some might disagree with this position, but it is certainly a
matter for discussion in the ESC.

Also, the ESC has not mapped out for us the potential for exploiting the
vulnerability with LO (with and without "social engineering" of user
behavior). While that is not critical, it would be useful both for
identifying, retroactively, LO exploitation as the culprit in case of
actual malicious intrusions; and for those rare cases where an upgrade
is impossible for some reason.

Eyal




On 28/09/2023 23:23, sophi wrote:

Hi Eyal, John,

Just to give some information on this peculiar episode. The CVE happened
just before the conference where most of the team was traveling, not
easy to do a respin in those conditions.

What Miklos meant is that in the *dev* point of view it was solved, a
fix has been provided thanks to Caolan, that's all developers can do
"they move on to the next issue". So nothing more on their side to talk
about. It doesn't mean they don't care about users, they have done their
job in fixing the issue, the rest is not in their power. It's up to us,
you, me.

Then it's up to release engineering, UX and marketing to act. What RE
did from Monday to today because there was some problem with a Mac
version.

We have discussed today inside the team how we could better served our
users when this type of issue emerged. Security is a difficult topic to
talk about, there is not only the fix, but how it's embargoed for other

Re: [Libreoffice-qa] ESC meeting agenda: 2023-09-28 16:00 CEST

[Eyal Rozenberg]

But Sophie, from the dev point of view, the problem is actually not
solved - until LO has a mechanism for pushing intrusive notifications of
required critical updates (with an opt-out for people who don't want
that). Some might disagree with this position, but it is certainly a
matter for discussion in the ESC.

Also, the ESC has not mapped out for us the potential for exploiting the
vulnerability with LO (with and without "social engineering" of user
behavior). While that is not critical, it would be useful both for
identifying, retroactively, LO exploitation as the culprit in case of
actual malicious intrusions; and for those rare cases where an upgrade
is impossible for some reason.

Eyal




On 28/09/2023 23:23, sophi wrote:

Hi Eyal, John,

Just to give some information on this peculiar episode. The CVE happened
just before the conference where most of the team was traveling, not
easy to do a respin in those conditions.

What Miklos meant is that in the *dev* point of view it was solved, a
fix has been provided thanks to Caolan, that's all developers can do
"they move on to the next issue". So nothing more on their side to talk
about. It doesn't mean they don't care about users, they have done their
job in fixing the issue, the rest is not in their power. It's up to us,
you, me.

Then it's up to release engineering, UX and marketing to act. What RE
did from Monday to today because there was some problem with a Mac version.

We have discussed today inside the team how we could better served our
users when this type of issue emerged. Security is a difficult topic to
talk about, there is not only the fix, but how it's embargoed for other
products, etc.

I think the best way now to go on positively on this is to have a
discussion between marketing, UX and RE: should we have a pop-up in the
product advertising about security fix, should we have a special
communication campaign. Most of the time, there is an embargo and we
release security fixes without communication because of that, what
should we do?

Please, open the discussion on the marketing list, all points of view
and ideas are valuable, but don't shout to our developers, they provided
a fix very quickly, up to us to know how to communicate it now. This was
a new situation that needs to be addressed, your opinion about users is
very much valid, how should we go from there now?

Cheers
Sophi

Le 28/09/2023 à 21:36, Eyal Rozenberg a écrit :

I second John's sentiment.

For the vast majority of LibreOffice users, this security problem is
_not_ fixed. And that is because they run versions of LibreOffice with
the vulnerability but without the fix; and have not been made aware of
the vulnerability and the release-with-a-fix.

I would claim that we are responsible to make our users thus aware. Now,
it's true that a user is not likely to allow this particular exploit to
be taken advantage of, since that would mean directing LO at a malicious
.webp somewhere. But - we have over 200 million users IIANM. If
malicious .webp's turn up on the web, it's quite likely some of our
users may do this by mistake; and we would bear some of the
responsibility for the consequences of such an outcome - after we've
told our users that they are in the capable hands of "security experts"
(to quote our website).

Also, what if, next time, the vulnerability is easier to exploit? Do we
even have the mechanism to push at least a warning about the need to
update LO?


Eyal

PS 1: I have widened the CC of this exchange, as this question relates
to how we present LibreOffice to users; our claims regarding the quality
of this product; and the implicit and explicit guarantees we make to
users.

PS 2: Many of us are not able to attend ESC sessions - in general, and
especially in the middle of a work day. And when this is the case we
send an email asking for relevant issues to be considered. Personally, I
struggle to attend even the design meetings (where I believe I can be of
more use).




On 28/09/2023 11:44, John Mills wrote:

Hello Miklos,

Is it an acceptable statement just to say that "we" move on? Yes, the
issue is now resolved for those people that download the newest version
of LibreOffice. However what about the many millions of users that will
not update or have no idea that they are now susceptible to this high
rated CVE?

This is not a compelling strategy and does not serve the best interests
of these users. I think it is poor for the reputation of LibreOffice and
the Document Foundation that there are many millions of unpatched
instances being used that could negatively impact people like this.

Perhaps this particular CVE is on the scale of things considered not
that critical, however what is the strategy if there was ever an exploit
that significantly impacted LibreOffice? How would this be made known to
our user and corrected?

With best regards,

John

Sent from Yahoo Mail on Android
<https://ma

Re: [Libreoffice-qa] ESC meeting agenda: 2023-09-28 16:00 CEST

[Eyal Rozenberg]

I second John's sentiment.

For the vast majority of LibreOffice users, this security problem is
_not_ fixed. And that is because they run versions of LibreOffice with
the vulnerability but without the fix; and have not been made aware of
the vulnerability and the release-with-a-fix.

I would claim that we are responsible to make our users thus aware. Now,
it's true that a user is not likely to allow this particular exploit to
be taken advantage of, since that would mean directing LO at a malicious
.webp somewhere. But - we have over 200 million users IIANM. If
malicious .webp's turn up on the web, it's quite likely some of our
users may do this by mistake; and we would bear some of the
responsibility for the consequences of such an outcome - after we've
told our users that they are in the capable hands of "security experts"
(to quote our website).

Also, what if, next time, the vulnerability is easier to exploit? Do we
even have the mechanism to push at least a warning about the need to
update LO?


Eyal

PS 1: I have widened the CC of this exchange, as this question relates
to how we present LibreOffice to users; our claims regarding the quality
of this product; and the implicit and explicit guarantees we make to users.

PS 2: Many of us are not able to attend ESC sessions - in general, and
especially in the middle of a work day. And when this is the case we
send an email asking for relevant issues to be considered. Personally, I
struggle to attend even the design meetings (where I believe I can be of
more use).




On 28/09/2023 11:44, John Mills wrote:

Hello Miklos,

Is it an acceptable statement just to say that "we" move on? Yes, the
issue is now resolved for those people that download the newest version
of LibreOffice. However what about the many millions of users that will
not update or have no idea that they are now susceptible to this high
rated CVE?

This is not a compelling strategy and does not serve the best interests
of these users. I think it is poor for the reputation of LibreOffice and
the Document Foundation that there are many millions of unpatched
instances being used that could negatively impact people like this.

Perhaps this particular CVE is on the scale of things considered not
that critical, however what is the strategy if there was ever an exploit
that significantly impacted LibreOffice? How would this be made known to
our user and corrected?

With best regards,

John

Sent from Yahoo Mail on Android
<https://mail.onelink.me/107872968?pid=nativeplacement=Global_Acquisition_YMktg_315_Internal_EmailSignature_sub1=Acquisition_sub2=Global_YMktg_sub3=_sub4=10604_sub5=EmailSignature__Static_>

On Thu, 28 Sept 2023 at 8:13 am, Miklos Vajna
 wrote:
Hi Eyal,

On Wed, Sep 27, 2023 at 08:31:04PM +0300, Eyal Rozenberg
mailto:eyalr...@gmx.com>> wrote:
 > I would like to ask you to discuss the situation with the recent CVE:
 > https://bugs.documentfoundation.org/show_bug.cgi?id=157231
<https://bugs.documentfoundation.org/show_bug.cgi?id=157231>

It was already discussed 2 weeks ago. If you have specific questions,
please ask on the developer list or take part in the ESC call yourself.

In short: the problem is fixed, it's released, we move on.


Regards,

Miklos

Re: [Libreoffice-qa] ESC meeting agenda: 2023-09-28 16:00 CEST

[Eyal Rozenberg]

Hello ESC,

I would like to ask you to discuss the situation with the recent CVE:
https://bugs.documentfoundation.org/show_bug.cgi?id=157231

which potentially affects LibreOffice:
https://bugs.documentfoundation.org/show_bug.cgi?id=157231

Specifically:

1. Please asses the potential effect on LO.
2. Please list the scenarios in which LO may be affected.
3. What capability do we currently have to strongly-encourage users to 
update to a secure version (assuming one is available)?
4. What capability do we currently have to force users to update to a 
secure version (assuming one is available)?
5. Assuming the answer to (3.) or (4.) is "none" - consider taking a 
decision on changing that, with high priority, even if the current CVE 
is rarely dangerous for LO users.
6. Assuming the answer to (3.) or (4.) is "some" - please decide whether 
to do so, or recommend the board decide to do so etc.


Eyal


On 27/09/2023 18:12, Miklos Vajna wrote:

Hi,

The prototype agenda is below. Extra items are appreciated either in
this document or as a reply to this mail:

https://pad.documentfoundation.org/p/esc

You can join using Jitsi here:

https://jitsi.documentfoundation.org/esc

Regards,

Miklos

---

* Present:
     +

* Completed Action Items:

* Pending Action Items:
     + Try gtk4 local builds, Qt6 local builds (Cloph)
     + review bot: ignore distro branches when adding reviewers (Xisco)

* Release Engineering update (Cloph)
     + 7.6 status:
     + 7.5 status:

* Documentation (Olivier)
     + Bugzilla Documentation statistics
     272(272) bugs open
     + Updates:
     BZ changes   1 week   1 month   3 months   12 months
    created 6(2) 19(2)  70(1)  298(0)
  commented 6(0) 48(-9)    225(-12)   1079(-15)
   resolved 0(-2) 4(-1) 30(0)  163(-2)
     + top 10 contributors:
   Stéphane Guillou made 16 changes in 1 month, and 341 changes 
in 1 year
   Olivier Hallot made 13 changes in 1 month, and 440 changes in 
1 year
   Ilmari Lauhakangas made 8 changes in 1 month, and 114 changes 
in 1 year
   Nabet, Julien made 8 changes in 1 month, and 39 changes in 1 
year

   aswath t made 5 changes in 1 month, and 5 changes in 1 year
   Jim Avera made 5 changes in 1 month, and 5 changes in 1 year
   steve made 4 changes in 1 month, and 18 changes in 1 year
   Seth Chaiklin made 4 changes in 1 month, and 306 changes in 1 
year
   Vernon, Stuart Foote made 3 changes in 1 month, and 44 
changes in 1 year
   Heiko Tietze made 2 changes in 1 month, and 107 changes in 1 
year


* UX Update (Heiko)
     + Bugzilla (topicUI) statistics
     259(259) (topicUI) bugs open, 57(57) (needsUXEval) needs to be 
evaluated by the UXteam

     + Updates:
     BZ changes   1 week   1 month   3 months   12 months
  added  3(2) 14(4) 20(4)   45(2)
  commented 27(-3)   181(-3)   461(15)    2324(-7)
    removed  0(0)  0(0)  1(-1)  20(-4)
   resolved 10(7) 35(5) 86(9)  330(2)
     + top 10 contributors:
   Heiko Tietze made 114 changes in 1 month, and 1385 changes in 
1 year
   Stéphane Guillou made 45 changes in 1 month, and 468 changes 
in 1 year
   Eyal Rozenberg made 41 changes in 1 month, and 324 changes in 
1 year
   Kaganski, Mike made 29 changes in 1 month, and 144 changes in 
1 year

   Dieter made 20 changes in 1 month, and 247 changes in 1 year
   Vernon, Stuart Foote made 19 changes in 1 month, and 405 
changes in 1 year

   ady made 18 changes in 1 month, and 110 changes in 1 year
   Fortin Tam, Jean-François made 11 changes in 1 month, and 16 
changes in 1 year

   Bogdan B made 10 changes in 1 month, and 105 changes in 1 year
   neil made 10 changes in 1 month, and 10 changes in 1 year

* Crash Testing (Caolan)
     + 22(+0) import failure, 0(+0) export failures
     + ??? coverity issues
     + Google / ossfuzz: ?? fuzzers active now

* Crash Reporting (Xisco)
     + 7.6.0.2    105(+1)
     + 7.6.0.3    9755(+1827)
     + 7.6.1.2    3478(+2545)
     + 7.6.2.1    16(+0)

* Mentoring (Hossein)
   committer...   1 week 1 month  3 months 12 months
   open  45(-10) 97(-7)  156(-7)   209(-2)
    reviews 226(-42)   1236(-140)   3408(-12)    11502(4)
     merged 169(-25)    989(-78)    3080(-107)   
12609(-110)

  abandoned   4(-6)  60(-9)  142(-10)  634(-15)
    own commits  99(34) 657(-17)    2062(13)  9688(-75)
     review commits  35(17) 179(-38) 628(0)   3025(1)
     contributor...   1 week 1 month  3 months 12 months
   open  26(5)   56(11)   91(15)   117(16)
    reviews 

Re: [Libreoffice-qa] [libreoffice-design] Minutes from the UX/design meeting 2023-Jul-13

[Eyal Rozenberg]

Oh, no, no, no, come on... I know I wasn't in the session (which I
couldn't since it was in the middle of a workday), but - there had been
extensive discussion on the bug pages, and the session itself seems to
have just ignore it all. This is really exasperating.


--


>   * Autocorrect replaces " - " with " – " instead of " — "
> (en-dash instead of em-dash)
> + typically two hyphen is an EN-dash, three EM (Heiko)

I've explained several times on the bug page that this bug is not about
when people are trying to explicitly express a choice between the two
kinds of longer dashes.

> + two dashes with / without spaces is kind of standard and
>   working like this in MSO (Hossein)

Same point. Heiko had definitely read the bug page, so he should have
known this already; Hossein - perhaps the bug was mis-described in the
Jitsi session and you didn't have the time to read the comments?

> + maybe drop the conversion of single hyphen (Stuart)

(This is not a misinterpretation, but it may be inspired by the
misinterpretation above) Of course not drop the conversion of a single
hyphen! That's an very important autocorrect feature: Most people use
minus/dash because they are unaware of the different types of dashes, or
because they don't know / haven't thought about how to insert different
kinds of dashes (or because they're lazy). This autocorrection helps
improve the typesetting quality of the work of "lay users".

> + clearly described in
> https://help.libreoffice.org/latest/en-US/text/shared/01/06040100.html

1. It clearly says in the help page that space,minus,space is replaced
with space,en-dash,space. Which is the behavior I'm suggesting be changed.
2. Help contents is never a justification for a choice of behavior of
the app itself.

> + two dashes without spaces like 1--2 is not correctly
>   converted (Heiko)

That's interesting - but unrelated to this bug. Open a separate bug...
No "bug hijacking" with something which is clearly not part of the scope
of the original bug.

> => bug; do not change the behavior as described in the help

How does this conclusion relate even to what you guys were saying before?!

And other than Stewart's position (which I disagree with but nullifies
the question in this bug) - none of the discussants even tried to argue
that it is better for text to have space,en-dash,space's instead of
space,em-dash,space's.


--


  * Support distinction rather than override of conflicting
    subdocument styles
    + https://bugs.documentfoundation.org/show_bug.cgi?id=155740
    + unclear use case (David)
    + some confirmation per document (Shu)
  + if we better go with a global master switch (Heiko)
    + master documents are a special workflow aiming for style
  consistency, WF (Mike, Hossein)


No, they aren't. A single document is the workflow for absolute style
consistency. Master documents are workflows for composing a larger
document from smaller documents, _which well be valid documents on their
own_.


    + unclear use case (David)


Second time this is said. Actually, third time, since this was said on
the bug page, and I clarified. What about that did not seem clear?


    + copy/paste could solve alternative workflows (Shu)


If it could, we wouldn't need master documents in the first place.

And, again, that's just a repetition of points which had been made, and
rebutted, on the bug page. To make them again, one must address and
reject the rebuttal.

---


  * When setting the Heading/Outline Numbering for a level to "None",
    still getting separators
    + https://bugs.documentfoundation.org/show_bug.cgi?id=156089
    + works like in MSO, WF (Justin)
    + no reason to block, WF (Heiko)
    + asking to _clear_ the separator fields in case of None (Eyal)
  + remembering "Chapter/:" is not a (good) solution since users may
    change it for None into "-/>", or the like, making it very
    difficult to follow
    + behavior existing for years shouldn't change without
  good reasons (Hossein)
    + list style is something you shouldn't change multiple times


Less frustrated about the objections here, but - the basic argument,
which was not rebutted, is that our current behavior is the opposite of
what the user expects to happen.

An especially problematic argument is "this has been the behavior for
years". Most of the bugs we consider in the design sessions are about
behaviors LO has had for years. That's not an argument against
addressing them, it's just a sign of the limitation of our resources.

Re: [Libreoffice-qa] ESC budget item review meeting agenda: 2023-06-22 16:00 CEST

[Eyal Rozenberg]

Unfortunately, I won't be able to make it... :-(

Can you explain what the "reviewed items" list means? The other lists
have suggestions regarding what to do with each item; is the "reviewed
items" list what you're planning to go over during the meeting?

Also, on a semi-related note and looking forward to next year - it would
be helpful if there were some guidelines of what makes for a "good"
tender proposal, or one that's more likely to be considered and
accepted. For example: How wide the scope should be, so as to avoid a
review result of "need to split this up".

Eyal

On 21/06/2023 19:19, Ilmari Lauhakangas wrote:

Hi,

this will be an exceptional meeting where we decide on the advice to
give to TDF board of directors regarding projects to tender. Minutes
will be kept in the pad:

https://pad.documentfoundation.org/p/esc

You can join using Jitsi here:

https://jitsi.documentfoundation.org/esc

TDF staff may add more items up until the meeting starts. Unfortunately
due to time constraints we were unable to review every item. Any
omission can be discussed in the meeting.

I will run the meeting.

Regards,
Ilmari Lauhakangas
Development Marketing at TDF

* Present:
     + Affiliated with TDF:
     + Affiliated with Collabora:
     + Affiliated with allotropia:
     + Unaffiliated:

* Spreadsheet with comments from TDF staff:
https://nextcloud.documentfoundation.org/s/i9CSEs2gjFisc2y

* Budget pages for reference:
     + https://wiki.documentfoundation.org/Development/Budget2021
     + https://wiki.documentfoundation.org/Development/Budget2022
     + https://wiki.documentfoundation.org/Development/Budget2023

* Propose to drop it
     + Automated test tools for finding text rendering defects
     + Rolling Release: Finish MAR-based autoupdater for Windows (2021)
     + Stabilize cross-page table layouting (2022)

* Propose to put it on hold for now
     + XLSX Aggressive Competitors tracker: table styles (ranked 6 in
Feb 2023)
     + Power optimization research (ranked 43 in Feb 2023)

* Propose to split it into smaller tenders
     + Missing ODF Features (general collection)

* Reviewed items
     + Cleanup & further improve ODF conformance (2021)
     + Convert Impress slideshow to drawinglayer primitives (2021)
     + Font subsetter for font embedding (2022)
     + XLSX Aggressive Competitors tracker: gridlines for 3d line charts
(2022)
     + Look-ahead styleref field for Writer (2022)
     + Normalized spell checking (2022)
     + SVG rendering improvements (ranked 4 in Feb 2023)
     + Remove/Replace usages of XOR-Paint (2022)
     + XLSX Aggressive Competitors tracker: support math equations in
Calc shapes (ranked 12 in Feb 2023)
     + Missing ODF Features: The attribute draw:text-rotate-angle is
interpreted, but there exists no user interface to change it. (ranked 33
in Feb 2023)
     + Missing ODF Features: Attribute svg:d of  some of the
possible commands are missing (ranked 30 in Feb 2023)
     + Missing ODF Features: Draw:shadow-offset-x/y only partially
implemented (ranked 38 in Feb 2023)
     + Missing ODF Feature:  missing completely
(ranked 33 in Feb 2023)
     + Replace remaining Carbon functions with non-Carbon functions
(macOS) (ranked 38 in Feb 2023)
     + Tests for drawinglayer and basegfx (ranked 41 in Feb 2023)
     + Bitmaps in vcl: Merge RGB and A layer into one (2022)
     + Make Firebird implementation production-ready (ranked 3 in Feb 2023)
     + ODT export nondeterminism (2022)
     + Writer tables: support cell margins (next to cell padding) (2021)
     + Rotated Writer TextFrames (ranked 9 in Feb 2023)
     + Allow inline graphics, formulas in impress (and draw), open
equation with inline formulas from PPT, PPS, PPTX, PPSX (ranked 1 in Feb
2023)

* For reference, top 15 still relevant ideas from the February 2023 ESC
ranking:
     1: Allow inline graphics, formulas in impress (and draw), open
equation with inline formulas from PPT, PPS, PPTX, PPSX
     2: Migrating to single modern 2D graphics library
     3: Make Firebird implementation production-ready
     4: SVG rendering improvements
     5: Fix unreliable unit tests
     6: XLSX Aggressive Competitors tracker: table styles
     9: Rotated Writer TextFrames
     9: Continuous Section Breaks
     12: XLSX Aggressive Competitors tracker: support math equations in
Calc shapes
     13: 3D rotation of Impress shapes
     14: Chart creation speed
     17: Split-pane documents
     17: Improve visual appearance of tracked changes
     17: Unit in numerical inputs
     19: Add more combo chart types

Re: [Libreoffice-qa] Minutes from the UX/design meeting 2023-Jun-15

[Eyal Rozenberg]

On 15/06/2023 18:29, Heiko Tietze wrote:

Present: Happy, Hossein, Heiko
Comments: Mike, Dieter, Eyal


Tickets/Topics


  * More centralized endnote/footnote settings
    + make footnote numbering page-style-specific, rename the Insert > F
  dialog "Out-of-order Note" or "Special Note", provide access to
Page Style
  from F (Eyal)
    + off topic here, depends on bug 155712; if footnotes were bound to
  page style it would be confusing for left/right varying styles


"Left/Right varying styles" are already super-confusing and broken, see:

https://bugs.documentfoundation.org/show_bug.cgi?id=153534

and especially comments 5 and 11.

Eyal

Re: [Libreoffice-qa] QA Quick Start

[Eyal Rozenberg]

LibreOffice, like any application, is in a continuing process of gradual
change. Sometimes, these changes make bugs disappear - intentionally, or
incidentally due to other changes. It is important for developers to
know whether this has happened for a reported bug, because if it has:

* Developers would not try to look for the cause on the most current
version of the LibreOffice code.
* The priority for fixing the bug would likely be lower - as it will
most likely be "fixed" in the next release anyway by having gone away.
* Developers will have a better idea of where to look for the cause of
the bug - as they will know that recent changes have "touched" the code
somewhere which affects it.

Eyal

On 09/06/2023 0:24, Dominic Ricci wrote:



I am trying to help out with the duplication of bugs as per:

https://wiki.documentfoundation.org/QA/GetInvolved


I am running on MacOS and loaded the latest version of
LibreOffice - 7.5.4.2
I also created a Bugzilla account but am confused about hy  needed to
download and install a recent master build - step 2 below -

I figured I would try and duplicate the bug(s) on the latest stable
version - if I am successful with that duplication, would I then make
the latest /master build/ active then try to duplicate the issue there
as well? /*Just not certain why I needed to download and install the
master build - please advise.*/

Thanks,
Dominic

From: https://wiki.documentfoundation.org/QA/GetInvolved



  Quick start guide for beginners

If you are a beginner, chances are you are not looking forward to wading
through an insane amount of technical documentation. You would rather
want to get started immediately. Let's go.

 1. Download  and
install the latest stable LibreOffice (from the "Fresh" line)
 2. Download
 and
install a recent master build of LibreOffice
 3. Create an account
 in The
Document Foundation Bugzilla, the bug tracker

Re: [Libreoffice-qa] ESC meeting minutes: 2023-06-01

[Eyal Rozenberg]

About the tender project proposals:

The minutes refer to this list:

https://wiki.documentfoundation.org/Development/Budget2022

but - there is also this list:

https://wiki.documentfoundation.org/Development/Budget2023

I know that May 28th has passed, but these minutes were only sent 
yesterday, so... which list is it?


Also, if I want to suggest a project - should I create a Budget2024 wiki 
page? Should I edit the Budget2023 page? (In which case - who will 
notice newer vs older entries?) Should I talk about it in an ESC session 
first?


Eyal


On 01/06/2023 17:57, Miklos Vajna wrote:

* ESC tender project proposal process (Thorsten & Florian)
   + reportedly Ilmari was sharing some list of projects to review, see 
below
   + Review of the items selected by ESC from 
https://wiki.documentfoundation.org/Development/Budget2022 (Ilmari)
   + if anybody has further comments on the above list, deadline to 
provide your input is 28th of May (Thorsten)

   + couple of new proposals, but no cost estimates for them (Ilmari)
     + 
https://wiki.documentfoundation.org/index.php?title=Development%2FBudget2023=revision=672211=612682

     + worth estimating one or two of them?
   + process draft, full text:
     https://nextcloud.documentfoundation.org/s/YprpsFP45z7a7p3
   + next: effort estimates (Thorsten)
     + default would be to just disqualify the items without estimates
     + idea: only do estimates for the ideas which would be tendered
     + if can't find anybody who won't bid to estimate -> also disqualify
     + ideally somebody from TDF staff should own this process (Thorsten)
   + has the info from Thorsten from yesterday (Florian)
     + the board will do the formal decision, based on ESC suggestion
     + need to declare who will bid
     + new proposals will need person day estimates from non-bidders
     + probably Ilmari / Khaled can own the process
     + need to publish the ranking: in read-only mode
     + will work with Italo/Mike on the transparency section, before the 
first tender is published

   + next steps (Thorsten)
     + for old projects: need to re-do effort estimates by TDF staff
     + good to publish the list of projects that are in the budget 
(Thorsten)

     + would like the community to participate (Heiko)
   + why not all TDF members do the ranking?
   + assumption behind that was that some projects are extremely 
technical (Thorsten)
   + internal refactoring: people outside ESC would not consider 
such non-user-visible changes

   + but e.g. 10% could be decided by TDF members
   + idea was to let the engineering leadership to decide
   + next year the process can be a bit different (Florian)
     + good to improve things next year
     + ranking is decided by the consensus of the non-conflicted members 
(Thorsten)

   + but the ranking can be done by all ESC members
     + Items currently in the budget draft (Florian)
   + Text layout Cleanup & further improve ODF conformance
   + Rolling Release: Finish MAR-based autoupdater for Windows
   + C++ accessibility tests
   + Support for Editing and Creation of SmartArt
   + Convert Impress slideshow to drawinglayer primitives
   + Writer tables: support cell margins (next to cell padding)
   + Bitmaps in vcl: Merge RGB and A layer into one
   + Stabilize cross-page table layouting
   + Font subsetter for font embedding
   + Bitmaps in vcl: Use a native format/depth
   + ODT export nondeterminism
   + Remove/Replace usages of XOR-Paint
   + Decouple master slide and layouts
   + Look-ahead styleref field for Writer
   + Normalized spell checking
   + Missing ODF Features: Concentric gradient fill of custom-shapes
   + Bridge the gap between drawinglayer and VCL
   + XLSX Aggressive Competitors tracker: gridlines for 3d line charts
     + new ideas (Thorsten)
   + better text justification
   + AI-based text-to-speech, OCR, etc
     + next step (Florian)
   + by next week: have effort estimates checked by TDF staff (Xisco)
   + propose a separate call, for those who want to rank (Thorsten)
     + the week after
     + sorry for the double-estimate, can't avoid that
   + sounds like a good plan (Florian, Xisco)

* Crash Testing (Caolan)
     + 28(+0) import failure, 2(+0) export failures
   - Mike K. has one more fixed since
     + 0 coverity issues
     + 4 ossfuzz issues
   - no crashes
     + CVE-2023-2255 and CVE-2023-0950 published

* Crash Reporting (Xisco)
    + https://crashreport.libreoffice.org/stats/version/7.4.6.2
  + (-146) 653 799 666 871 679 676 683 513 392 371 241 0
    + https://crashreport.libreoffice.org/stats/version/7.4.7.2
  + (-1) 250 251 118 0
    + https://crashreport.libreoffice.org/stats/version/7.5.2.2
  + (-112) 628 740 674 1041 1070 1162 950 527 0
    + https://crashreport.libreoffice.org/stats/version/7.5.3.2
  + (+145)