[Wikidata-bugs] [Maniphest] T260737: Some types of edits with Wikidata Bridge do not have an applicable selector

[Charlie_WMDE]

Charlie_WMDE updated the task description.

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
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T260737: Some types of edits with Wikidata Bridge do not have an applicable selector

[abian]

abian added a comment.


  Hi, Charlie. 
  
  In T260737#6459414 , 
@Charlie_WMDE wrote:
  
  >> 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?
  
  I'm thinking of the scenario where the reader doesn't consider the original 
value to be incorrect or outdated but wishes to reflect a more precise/complete 
value. For example, they want to change "musem" to "history museum", or 
"cancer" to "prostate cancer", or "Berlin" to "Friedrichshain". In any case, 
this will hopefully be resolved with the possible rewording (the addition of 
"less […] complete or precise").
  
  >> 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.
  
  Great point, I hadn't thought of that. :-)
  
  >> 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!
  
  Perfect; from what we've discussed, I think the rewording would be enough to 
resolve this task. Thank you!

TASK DETAIL
  https://phabricator.wikimedia.org/T260737

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
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
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T260737: Some types of edits with Wikidata Bridge do not have an applicable selector

[Charlie_WMDE]

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
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T260737: Some types of edits with Wikidata Bridge do not have an applicable selector

[abian]

abian added a comment.


  Hi, Léa; I hope you have enjoyed the summer (which isn't technically over). 
:-)
  
  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 think that completing a value or making it more precise can be 
considered as "correcting". The action behind it would be the same (editing the 
existing value).
  
  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.
  
  > About "I know the original value is not applicable today but I cannot 
determine if it was correct at some point in the past or not.", is that a 
theoretical example, or did you encounter this situation in the past? If so, 
can you tell us more about this example?
  > If someone is facing this situation, what should be the related action on 
Wikidata?
  
  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. (?)
  
  ---
  
  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.

TASK DETAIL
  https://phabricator.wikimedia.org/T260737

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
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
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T260737: Some types of edits with Wikidata Bridge do not have an applicable selector

[Lea_Lacroix_WMDE]

Lea_Lacroix_WMDE added a comment.


  Hi Abian, thanks for your report :)
  
  The options we present on this screen are connected to the type of edit that 
the Bridge does on Wikidata. For example, it can directly update the existing 
value of a statement (option 1, correct), or add a new value (option 2, 
update). In the future, it will also be able to deal with statements having 
several values, with ranks, editing the labels of a value having the datatype 
Item, etc. So behind each option lies the adapted action on Wikidata.
  
  We think that completing a value or making it more precise can be considered 
as "correcting". The action behind it would be the same (editing the existing 
value).
  
  About "I know the original value is not applicable today but I cannot 
determine if it was correct at some point in the past or not.", is that a 
theoretical example, or did you encounter this situation in the past? If so, 
can you tell us more about this example?
  If someone is facing this situation, what should be the related action on 
Wikidata?
  
  Overall, we are trying to keep the number of choices short, so the user 
doesn't feel overwhelmed with options that they didn't know were even possible. 
We do not offer an "other reason" option, as it would not be connected to any 
specific action on Wikidata. We acknowledge the fact that they are options that 
are not perfectly covered by the Bridge, but we hope that the most usual cases 
are covered.

TASK DETAIL
  https://phabricator.wikimedia.org/T260737

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lea_Lacroix_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
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T260737: Some types of edits with Wikidata Bridge do not have an applicable selector

[abian]

abian updated the task description.

TASK DETAIL
  https://phabricator.wikimedia.org/T260737

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: 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
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T260737: Some types of edits with Wikidata Bridge do not have an applicable selector

[abian]

abian created this task.
abian added projects: Wikidata-Bridge, Wikidata.
Restricted Application added a subscriber: Aklapper.

TASK DESCRIPTION
  **Problem**: As a user, when I'm editing Wikidata from Wikipedia with 
Wikidata Bridge, sometimes I don't have a radio button representing the type of 
edit I'm making. For example, I don't have an applicable option when:
  
  - I'm completing or making more precise the original value, which I already 
considered correct but less detailed.
  - I know the original value is not applicable today but I cannot determine if 
it was correct at some point in the past or not.
  
  I should know which option to choose in these cases, either from the two 
existing options (in which case the descriptions should be rewritten) or from 
new ones.

TASK DETAIL
  https://phabricator.wikimedia.org/T260737

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: 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
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs