Aside from technical approaches, there have been mixed feelings on where the range contributions tool (T145912) should live, what features the first iteration should include, etc. I'm opening this ticket so we can have a dedicated discussion.
For this let's assume we want all requirements, bells and whistles, to be included in the initial release, even though this may not be true.
Arguments we have thus far regarding where it should live:
Special:RangeContributions
Pros
- Separates the advanced functionality (automated WHOIS, geolocation, range calculator, etc., e.g. T152114) from the basic functionality Special:Contribs offers. Users can essentially think of it as a standalone tool for power users, as they do now with XTools.
- We don't have to rework the Special:Contribs code, meaning we can get this out the door much faster. E.g. ContribsPager.php among others aren't built to group of results with headings like F5013937.
- We don't necessarily have to include this in core. As a separate extension we could (maybe?) finish this even faster, or at least release it as a proof of concept before considering merging it into Special:Contribs.
- We presumably can update the CIDR links in the block log to point to Special:RangeContribs. They currently link to Special:Contribs (example).
Cons
- Because of the nice advanced features, wikis might change all their templates and system messages to go to Special:RangeContribs instead of Special:Contribs, and hence new users might get thrown into it without any choice.
- Logically users would expect ranges to work at Special:Contribs, and not have to go to a separate special page. However, we might redirect to Special:RangeContribs if it is detected they entered a range.
Special:Contributions
Pros
- This is where users would expect ranges to work. Instead of typing in a single IP you type in a range.
- In its simplest form, it should not be that hard to allow querying of ranges and show them sorted by date, but we want to keep the advanced features in mind.
- Eliminates confusion of two Special pages that do the same thing for single IPs.
- We don't need to update any links across MediaWiki that link to ranges (like the block log).
Cons
- The advanced features will be too "in your face" for most users, such as the WHOIS, geolocation, range calculator, and list of subranges and individual IPs that are blocked within the requested range. We'd have to put all of this behind a preference, and we arguably have too many preferences as it is.
- Development costs. Having to rework ContribsPager, etc., to meet our needs could add months of work.
Thoughts?