Change Details

Activity (such as replies) in Flow currently result in the following RC entry: irc.wikimedia.org/#test2.wikipedia rc-pmtpa: [[Talk:Flow QA]] ! http://test2.wikipedia.org/w/index.php?diff=0&oldid=0&rcid=82816 * Krinkle * (+31) reply,rpw4ywdy0xw7t5ou,rpwgr7r79uy8pznh chat.freenode.net/#cvn-sw [[m:CVNBot]]: IP [[test2wiki:User:162.222.73.148]] matched edit summary "[bcdfghjklmnpqrstvwxz]{8,}" (possible nonsense) [[test2wiki:Talk:Flow QA]] (+22) Diff: https://test2.wikipedia.org/?diff=0&oldid=0&rcid=82813 "reply,rpwgkgfa3bbexlwf,rpwgkgfd7m5qq1b3" It is paramount that Flow generates more sensible RC events before being enabled in a visible way, to avoid: 1) Unusable clutter for vandalism patrollers (they are overwhelmed as it is already in our crippled system). -- and, though less important for the short term: -- 2) Spam evading our patrollers. #1 Would be solved by having these not be useless (either don't emit rc events for now, or implement them in a way that produces a useful link and doesn't abuse the edit summary field). #2 Would be solved by making the content actions (creation and modification of posts) patrollable by: * - Defaulting to rc_patrolled=0 * - Exposing the [mark as patrolled] link somewhere in the UI or; by continuing to keep them outside rcpatrol and instead provide a different means for patrollers to monitor Flow events on wikis with $wgUseRCPatrol enabled. Though I'd recommend against that as that will likely not take off and not integrate with any of the dozens of patrol workflows, and considering the patrol workforce isn't huge, giving them yet another thing to monitor is probably not productive, and would also cost more work by the Flow team to invent. So best to simply defer to the system core already has available. It's a very minimal system (simple boolean flag and log event), but you'd be surprised how much unofficial infrastructure is built atop that. -------------------------- **Version**: unspecified **Severity**: critical **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=60559

Activity (such as replies) in Flow currently result in the following RC entry: irc.wikimedia.org/#test2.wikipedia rc-pmtpa: [[Talk:Flow QA]] ! http://test2.wikipedia.org/w/index.php?diff=0&oldid=0&rcid=82816 * Krinkle * (+31) reply,rpw4ywdy0xw7t5ou,rpwgr7r79uy8pznh chat.freenode.net/#cvn-sw [[m:CVNBot]]: IP [[test2wiki:User:162.222.73.148]] matched edit summary "[bcdfghjklmnpqrstvwxz]{8,}" (possible nonsense) [[test2wiki:Talk:Flow QA]] (+22) Diff: https://test2.wikipedia.org/?diff=0&oldid=0&rcid=82813 "reply,rpwgkgfa3bbexlwf,rpwgkgfd7m5qq1b3" It is paramount that Flow generates more sensible RC events before being enabled in a visible way, to avoid: 1) Unusable clutter for vandalism patrollers (they are overwhelmed as it is already in our crippled system). -- and, though less important for the short term: -- 2) Spam evading our patrollers. #1 Would be solved by having these not be useless (either don't emit rc events for now, or implement them in a way that produces a useful link and doesn't abuse the edit summary field). #2 Would be solved by making the content actions (creation and modification of posts) patrollable by: * - Defaulting to rc_patrolled=0 * - Exposing the [mark as patrolled] link somewhere in the UI (done, {T94452}) or; by continuing to keep them outside rcpatrol and instead provide a different means for patrollers to monitor Flow events on wikis with $wgUseRCPatrol enabled. Though I'd recommend against that as that will likely not take off and not integrate with any of the dozens of patrol workflows, and considering the patrol workforce isn't huge, giving them yet another thing to monitor is probably not productive, and would also cost more work by the Flow team to invent. So best to simply defer to the system core already has available. It's a very minimal system (simple boolean flag and log event), but you'd be surprised how much unofficial infrastructure is built atop that. -------------------------- **Version**: unspecified **Severity**: critical **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=60559

Activity (such as replies) in Flow currently result in the following RC entry: irc.wikimedia.org/#test2.wikipedia rc-pmtpa: [[Talk:Flow QA]] ! http://test2.wikipedia.org/w/index.php?diff=0&oldid=0&rcid=82816 * Krinkle * (+31) reply,rpw4ywdy0xw7t5ou,rpwgr7r79uy8pznh chat.freenode.net/#cvn-sw [[m:CVNBot]]: IP [[test2wiki:User:162.222.73.148]] matched edit summary "[bcdfghjklmnpqrstvwxz]{8,}" (possible nonsense) [[test2wiki:Talk:Flow QA]] (+22) Diff: https://test2.wikipedia.org/?diff=0&oldid=0&rcid=82813 "reply,rpwgkgfa3bbexlwf,rpwgkgfd7m5qq1b3" It is paramount that Flow generates more sensible RC events before being enabled in a visible way, to avoid: 1) Unusable clutter for vandalism patrollers (they are overwhelmed as it is already in our crippled system). -- and, though less important for the short term: -- 2) Spam evading our patrollers. #1 Would be solved by having these not be useless (either don't emit rc events for now, or implement them in a way that produces a useful link and doesn't abuse the edit summary field). #2 Would be solved by making the content actions (creation and modification of posts) patrollable by: * - Defaulting to rc_patrolled=0 * - Exposing the [mark as patrolled] link somewhere in the UI (done, {T94452}) or; by continuing to keep them outside rcpatrol and instead provide a different means for patrollers to monitor Flow events on wikis with $wgUseRCPatrol enabled. Though I'd recommend against that as that will likely not take off and not integrate with any of the dozens of patrol workflows, and considering the patrol workforce isn't huge, giving them yet another thing to monitor is probably not productive, and would also cost more work by the Flow team to invent. So best to simply defer to the system core already has available. It's a very minimal system (simple boolean flag and log event), but you'd be surprised how much unofficial infrastructure is built atop that. -------------------------- **Version**: unspecified **Severity**: critical **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=60559