Unable to follow instruction of ST Admin (per e-mail)

Sat Jul 28 03:26:00 CDT 2018

Sorry, ultimately below I forgot to mention a typo I left in 2 values so they couldn’t be upvoted, 
leaving inconsistent data because we aren’t able to correct any value during the vetting phase. 
That is documented on the forum (but ST fora cannot be viewed without credentials) and in 
ticket 11296:
http://unicode.org/cldr/trac/ticket/11296

Another way to fix that problem, if write privileges must be refused during vetting, is to add
an edit button to each value a given contributor added during survey, so everybody will be 
able to correct his or her own data, while being forbidden to add values to other items. But 
still the efficiency and ROI of that scheme is doubtful as it wouldn’t allow to fix issue 4 below
(cf. note to #4 below).

On 28/07/18 04:38, Mark Davis ☕️ wrote:
>
> By "errors", we mean those in the Dashboard. Those need to be fixed, one way or another,
> before v34 is released so that . It should have been more clearly stated in the message.

#1 There was actually a set of red-flagged errors, that have been fixed following your instructions 
and Philippe Verdy’s recommendation. Seeing these in the dashboard was useful, ST heuristics 
made that possible as they succeed in catching conflicts. However we’ve been lucky, given ST
typically red-flags only one side of a conflicting pair, and it happened to be the right one. That 
is not always true. Better to flag both sides, so vetters can always pick the one that is actually 
to be changed.

#2 But many many errors are not caught by ST heuristics, such as a short form mistakenly used 
where a long form is required (2+1 items were overlooked). ST already checks the length of the 
narrow forms. It could check, too, for consistent length between long and short forms. But that 
would merely allow to red-flag those errors, allowing vetters to fix them. Now we’re aware of 
these 3 items, as they came up in the vetting phase, but for 2 of them there are even no means 
to fix them any more.

#3 A set of other items are not fixed because ST diverted vetters from upvoting them, by wrongly 
flagging them as "fallback" with darker blue background as if they were inherited from English, 
while actually they’ve been added during survey. As many as 4 instances fall under this category.
This ST bug has been reported in ticket 11298.
http://unicode.org/cldr/trac/ticket/11298

#4 The casing issue with the names of the signs of the zodiac is fixed in fr-CA but should be so in fr.
ST should red-flag those items. It already checks whether sublocales are diverging on a given item, 
so it should simply put them on the dashboard, because of multiple cases where various sublocales 
corrected on their part instead of correcting fr for inheritance.

Note: Issue 4 came up during vetting, while another issue related to these items was discussed with 
respect to fr-CA. During submission I didn’t get aware as I hadn’t enough time to review all data. See 
my second e-mail in this thread:
http://unicode.org/pipermail/cldr-users/2018-July/000806.html

#5 By what I consider as a design mistake, the narrow display forms of measurement units are excluded 
from coverage level "Modern". Many organizations don’t allow their vetters to work under coverage 
Comprehensive, or did allow in one era and forbid in present days, so that people are prevented from 
checking and fixing the errors, let alone that narrow display forms don’t have enough support. So that 
part of CLDR is simply unusable, and CLDR/ICU are deceiving users by delivering sort of fake data 
simply because whole categories are added and then vetters are discouraged from catering for the data.

>From all that it becomes clear we should not narrow error-fixing to the dashboard, nor to coverage 
level "Modern"; and that if nonetheless we do, many errors pass through, and the release is unreliable 
and has limited usability.

> As for disputes between vetters,

Sorry, we don’t have any “disputes”.

> there is always room for improving the process, and we are looking at ways to encourage more effective
> participation and use of the forums in settling disputes.

That is always a good concern. The big big problem in use of ST fora is in alert settings. Actually we get alerts 
from any post, including those that we’ve posted ourselves. Sorry to say bluntly that this is sheer nonsense as 
it annihilates effectiveness of those alerts that are really relevant as coming from co-vetters, actually drowned 
in a flood of e-mails of similarly looking sender (not completed with submitter name as from the mailing lists).
That is how I happened missing other people’s posts, as I’m unwilling to open dozens of alerts bringing to me 
some content I already know for having posted it myself. I’ve filed a ticket about that on July 13:
http://unicode.org/cldr/trac/ticket/11266

> Right now, people can't tell what it means when nobody responds to their posts.

In these days, my only concern with forum posts is that *no TC member* does respond in any of our threads.
(Except in fr-CA threads.)

> For example, it could mean (a) people didn't see the post,

See above about how that typically happens.

> or (b) people saw the post but disagreed with it (seeing no reason to change their votes), or some other reason.

OK sometimes I saw a post but was so busy with submitting data that I’d no mind left over, or didn’t make up 
my mind until I came round another day. Regularly browsing the forum is very important, and that’s the way I
ultimately found threads and posts I wasn’t aware of. But again, that’s unrelated to my actual concern about 
TC review.

> In the past, we were only showing the forum posts from the current release, but we are now preserving all of them.
> That way people will be able to see and consider the threads in the next cycle(s) of submission.

Very good. Thanks!

> We also now have a full-time engineer working to remove some of the worst "rough edges" in the tool,
> so we're prioritizing the tickets to try to get the highest ROI ones fixed for the next cycle.

What would have been the Right Thing to Do is just copy-paste the provided patch into survey.js for ST to 
display the confusable spaces in a useful way. That feature alone, requested on June 29, with patches posted 
from July 7–10, would significantly reduce the amount of time required for survey, actually with the use of a 
JS function in the browser console. 
And hence if timely implemented as requested, it would have drastically reduced the error rate. 
It will be useful to check letter apostrophe and an extensible set of other characters as well.
See:
http://unicode.org/cldr/trac/ticket/11235

I’ve pleaded for high priority on July 10:
http://unicode.org/cldr/trac/ticket/11235#comment:18

Best regards,

Marcel