Thu, Apr 18
Wed, Apr 17
Thanks @Umherirrender, merged in as a duplicate.
Tue, Apr 16
Mon, Apr 15
Fri, Apr 12
A few small clarifications:
Thu, Apr 11
I don't have great ideas about this one. We could modify MenuSelectWidget.prototype.onDocumentKeyDown to use this.findFirstSelectableItem(); when nextItem is null for tab or down arrow when the input field is focused, but we'd also need to change OO.ui.SelectWidget.prototype.selectItem so that the item is considered highlightable, or find some other workaround. There is a TODO there asking // TODO: When should a non-highlightable element be selected?, maybe this is a good use case.
This bug is also noted in T220407: Unable to scroll notifications on iOS but not sure if those regressions were introduced at the same time.
But, it wasn't actually delivered, so there may still be an issue.
That's probably because of T215339: No jobs running on beta cluster
This is important to Growth-Team as well as we use the job queue in various places of MediaWiki-extensions-GrowthExperiments and can't QA some features at the moment. Is there an ETA for when this might be resolved?
Lowering priority, if it's still broken please change the priority again.
Should be fixed by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/EventBus/+/502875
@Shivanshbindal9 yes please do!
Wed, Apr 10
Tue, Apr 9
What I ended up doing here was setting the defaults to the values I need enabled for testing, which seems safe enough given that InitialiseSettings.php always sets the defaults for those particular feature flags to false.
Perhaps it would be reasonable to limit the max number of items rendered on Special:EditWatchlist, and point users to Special:EditWatchlist/raw for modifying larger watchlists. Although this bug report says timeouts happen on Special:EditWatchlist/raw, locally with a 2,470 item watchlist, the memory usage for that page is 8.77 MB while for Special:EditWatchlist it's 74.05 MB.
Mon, Apr 8
@nettrom_WMF and I decided to keep two separate schemas. I've made the change to record three different states for email module.
Updated schema per discussion with @nettrom_WMF https://meta.wikimedia.org/w/index.php?title=Schema%3AHomepageModule&type=revision&diff=18999329&oldid=18998619
Thanks a lot, sir for your review and sorry if I sounded a bit impatient but today is the last day to for submitting the proposal. I have made the changes that you suggested.
no problem, thanks for getting it submitted!
@Shivanshbindal9, this looks good! Some suggestions:
Yay, this works! Not sure what changed with the infrastructure, but today I was able to clear my 1,828 item watchlist on enwiki. @Pchelolo assigning to you to review and close.
Okay so I put this back In Progress so we can record the three different states of the email module.
@nettrom_WMF @MMiller_WMF I updated the schema https://meta.wikimedia.org/w/index.php?title=Schema:HomepageModule&oldid=18998619, could you please take a look and let me know if that is OK before I update the code?
Fri, Apr 5
I suggest we wait until T220239 is done (or block off time to work on that one) because it will help with fixing the problem here.
@Catrope and I might work on this at the hackathon, other collaborators welcome!
Similarly to my comment on T219432, doesn't the email module have three states? You can need to add your email, need to confirm your email, or be complete.
Doesn't the email module have three states? You can need to add your email, need to confirm your email, or be complete.
Yes, this could be a good one for the hackathon, but let's make sure to consider it alongside of T215911: Help panel: Manage help panel links on wiki