[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 abraham.taheriv...@wikimedia.de changed: What|Removed |Added Status|NEW |RESOLVED CC||abraham.taherivand@wikimedi ||a.de Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 abraham.taheriv...@wikimedia.de changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #22 from abraham.taheriv...@wikimedia.de --- Verified at the Hackathon -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 Daniel Kinzler daniel.kinz...@wikimedia.de changed: What|Removed |Added See Also||https://bugzilla.wikimedia. ||org/show_bug.cgi?id=17237 -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 --- Comment #20 from Tyler Romeo tylerro...@gmail.com --- So, just to be clear, the plan is to commit a temporary hack into core just so a single WMF wiki can shorten their logs until somebody gets around to properly fixing the bug? That doesn't sound like the cleanest solution. -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 --- Comment #21 from Krinkle krinklem...@gmail.com --- (In reply to comment #20) So, just to be clear, the plan is to commit a temporary hack into core just so a single WMF wiki can shorten their logs until somebody gets around to properly fixing the bug? That doesn't sound like the cleanest solution. As both James and I have said, we have a plan in place to address this in a way that is acceptable to us (software developers product managers) and will not cause problems to users of wikidata and/or users active in countervandalism network. In fact, it'll make things better and allow for other interesting new features. However since making major schema changes requires a significant amount of coordination, database switches, and what not, it is not in our hands to make that happen. This is mostly up to platform operations. So, depending on whether our plan can be executed before wikidata explodes we will have to settle on an intermediate solution. The solution proposed in earlier comments before mine (disabling autopatrol logging on wikidata) is in my opinion not ideal, but it could be worse. I think it is acceptable if and only if it is temporary and only until we finish the larger schema change. -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 --- Comment #16 from James Forrester jforres...@wikimedia.org --- (In reply to comment #14) See bug 17237 for a solution based on discussion from Amsterdam Hackathon 2013 between Daniel, Tim and Timo. So this means that, if needed, we can proceed with this as a temporary hack in the Wikibase extension before we re-work master as part of the to-be-scheduled occasional MW core re-working that Tim agreed to (what are the Ops/growth issues and how quickly can we fix bug 17237?). -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 --- Comment #17 from Daniel Kinzler daniel.kinz...@wikimedia.de --- (In reply to comment #16) So this means that, if needed, we can proceed with this as a temporary hack in the Wikibase extension Which temporary hack are you referring to? I'm only aware of Ic999454d, which makes logging autopatroll events optional in core. I think we can and should go ahead with that. For now, the default should be to log autopatrolled events, and this should only be disabled for wikidata.org to avoid flooding the log. Once we have the patrolling info in the revision table, the log entries for autopatroll events are redundant, and might be turned off per default. -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 --- Comment #18 from Ariel T. Glenn ar...@wikimedia.org --- (In reply to comment #16) So this means that, if needed, we can proceed with this as a temporary hack in the Wikibase extension before we re-work master as part of the to-be-scheduled occasional MW core re-working that Tim agreed to (what are the Ops/growth issues and how quickly can we fix bug 17237?). The dump-related ops issues can be worked around for now with a functional if not awesome hack, for now. -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 --- Comment #19 from Krinkle krinklem...@gmail.com --- (In reply to comment #17) (In reply to comment #16) So this means that, if needed, we can proceed with this as a temporary hack in the Wikibase extension Which temporary hack are you referring to? I'm only aware of Ic999454d, which makes logging autopatroll events optional in core. I think we can and should go ahead with that. That is indeed the temporary hack James was referring to (I was sitting next to him when he wrote that). It is temporary because as soon as the _bot and _patrolled fields are moved to the revision table we shall remove logging of autopatrol from core entirely as I'm pretty sure there is no longer an acceptable use-case for them (especially as long as they remain to be logged as the same log_type and log_action as non-auto patrols - ergo it will fix bug 25799). Keeping it around under a feature flag seems pointless and only encourages a bad user experience for patrollers. For now, the default should be to log autopatrolled events, and this should only be disabled for wikidata.org to avoid flooding the log. Once we have the patrolling info in the revision table, the log entries for autopatroll events are redundant, and might be turned off per default. As James said, this is acceptable – assuming we've considered the feasibility of adding the patrolling info to the revision table soon enough for wikidata not to explode. That it will happen has pretty much been agreed on already, whether it is worth it to do this temporary hack first (thus semi-permanently losing some data about events in the database) or whether it is feasible to get this revision table change through before the problems becomes critical for wikidata. -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 --- Comment #15 from Ariel T. Glenn ar...@wikimedia.org --- +1 from me for that approach. It covers all my concerns. -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 --- Comment #14 from Krinkle krinklem...@gmail.com --- See bug 17237 for a solution based on discussion from Amsterdam Hackathon 2013 between Daniel, Tim and Timo. -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 --- Comment #13 from Ariel T. Glenn ar...@wikimedia.org --- So here is (part of) why the situation is different on wikidata than anywhere else. 1) Wikidata actually has more edits/sec than anywhere, including en wp. 2) Almost all of those edits are autopatrolled and wind up in the log. 3) On en wp a much tinier proportion of edits wind up in the log, since they don't use RCPatrol. The number of large projects with RCPatrol on and with lots of bot edits in a short period of time must be, well... one, and that's the one with the issue :-D If we want RCPatrol to scale then we need to rethink the ever-expanding log; even a 30 day retention is better than what we have now. I still claim that bot edits being autopatrolled and then logged is a waste of resources. -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 --- Comment #11 from Krinkle krinklem...@gmail.com --- (In reply to comment #8) [Speaking with my Product Manager for Admin Tools hat on.] (In reply to comment #5) I'm not sure what the point is of disabling auto patrol logging entirely. The point is to save Wikidata from falling over because the DB can't scale. (Note, BTW, that the proposal is only to disable autopatrol logging for Wikidata, not other wikis; you can see the default setting for MW itself in the commit.) The fault is not with Wikibase (which uses the entirely-reasonable concept of letting wiki users edit things in the same way as on core MW), but with MW core's design not being thought-through in terms of scalability. We already know that the revisions table's growth is a problem; patrolling logs cause a second table to also be a problem. How come this is a problem new with Wikidata? We have close to a 1,000 of wikis with many thousands of wiki-admins, stewards, bots, reviewers, rollbackers and patrollers etc. all who make lots of edits that are autopatrolled. (In reply to comment #7) I'm sorry, but I don't quite follow. When do you ever need to see the log entries for *auto*patrolled edits? Don't they just duplicate the page history? Yes, on a healthy wiki every revision would have a patrol entry at some point (either autopatrol or patrol by another user). This is nothing new. I can imagine this being a scalability problem, but I don't see how that only becomes a problem now. And if it is, I imagine we'll need a solution for other all other wikis as well (commons, enwiki, ..). Perhaps operations thinks that could be deferred to later, but if this is as important as some people make it seem, I imagine it is as much as problem elsewhere as for wikidata and we'll need single solution for all very soon. Is that worth boldly sacrificing the integrity of the database (inconsistently log entries missing for actions taken, that are usually there for the same action by other users and on all other wikis). If claim should not be subject to auto-patrolling or patrolling, then that should be disabled instead. Solving the claim auto patrol log problem, by disabling the logging for it entirely seems an odd way to solve the problem. I appreciate that this is disruptive for users of the patrolling logs, most notably the CVU tools, but this is a change made for site stability, and we must accept it. Maybe you mistunderstood, but I don't see how this relates to the cited statement. I am suggesting that if claim creations should not be reviewed through the patrolling system, what's stopping Wikibase from preventing the patrol entry in the first place? Perform the creation like other unpatrollable actions (such as uploads, they create an unpatrollable recentchanges entry and no autopatrol entry). I think it would be unfortunate if claims are not patrollable but since that seems already accepted, I'm merely suggesting we don't also disable logging for autopatrols outside this area (e.g. edits to regular pages, talk pages, categories, user pages, project pages etc.) -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 Daniel Kinzler daniel.kinz...@wikimedia.de changed: What|Removed |Added CC||daniel.kinz...@wikimedia.de --- Comment #12 from Daniel Kinzler daniel.kinz...@wikimedia.de --- I am suggesting that if claim creations should not be reviewed through the patrolling system, what's stopping Wikibase from preventing the patrol entry in the first place? Claim creation is a regular edit to an Item page. The RC entry is generated upon save, that is not under the control of the Wikibase extension. I suppose we could hack in and try to suppress patrolling based on some magic property of some edits. But I feel this introduces even more inconsistency (why do some edits require patrolling, and others don't?) Furthermore, Claim creation/changes by users without the Autopatroll right should still be patrolled, so suppressing patrolling for this type of edit is not desired. Yes, on a healthy wiki every revision would have a patrol entry at some point (either autopatrol or patrol by another user). This is nothing new. This is indeed an expectation we would break. But I don't see how, why or where this assumption is important or even relevant. Do you have an example? -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 --- Comment #10 from Tyler Romeo tylerro...@gmail.com --- (In reply to comment #9) Can we set up a rolling log instead? Like have the log entries vanish after 30 days (recentchanges table length). After that point you can't tell whether the edit was patrolled or not, so it would be pointless to know who patrolled it. This has the advantage of not breaking anything (hopefully), and being able to provide the necessary features that patrolling does, while still reducing the log table. I'm hesitant to set up an entire separate logging structure just for patrolling. At that point we might as well just make patrolling a recentchange itself and og it to the recentchanges table. -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 --- Comment #9 from Legoktm legoktm.wikipe...@gmail.com --- (In reply to comment #8) [Speaking with my Product Manager for Admin Tools hat on.] (In reply to comment #5) Solving the claim auto patrol log problem, by disabling the logging for it entirely seems an odd way to solve the problem. I appreciate that this is disruptive for users of the patrolling logs, most notably the CVU tools, but this is a change made for site stability, and we must accept it. Can we set up a rolling log instead? Like have the log entries vanish after 30 days (recentchanges table length). After that point you can't tell whether the edit was patrolled or not, so it would be pointless to know who patrolled it. This has the advantage of not breaking anything (hopefully), and being able to provide the necessary features that patrolling does, while still reducing the log table. -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 James Forrester jforres...@wikimedia.org changed: What|Removed |Added CC||jforres...@wikimedia.org --- Comment #8 from James Forrester jforres...@wikimedia.org --- [Speaking with my Product Manager for Admin Tools hat on.] (In reply to comment #5) I'm not sure what the point is of disabling auto patrol logging entirely. The point is to save Wikidata from falling over because the DB can't scale. (Note, BTW, that the proposal is only to disable autopatrol logging for Wikidata, not other wikis; you can see the default setting for MW itself in the commit.) That means patrolling tools will be unable to discover the log entry for a patrolled edit. Indeed. We have lost a lot of MW core functionality over the years because of our inability to design a system that can scale arbitrarily; this is not the first, and sadly won't be the last. If claim should not be subject to auto-patrolling or patrolling, then that should be disabled instead. The fault is not with Wikibase (which uses the entirely-reasonable concept of letting wiki users edit things in the same way as on core MW), but with MW core's design not being thought-through in terms of scalability. We already know that the revisions table's growth is a problem; patrolling logs cause a second table to also be a problem. Solving the claim auto patrol log problem, by disabling the logging for it entirely seems an odd way to solve the problem. I appreciate that this is disruptive for users of the patrolling logs, most notably the CVU tools, but this is a change made for site stability, and we must accept it. -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 --- Comment #4 from Gerrit Notification Bot gerritad...@wikimedia.org --- Related URL: https://gerrit.wikimedia.org/r/62785 (Gerrit Change Ic999454d001c38dea08746d1e8184f0163cb7330) -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 Krinkle krinklem...@gmail.com changed: What|Removed |Added CC||krinklem...@gmail.com --- Comment #5 from Krinkle krinklem...@gmail.com --- I'm not sure what the point is of disabling auto patrol logging entirely. That means patrolling tools will be unable to discover the log entry for a patrolled edit. If claim should not be subject to auto-patrolling or patrolling, then that should be disabled instead. Solving the claim auto patrol log problem, by disabling the logging for it entirely seems an odd way to solve the problem. -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 --- Comment #6 from Ariel T. Glenn ar...@wikimedia.org --- OK, I take your point. OTOH is there any real need for patrolling tools to discover lots and lots of log entries for autopatrolled bot entries? Maybe these can be excluded from the log and the rest left in. -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 --- Comment #7 from T. H. Kelly pinkampersand.wikime...@gmail.com --- (In reply to comment #5) I'm not sure what the point is of disabling auto patrol logging entirely. That means patrolling tools will be unable to discover the log entry for a patrolled edit. I'm sorry, but I don't quite follow. When do you ever need to see the log entries for *auto*patrolled edits? Don't they just duplicate the page history? -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 T. H. Kelly pinkampersand.wikime...@gmail.com changed: What|Removed |Added CC||pinkampersand.wikimedia@gma ||il.com --- Comment #3 from T. H. Kelly pinkampersand.wikime...@gmail.com --- Echoing Lego's comment, if there's a way to turn off the log function for *automatic* patrolling, but not manual, that'd be great. In fact, even without any server-related concerns that'd be great, since a log entry accompanying every edit essentially makes the patrol logs impossible to navigate. (There are a handful of circumstances where it's important to know who patrolled a page, e.g. if an obviously vandalistic page has been marked as patrolled and you want to know who did that, so you can explain things to them or pull their rights if necessary.) -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 Sam Reed (reedy) s...@reedyboy.net changed: What|Removed |Added Priority|Unprioritized |High -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 Aude aude.w...@gmail.com changed: What|Removed |Added CC||aude.w...@gmail.com --- Comment #1 from Aude aude.w...@gmail.com --- For reference, http://bugzilla.wikimedia.org/41907 is the request for enabling RC patrol on wikidata -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47415] creation of new claims (and perhaps other edits) can be (auto)patrolled on wikidata
https://bugzilla.wikimedia.org/show_bug.cgi?id=47415 Legoktm legoktm.wikipe...@gmail.com changed: What|Removed |Added CC||legoktm.wikipe...@gmail.com --- Comment #2 from Legoktm legoktm.wikipe...@gmail.com --- RC patrol is useful for anyone trying to fight vandalism since it immediately removes trusted or already checked edits. I think it would be more useful to remove useless log entries like automatically marked revision 27230780 of page Colin McWilliam (Q5145398) patrolled which I doubt anyone checks or cares about. -- You are receiving this mail because: You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
