Charlie_WMDE added a comment.
Thank you for your extensive reply!
> Thank you for the explanation. The risk I see in having two such opposite
and assertive options ("incorrect", "was not correct and has never been", etc.)
is that, in the grey area, or in case of doubt, users might end up choosing
randomly, and that, from what you say, might not be ideal because it would have
consequences on how values are finally reflected.
We see your point here. We carefully considered only having two options,
rather than more, because the danger of having multiple options is of course
that people wouldn’t know which one fits their case best and would also pick
randomly. We’re currently considering adding some sort of explanatory text, to
help in the situation of doubt.
> Okay. Then the description might be incomplete; for example, if I change a
territorial administrative unit to a lower one, I wouldn't consider that the
previous value "was not correct and has never been". I personally would think
that I would have improved the original value, but not that the original value
was wrong, and I wouldn't know what to choose. In this situation people might
choose arbitrarily (if they didn't have much time) or they might feel forced to
ask about the consequences of these decisions and about Wikidata's policies on
when to add values and when to replace them.
I’m not sure i understand the scenario correctly, but i would think, if it
was a mistake, then choosing the first option “correcting” would be correct, if
the unit has changed then the “outdated” option would be the correct one to
pick. Can you clarify?
> First I thought of population figures for a municipality, the number of
employees in a company… mainly of quantities, but I think this would apply to
any other data type. If I read that a village has a population of 432 according
to the infobox, but I have just checked that today there are 276 inhabitants
according to an official source, I know that the value from the official source
can be considered correct now, but I don't know if the previous figure was
correct at some point in the past or not. It seems to me that this situation
will occur often, as normally we don't know the full history of anything and we
can't rule out that a value may have been correct an unknown number of years
ago.
>
> As to what the related action should be... in my opinion, the value should
be overwritten if it had no qualifiers or references, and preserved if it had a
reference or a qualifier (in this case, the new value should have a preferred
rank, and the original value should be downgraded to normal value if it had
been marked as preferred). But this is only my opinion, and I know it's a mess;
when in doubt, adding the value might be the lesser of two evils. (?)
That seems like a reasonable conclusion. Is there something that would stop
you from doing exactly that in the bridge? Currently we can not display
qualifiers unfortunately, but references can already be viewed. What you said
about the lesser evil makes a lot of sense to me. Maybe you’re suggestion of
putting the “outdated”-option first, would serve a second purpose. People will
more likely select the first option when in doubt.
> I am going to make some suggestions gathering all this together:
>
> - **The order of the options could be changed** so that the most specific
or less ambiguous option ("I updated") appears first. This might let the user
know that the wording of the second option is no longer covering the first case
("I corrected" does not include updating, because that option has already been
mentioned).
> - "I updated an outdated value / The previous value used to be correct but
now is outdated."
> - → "I updated **the (or "a")** value / The previous (or "original")
value **may have been** (to cover the doubtful case) correct but now is
outdated."
> - "I corrected an incorrect value / The previous value was not correct and
has never been."
> - → "I corrected **or completed the (or "a")** value / The previous (or
"original") value was **less** correct**, complete or precise**."
>
> These are just my suggestions, feel free to adapt or rule them all out if
they aren't useful.
I will run these past our technical writer. Thank you for the suggestions!
They both make a lot of sense to me!
TASK DETAIL
https://phabricator.wikimedia.org/T260737
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Charlie_WMDE
Cc: Lea_Lacroix_WMDE, Charlie_WMDE, abian, Aklapper, Akuckartz, darthmon_wmde,
Michael, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen,
rosalieper, Scott_WUaS, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
