Last modified: 2011-04-14 15:13:31 UTC
Suggestion: Have a mechanism whereby anonymous IP edits can be reattributed to an editor who is editing from that same IP, within some timespan (eg, an hour). Rationale: It's easy to accidentally edit while logged out, and to leave a permanent trace of your IP on the public record. For example, if you create an interwiki link from wiki A to wiki B (with your login name), then on wiki B back to wiki A (forgetting to log in), it's trivial to work out that the IP on wiki B corresponds to the username on wiki A. And there's nothing you can do about it. Making it possible to reattribute these anonymous edits will/may/could ideally: - Help people who are particularly concerned about their IP being public - Reduce the disincentive to working outside one's home wiki
Just the same IP isn't reliable -- frequently multiple people will have direct access on the same IP due to proxying (for instance a whole office, school, or ISP). Likewise, some ISPs such as AOL have some ugly proxying systems which cause multiple edits in the same session to be passed off through multiple IPs. It might be more or less feasible, in theory, to authenticate the recently-made edits against an open session identifier, so as long as you didn't shut down your browser they could be confirmed as coming from the same place. There are issues with data disclosure and updating of records, caching, and external data feeds, though. It's probably a lot simpler to just make it hard to accidentally edit while logged in.
IIRC, re-assigning IP contributions to usernames used to be on demand but has been stopped AFAIK because of time consumption, since devs had to do it. However, it would be nice to have perhaps some kind of special page with two inputboxes - revisionid and username. This would be available for bureaucrats only (or stewards?). Anyaway, some kind of re-assigning mechanism independent on devs would be handy.
(In reply to comment #2) > Anyaway, some kind of re-assigning mechanism independent on devs would be > handy. Note that a general-purpose edit re-assigning extension was the focus of bug 2858.
*** Bug 21184 has been marked as a duplicate of this bug. ***