Sarai-WMDE added a comment.
Posting a progress update on the design exploration. Att @Arian_Bozorg and @Lydia_Pintscher TL;DR: We need help validating whether the risk of overloading the WQS erver due to the implementation of the Run/Stop toggle solution is a serious one. We also need to agree on a strategy: should we preventively modify the design solution further (making it slightly less streamlined), or go ahead and act in case we notice a risky increase on the volume of queries? In the last two weeks, we approached the Wikidata community to test the Run/Stop toggle button solution described above. We used a survey to collect feedback from volunteers on two main areas: 1. Their understanding of the solution: Here the data collected was overwhelmingly positive. The great majority of users interpreted the behavior exactly as intended, and didn't find anything about the proposal confusing. 2. Potential risks, concerns and improvements they would suggest in order to adjust the feature to their needs: When it comes to their concerns, there were some clear patterns. The most frequently mentioned issue was the **risk of overloading the WQS server**, due to the facilitation of running multiple heavy queries in parallel, accidental double clicks, and active vandalism (DDoS attacks). As potential solutions, users brought up strategies like avoiding making the "Stop query" functionality available for bots, or actually stopping the query on the server side (which I'm aware is not feasible). They also mentioned some redesign suggestions that we're integrating in the next iteration (whenever suitable), and made very interesting comments regarding the lack of visibility of the server's status (users don't get an estimation of the query execution time, nor know when it's struggling – I believe there's a very interesting improvement opportunity here). Our first inclination to address the server overload concern was to come up with a different design alternative, one that provides a "rerun" option only when the query is modified. We are currently testing this new solution in a follow-up survey (distributed via different channels to avoid any spamming). Nevertheless, we are aware that this alternative is a less optimal solution in terms of discoverability and accessibility, so we are less confident it'll do better during the tests. Now, the more technical question that we need help validating is: In general, an increase in the volume of queries can be expected as a result of these changes. But, how serious should we take this overload concern? Should we put strategies in place to prevent any overloads at this point (e.g. create a bit more friction at the design level), or can we wait to track performance and see if we need to correct our solution later? TASK DETAIL https://phabricator.wikimedia.org/T245643 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Sarai-WMDE Cc: Michael, Ainali, Lydia_Pintscher, jhsoby, agray, Nikki, Sarai-WMDE, Arian_Bozorg, edwardbetts, Aklapper, Bugreporter, Danny_Benjafield_WMDE, Astuthiodit_1, AWesterinen, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Mahir256, QZanden, EBjune, KimKelting, merbst, LawExplorer, Salgo60, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331
_______________________________________________ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
