@kostajh -- how different do those thresholds look, just eyeballing the numbers? If this can be an easy background task to fix them, then I think worth it, but if it will take a lot of person time, then not.

@kostajh -- thanks for putting in extra time to work on this. The prototypes look good to me. I created T245368: Newcomer tasks: evaluate new ORES topic models so that the ambassadors can get started with evaluating the models.

@Dyolf77_WMF @Urbanecm @PPham @revi -- this task is ready for you. Because there are two versions of the model, and each has 64 topics, this may take a long time. Please speak up if you are concerned about how much time this will take. We would like to have these results by the end of the week.

@revi @PPham @Dyolf77_WMF @Urbanecm -- this task is ready for you. I know this may be confusing, so please let me know if you have any questions.

@Tgr -- I think they look fine. Thanks.

Hi! I just want to post here and say that since I've been using Turnilo, I definitely want this data to be updated more frequently -- even weekly would be a great improvement. My use case is that I check Turnilo to see how many suggested edits (based on edit tags) are being done in our target wikis.

@kostajh -- it is okay for the cross-walk version to have fewer articles. It's just that there have to be enough for the ambassadors to evaluate, like we're thinking at least 20 in each topic, simulating the articles that the actual module would be choosing, so that we get a good sense of the quality of topics that users will experience. The native mode should not be set up to show articles that exist in the cross-walk, because we're not going to be comparing the results article-by-article; we're going to be comparing it topic-by-topic. We want to look at how these models will perform, as closely as we can simulating the results they would be getting in production.

I am moving this to the Growth Team's "Upcoming Work" column so that it can be among the next bugs we address that are outside our normal feature development stream.

Given that it doesn't sound like this is needed. I'm declining the task. Please let us know if this changes!

Thanks, @RHo -- I am resolving this task and putting your comments on the UX task for the ORES topics: T244421: Newcomer tasks: UX changes for ORES topics

Thank you! I totally use this.

Thank you!

I will check this out in production once it's deployed.

Thank you!

@Etonkovidova -- should this still be in your column? Or are there next steps that someone should take?

@ppelberg -- FYI here is an experience that @Dyolf77_WMF found confusing in mobile VE. Please feel free to close this task if the behavior is intentional with no intention to make changes.

@Tgr -- yes, the taxonomy and mapping will be the same across all wikis.

@kostajh -- sounds good, we can do the one-off solution when we have a moment in the coming couple weeks.

@Etonkovidova -- since this is covered in T224883, do you think that this task should be merged into that one? If so, could you please merge?

Thanks for the questions, @kostajh.

@ppelberg -- here is a use cases for replying that comes from our Czech community members. They get mentorship questions on their talk pages from the newcomer homepage's mentorship module, and the two issues are:

Now that @RHo has created the interactive prototype that I've put in the task description, this is Ready for Development.

Now that we have the new ontology mapping and are setting score thresholds via T244192, this is Ready for Development.

Thank you! The Growth team has discussed the results and made decisions on the final designs, which are reflected in other Phabricator tasks.

@Tgr -- if we don't implement alphabetical sorting, what will the sorting be governed by?

Hi @Piramidion -- thanks for trying the features out and thinking about them. The reason we ended up including those timestamps is that it is relatively common for newcomers to ask multiple separate questions close together. Without something like a timestamp in the header, those multiple questions from the same user would have identical headers, which makes it hard to distinguish them in the table of contents and in a watchlist. Does that make sense? Given that issue, what do you recommend?

@kostajh -- thanks. I made the sheet public.

@Stryn @Seraphimblade @Izno -- we really appreciate the effort you've put into helping us try debug this issue. We're frustrated and disappointed that it doesn't look like there's much we can do on our end to fix it, especially given the importance of the work you're doing with notifications from mobile. After putting a lot of time into this, at this point, it looks like the Growth team has to move on to other work and other bugs. Does this sound okay to you?

@kostajh @RHo -- I am going to resolve this task, and put these points in T244421: Newcomer tasks: UX changes for ORES topics, because that work will adjust this topic filter dialog again.

@RHo -- could you please also comment on how this overlay should work? Like should the messaging at the top scroll away? Or should it stay stationary as the user scrolls the topics below it? Also, right now, when the user clicks "show more", it changes the size of the overlay to accommodate. Should the overlay size not change once we have these ORES topics?