Fri, May 20
For more clarity, at the point of withdrawal from the process, this ticket was at the stage where Search was unblocked from moving forward. We have a RACI card filled out based on feedback, which we still intend to use to communicate our plans as we move forward. There were multiple upcoming phases of shopping ideas around for feedback, but I was told that this feedback would not be binding or a blocker to continue our work, but as additional points of perspective to consider.
Given that this is a minor component that was holding up our larger Elasticsearch version upgrade, I expressed concern that these additional stages were creating busy work that put our timelines at risk. Based on the size and impact of removing API Feature Usage's dependency on Elasticsearch, I was given the go ahead to move forward with this work without moving through the final steps of the Tech Decision process, which were understood to be more of a formality at this stage.
Thu, May 19
@cchen , looks like maybe the gobar_search numbers for ptwiki and ruwiki are off
Sorry for all the confusion. This process is new to me, and I don't yet fully understand how it works and what communication practices/norms are.
The ticket was declined because @SWakiyama cleared my team to move forward with this work without pushing it through the rest of the Tech Decision process.
I was under the understanding that this unblocked this work for the search team.
@Reedy , is there a reason this ticket was declined?
Mon, May 9
It seems like this is a nice to have since the user could still type more of the language name out in order to either complete it by only typing, or enough that the number or suggestions is small enough to select from (i.e. by the time I type Englis, the language suggestion is probably pretty high)?
Do you happen to have data on how often people use the suggestions? or might use it if it works well?
Updated ticket to reflect that this is about the order of autocomplete suggestions, and not (full text) search results (these are two different processes on the backend -- yes, this is a little confusing and should probably be addressed elsewhere)
Wed, May 4
Mon, May 2
For extra context, the reason for this behavior is that trying to merge and filter such a high volume of results on each shard of our search cluster could crush our servers and bring down our search services.
Based on last week's check in meeting, I think Erik's comment is a sufficient answer and we can close this ticket
Fri, Apr 29
Wed, Apr 27
Thanks @cchen ! This is great.
I don't think for performance reasons we can/want to run any kind of full text search in the go bar, so this will likely be a declined task, or low priority one, unless there are other solutions I'm not thinking of.
@TJones can correct me if/where I'm wrong.
Tue, Apr 26
cc: @cchen , in case you have some additional insight into what search instrumentation/metrics are currently available
Fri, Apr 22
@DD063520 , thanks for asking. Please refer to the attached paper for more details on the criteria we used to decide on our shortlist, which includes a note on Oxigraph: https://upload.wikimedia.org/wikipedia/commons/e/ea/WDQS_Backend_Alternatives_working_paper.pdf
I'm closing this task since Halyard is not on the shortlist of Blazegraph alternatives, as per https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_backend_update/WDQS_backend_alternatives
I'm closing this task since Oxigraph is not on the shortlist of Blazegraph alternatives, as per https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_backend_update/WDQS_backend_alternatives
I'm closing this task, as Rya is not a shortlist candidate to replace Blazegraph, based on https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_backend_update/WDQS_backend_alternatives
Apr 20 2022
Apr 19 2022
Apr 18 2022
Also, if you select the option to "Search for pages containing 22.214.171.124", you'll get the expected search results page. It seems like at some point, somebody added a feature to quickly search for contributions based on IP
Interesting: also not my expected behavior. But it looks like according to the help page, this is actually expected behavior (not a bug): https://en.wikipedia.org/wiki/Help:User_contributions#Accessing
Apr 12 2022
Thanks for the clarification. With regard to orphaned nodes throwing off query results, there should be ways to write SPARQL queries in such a way that they ignore these nodes.