I think it's fine in this case if our first go at this is focused on the existing EN-wiki only scope. It's not ideal and certainly not what we'd do if we had the chance to start from scratch. However, given the scope of a Wishlist item, I think holding to that for this work is acceptable.
Thu, Aug 15
I like the redirect to a PHP page with translations. Simple, incremental, and easy to change later should we want to do something fancier because we want more of a NoJS experience.
I'll say that in my beginning work on this, I found the original link target very confusing and did accidentally click on it a few times. So, my experience was the opposite of yours.
There's a PR here which is sort of a WIP. https://github.com/wikimedia/InteractionTimeline/pull/108
This has been around for quite a while. What's the barrier to review? What's the risk in just moving forward with it as is?
Wed, Aug 14
Just to get the ball rolling: https://github.com/wikimedia/InteractionTimeline/pull/105
Thu, Aug 1
@Niharika Given @JMinor's comment above, I think we should escalate the priority of this. Additionally, maybe we should make it the final focus of our Block work for now. Once we deliver this, we can pick up some other work and possibly come back to the remaining Block effort?
Wed, Jul 31
Tagging @ifried to get her feedback.
Jul 19 2019
I think that's probably true, however, we are more likely trying to stop the drive-by vandal than a serious coordinated attack. If we could reduce by 10% the amount of inappropriate images admins had to deal with, we'd be saving hundreds of hours of people's time.
Jul 18 2019
Just in case manager approval is needed. I approve this access for Dom.
Jul 16 2019
That might be interesting information to share with Cloud-Services.
Jul 15 2019
This was my bad. I saw that 185 was merged. Thanks for clearing it up.
Jul 11 2019
This is a good collection of ideas.
Jul 10 2019
It's the GROUP BY that causes the query plan to do a filesort which is the problem as the optimizer tool tells us. I think the COUNT(*) AS revisions makes this use a temporary column and the GROUP BY is on that column. As far as I know, an index can't help that problem though the query is making use of the rev_page index apparently.
Jul 9 2019
We need to make sure the indexes for this are setup correctly so we can filter with WHERE by the expiration timestamp.
Thanks @Marostegui for the detail.
Jun 28 2019
@Samwilson I'm OK with repurposing it as it'll keep all the context in one place.
Jun 25 2019
I think we should discuss whether the feature this work would enable is worth the effort.
Jun 21 2019
Jun 20 2019
Jun 13 2019
Jun 11 2019
Let's make the first step of this work to setup a cron on production to restart the service once (maybe twice) a day. That should be done soon to get rid of the user impact. Then, we can do the effort to fix this.
Jun 10 2019
The approach @MaxSem outlines above seems to boil down to our trying to cause the least amount of impact on other services. I agree that having a separate watchlist_expiry makes the most sense. That allows us to have a cron which cleans the watchlist table on some schedule. All the rest of the code could remain the same. I agree with Max that we could by convention say that the expiration is "best effort" and that it might be an hour or two off. That depends on how often we think we could have the cron run.
Jun 3 2019
Tagging Cloud-VPS for help with review. If that's not the right project, please point me in the right direction.
May 31 2019
I think I understand what @dbarratt means about not using verbs in the text that the user clicks to get to the preferences. That seems right to me.
May 29 2019
In our standup yesterday, we discussed this. @Niharika made it clear that she would prefer to have the checkboxes. I'll let her provide her reasoning if she wishes.
May 24 2019
I wonder if @MaxSem might be able to give us some of the context for why it was built that way?
May 23 2019
@Barkeep49 Thanks. My comment was a summation of a discussion we had within the team earlier today. I'm glad to read that we likely understood the request well enough.
I'm summarizing what I understand the request here. Please correct if I've missed something.
As an Engineering Manager I need to be able to admin projects for Community Tech to help manage our sprint boards.
May 22 2019
Sounds like we are in a good spot then. I'm comfortable with it falling over at 30 concurrent requests...for now.
Try using the debounce method in OOUI. If that doesn't fix it, we should document our findings here and abandoning it.
May 14 2019
Apr 25 2019
Thanks @MaxSem. I suspect, maybe when Sam gets back, that we can sync up the code across them with the fixes you've made already.
This could mean that users potentially aren't receiving the headers for their requests in the right way. We don't know what that means for the user experience.
Based on what @MaxSem says above, it sounds like we want to filter to certain kind of meaningful exceptions. That likely means we'll need to filter out some non-error/crash type exceptions.
@MaxSem Are we pushing changes like this and the other recent ones out to staging and production or just production?
I'd rather we not spend efforts on this and focus on getting the extension built. Then we can iterate on the testing there with the CSS that's been tested via the method that's already available.
Apr 24 2019
Apr 23 2019
I tested this and no longer receive the error. I'm approving the review in Github.
Apr 19 2019
I tested this and it works quite nicely. Moving to Done.
I did a rudimentary test on this and it seems to work fine.
I took a look at the new tasks that Max created and it looks like a good start to dig through the first layer of issues with the service.
Apr 18 2019
This is now invalid. The result of the "invert" isn't high enough fidelity for what we want. We should strive towards something more like what the mobile app does. Maybe we can learn from their code?