Wikidata:Requests for permissions/Bot/BorkedBot 7

BorkedBot 7 edit

BorkedBot (talk • contribs • new items • new lexemes • SUL • Block log • User rights log • User rights • xtools)
Operator: BrokenSegue (talk • contribs • logs)

Update youtube follower count data as frequently once per week.

Task/s: This is an extension of a previous request except now it is happening more frequently. See this request for more details on why @Sdkb: would want to do this.

Code: See User:BorkedBot

--BrokenSegue (talk) 19:45, 23 September 2021 (UTC)[reply]

I rather see it less frequently, but added to social media followers (P8687). Which is why we created that property. Continuously overwriting statements isn't really well received. --- Jura 19:52, 23 September 2021 (UTC)[reply]
- @Jura1: not sure I understand. the plan **is** to use that property. continuously overwriting is not my plan (though sometimes overwriting was suggested in the discussion). BrokenSegue (talk) 21:08, 23 September 2021 (UTC)[reply]
- Nevermind then. So we would have 50 statements after a year. --- Jura 08:53, 24 September 2021 (UTC)[reply]
This would possibly result in *lots* of updates, or in other words it consumes a noticable share of available edit resources. (I am factoring in here that others could do the same for follower counts of other services such as Facebook or Twitter or Instagram.) Can we apply some constraints here, e.g. only update if the increment is +10%, or only update if some milestone was reached? —MisterSynergy (talk) 19:55, 23 September 2021 (UTC)[reply]
- @MisterSynergy: Yes it would. What about only updating items that have an enwiki link. That's many fewer (though I don't have time to do a SPARQL query to quantify that at the moment). BrokenSegue (talk) 21:08, 23 September 2021 (UTC)[reply]
  I still see no value in tiny increment updates just because some time has passed. —MisterSynergy (talk) 21:17, 23 September 2021 (UTC)[reply]
  The value would be getting more integration with enwiki. BrokenSegue (talk) 21:19, 23 September 2021 (UTC)[reply]
  Even more for a Wikipedia article I do not see a reason to update to super precise numbers every week. Effectively only the ballpark figure of subscribers matters for an encyclopedia and an update scheme as proposed above would easily be sufficient to provide ballpark figures for Wikipedia.
  Another issue is that you are proposing to update weekly, but so many values are not desired per Property talk:P8687 (“one value per media and calendar year, not more than one per quarter”). You would either need to overwrite existing values every week and add a new claim every quarter (or year), or the affected items would become bloated with tabluar data quickly if you plan to violate this “rule”. —MisterSynergy (talk) 21:48, 23 September 2021 (UTC)[reply]
  +1 I agree, let's not bloat WD. The full tabular data could be collected by someone and uploaded to Commons for users to consume if they want more details.--So9q (talk) 15:41, 26 September 2021 (UTC)[reply]
I think once per year at social media followers (P8687) would be good + some milestones. --- Jura 20:37, 23 September 2021 (UTC)[reply]
- Yeah that's roughly what was initially approved. BrokenSegue (talk) 21:08, 23 September 2021 (UTC)[reply]
- I don't think that would be enough, per the reasoning I gave in the link at the top. I like MisterSynergy's idea to only update if it's a 10% change or a milestone. {{u|Sdkb}} ^talk 23:15, 29 September 2021 (UTC)[reply]
Would you be ok with that compromise @Jura1: @So9q:? BrokenSegue (talk) 23:26, 29 September 2021 (UTC)[reply]
Wouldn't an update every +10% lead to even more data than what was initially proposed? Milestones like every n in 10^n seem a good idea. Some sites don't even display the detailed count by default, so I'm not really convinced that an encyclopedia should do that. --- Jura 03:51, 30 September 2021 (UTC)[reply]

I honestly have a hard time imagining the effect of the proposal of Jura and the 10% proposal. This is somewhat similar to the issue of COVID death tabular data being thrown into COVID items by a bot. A lot of statements with very little or no value, especially if you consider that the way they are generated is imprecise and differs from country to country. Why not just link in 1 statement to tabular data at commons? (I don't know how that works over time, though).--So9q (talk) 07:52, 30 September 2021 (UTC)[reply]

Have a look at the proposal for P8687. I think we went through all possible options for the question at hand. --- Jura 07:59, 30 September 2021 (UTC)[reply]

Withdrawn Looks like this isn't going anywhere. BrokenSegue (talk) 17:26, 12 October 2021 (UTC)[reply]

@BrokenSegue, this is a deeply unfortunate outcome. If we cannot a find a way to move forward with Wikidata and Wikipedia integration in areas like this that are practically screaming for it, our hope of someday achieving fuller integration is utterly doomed. If this stands, it will block me from moving forward, as I can pretty much guarantee that Wikipedians won't find the current yearly updates frequent enough. Could we try again, going with +15% or a 10^n milestone from the start, and concisely laying out the reasoning in the task description rather than just putting a link to the bot request and hoping others read it (which many won't)? {{u|Sdkb}} ^talk 18:11, 14 October 2021 (UTC)[reply]

@Sdkb: I agree this outcome is unfortunate but it didn't seem like this request was going anywhere. you can feel free to open a new request with a modified proposal and if you can win support for some compromise I will implement it. I feel like including only items with enwiki entries and only at certain milestones should be a workable compromise. BrokenSegue (talk) 21:35, 14 October 2021 (UTC)[reply]

Okay, I've opened an RfC at Wikidata:Requests for comment/Frequency of YouTube follower count data. I'm not overly familiar with Wikidata RfCs, so please lmk if I've done anything wrong there. {{u|Sdkb}} ^talk 22:59, 14 October 2021 (UTC)[reply]