Fri, Oct 11
I spoke to a friend who still works in this area and they said that spam detection and management is in freefall at Yahoo/AOL right now. They are rapidly defunding that part of the business and many automated operations are happening with little human oversight.
Wed, Oct 9
@ifried That's fine. I wanted to scope the responses you're expecting.
Do any of these considerations change or have unique limitations in the mobile context?
The PR is merged but it appears to me like this might be one of the things that the Mozilla folks were concerned about. The documentation even says, "Accepts raw HTML."
Tue, Oct 8
Mon, Oct 7
I guess I was thinking about a template library and not string literals. I misspoke.
Oof. I think we knew this was a risk, right? Looks like we need to do sanitization or go toward some ES6 template sort of thing like @MusikAnimal was proposing at some point.
I've +2ed this patch.
Pages with the Most Revisions is the report that fails on occasion. We will leave it in because it does work sometimes and some people get value.
Thu, Oct 3
Thanks, y'all. Having that priority will help us know when to raise potential effort/sizing issues about the could haves.
I don't know of anything concrete about what might change with the Desktop Refresh. I think we should proceed with the current state and just understand that it may need to adjust in the future.
This seems like a nice feature.
Tue, Oct 1
Who is the primary audience for these reports? Where do they end up?
Mon, Sep 30
Moving back to Ready as we are changing the design in general.
Thu, Sep 19
The limit is 10 pages.
Thanks @nettrom_WMF. We will take a look. I don't know if we have this off the top of my head.
Tue, Sep 17
Works correctly for me as well. Chrome 77 on Mac.
Sep 12 2019
Thanks @Samwilson! That's very helpful.
Sep 11 2019
@WDoranWMF It's not actually sure that we will take on this work. We wrote this task so that "someone" in the future could do this work. The decoupling initiative seemed a good candidate. We wrote it because we are knee deep in the code at the moment.
Yes. Once we've created the tasks needed to do the work the spike recommends, we can close the spike task.
Sep 10 2019
@Samwilson What's the status of this task? It's in Needs Review but it's not clear to me what the outcome/recommendation is.
@sbassett Thanks for your help here. While there was some back and forth, I had a really productive meeting with @JBennett yesterday about your team's plans for Phab task tagging. I'm excited about the clarity and flexibility that might come out of it.
Sep 9 2019
I would agree with Leon here. Simplicity seems a smart tactic. Personally, I'd always show the loading indicator even if it disappears as soon as it's there. In my opinion, that's bomb-proof for those requests that might take a long time and much simpler than trying to guess how long something is going to take.
Just a note: Max and I were talking about this a few days ago and how it might impact the API. It appears all of the code from the API and the UI ends up in the same class/function so the changes here shouldn't be difficult to apply to both scenarios.
Sep 6 2019
An appropriate result out of any 8 hour spike could be, "There's enough work just to figure out the problem that I couldn't finish it in 8 hours." That's some data that's interesting also.
Sep 3 2019
Aug 30 2019
I approve this as the manager for @Tchanders.
Aug 27 2019
I'm not sure if this was clear but when talking to @MaxSem, he told me that he has been unable to reproduce this error. That's one reason why we are pursuing other ways to get more information and/or work around it in the short term.
@Reedy AHT were working on this on behalf of the Security team. They'd be better to talk to about this than us as they understood the implications of making this change when they asked us to do it.
Aug 22 2019
This will be solved by other tasks moving some function calls around.
Aug 21 2019
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.
Aug 15 2019
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.
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?
Aug 14 2019
Just to get the ball rolling: https://github.com/wikimedia/InteractionTimeline/pull/105
Aug 1 2019
@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?
Jul 31 2019
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.