https://bugzilla.wikimedia.org/show_bug.cgi?id=38403
Dan Garry <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |WONTFIX --- Comment #20 from Dan Garry <[email protected]> --- (In reply to Jan Ainali from comment #16) > Here is another use case one user came up with during a discussion. You > search for a term and you want to fix something in all these articles. By > being able to sort it by last modified, all the ones you just fixed will go > to the end of the list and it is to see what is left to do. Implementing search sorting for this use case is implementing a solution to a problem that does not exist. In CirrusSearch, the search index is updated within seconds of changes to articles, so any articles you've fixed will be removed from the search results if you were to rerun the query. (In reply to Jan Ainali from comment #18) > Your assumption here is that there is only one hit that might be interesting > for the user. For many editors, lists of articles that are starting points > for their editing behavior make perfect sense. Sure, editors are a very > small number of users compared to readers. That is why sorting should be a > secondary action, after the first results have been shown. I make the assumption that being the user expects to be presented with results relevant to the query that is typed in. If you are not expecting that, then you should not be trying to change the intended function of the search engine, you should be using some other tool (like database dumps). I'm genuinely sorry if that's harder and more inconvenient for you, because I do not like making things inconvenient for people, but that does not change my stance about the product that is search. (In reply to Jan Ainali from comment #16) > I am sorry, but you have not stated any reasons at all. In what way will > this degrade performance for users? My wish is that the search is presented > as it is today, with the option to sort it *after* the first results has > been showed. So for users not wanting to sort it, there will be no > difference at all. I've already outlined that sorting by date will, for the vast majority of users, generate meaningless results. Putting it behind a button and expecting people not to press that button does not make that okay. Just to be clear, you reopening the bug does not change our work priorities, or change that any patch which attempts to implement this functionality will be met with a -2 by the engineers that work on the extension. It just leaves the bug in a status that does represent our ongoing priorities, which is confusing and nothing more. I will close the bug once more to rectify that confusion, but after that any I'll just leave it because I don't want to spend my time in a bug status revert war. Any ramifications for the incorrect status of the bug will be your responsibility. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
