b***@wikimedia.org
2014-02-25 20:25:28 UTC
https://bugzilla.wikimedia.org/show_bug.cgi?id=61927
Bug ID: 61927
Summary: Flow: Sends malformed RC events
Product: MediaWiki extensions
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: Flow
Assignee: wikibugs-***@lists.wikimedia.org
Reporter: ***@gmail.com
CC: ***@wikimedia.org, ***@wikimedia.org,
***@gmail.com, ***@wikimedia.org
Web browser: ---
Mobile Platform: ---
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.
Bug ID: 61927
Summary: Flow: Sends malformed RC events
Product: MediaWiki extensions
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: Flow
Assignee: wikibugs-***@lists.wikimedia.org
Reporter: ***@gmail.com
CC: ***@wikimedia.org, ***@wikimedia.org,
***@gmail.com, ***@wikimedia.org
Web browser: ---
Mobile Platform: ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.