Last modified: 2014-11-18 18:07:21 UTC
I think it would be better to tag bot edits with a 'b' by default just like how minor edits are marked with an 'm'. I think this can be achieved with a schema change to the revision table.
This enhancement request really consists of two parts: (In reply to comment #0) > I think it would be better to tag bot edits with a 'b' by default Part one: if the user is a bot, tag their edits as bot unless specifically requested is otherwise. > just like how > minor edits are marked with an 'm'. Part two: make the 'b's show up in the page history. > I think this can be achieved with a schema change to the revision table. More specifically, a rev_bot field would have to be created, mirroring the rc_bot field that already exists in the recentchanges table.
Actualy while discussing this idea with pathoschild something interesting came about. Why not prod the issue a bit further. The code could add a "bot" (variable - so that it can be translated to the local language) to the bots name? Current history line (from fr.wiki) 16:56, 2 September 2007 Ordinateur (Talk | contribs) m (43 bytes) (Robot : répare double redirection) (undo) how it would be: 16:56, 2 September 2007 ([[link to what a wikipedia bot is|Robot]])Ordinateur (Talk | contribs) bm (43 bytes) (Robot : répare double redirection) (undo)
(In reply to comment #2) That's unrelated. Please create a separate bug requesting it.
Schema change committed in r25602 and r25604. Once (and if) that's applied to Wikimedia sites, it should be simple enough to write the code to display it on history pages.
It was reverted in r25635. As rev_minor_edit field is tinyint, it could be overloaded to also store the bot flag (treating it as a bitfield).
(In reply to comment #5) > It was reverted in r25635. Probably only temporarily though: schema changes can't just be added to the trunk at any given time.
(In reply to comment #6) > Probably only temporarily though: schema changes can't just be added to the > trunk at any given time. Not if we convert rev_minor_edit to a bitfield, which is what I'd have suggested. Although I'd also have suggested renaming the column to something accurate...
We could make rev_minor_edit a bitfield, but then it should be renamed to rev_flags or something similar.
I think MySQL was too inefficient on renaming fields (or is it only renaming tables?).
(In reply to comment #5) > As rev_minor_edit field is tinyint, it could be overloaded to also store the > bot flag (treating it as a bitfield). Not if you want to be able to index it. Although currently, we don't index it anyway, so it might well be fine. Anyway, this would be a breaking change. All code accessing rev_minor_edit would need to be updated, including third-party code. It's not much less disruptive than a schema change.
Do not repurpose existing boolean fields into bitfields, please. Schema changes, if appropriate, will be made when we've got a clear opportunity to plan for them.
(In reply to comment #10) > Anyway, this would be a breaking change. All code accessing rev_minor_edit > would need to be updated, including third-party code. It's not much less > disruptive than a schema change. > Actually, adding a new rev_bot field would actually cause *less* trouble than the bitfield thing.
*** Bug 11444 has been marked as a duplicate of this bug. ***
Just a thought: Since we have now the change_tag table, couldn't it be used to tag bot edits (and maybe even minor ones) as well?
That would be something of a hack, and not really what it was designed for. Are tags stored indefinitely? I'm not familiar enough with the feature to know that.
*** Bug 16228 has been marked as a duplicate of this bug. ***
But in fact both "minor" and "bot" are tag like entities as well. It is not unlogical to store both in change_tags.
Some tasks need an analysis of the page history, and they are senseless without knowing which user is a bot. It is often necessary to separate bot edits from human ones.
Should we go through with this, or just scrap the whole idea?
There are a number of useful applications of such tagging. It is also useful to the user reviewing the edit itself. It also helps us catch people pretending to be bots when they aren't. I insist that going forward with the idea offers benefit.
If this is done, bug 19322 should also be done, which adds the bot field to log entries.
This is still very important, and many users wait for it being solved. I have a bot that analyses page histories and users want me to find the last human edit which I can't do now.
This bug is with us from 2007. Every year which passes schema change becomes more expensive. Maybe it is now time to made schema change?
