As Harumi's manager, I approve.
Sat, Nov 23
As Max's former manager, I endorse his access to these resources under and NDA.
Fri, Nov 22
My opinion is that non-org is fine. Thanks for tracking down all the details on this.
Thu, Nov 21
Fri, Nov 15
I had a very similar reaction to the data. I made this point when we first talking about this task. I think this is an initial pass at the data and probably gives us a sense of the upper bounds of what's possible but isn't actually realistic.
Thu, Nov 14
Wed, Nov 13
That works for me.
@dbarratt I see. That makes sense to not try to overload the API that way.
Nov 4 2019
Nov 1 2019
That works for me. It's about degrees of risk here. If we feel that prioritizing it as you've described is acceptable level of risk, then I think that's fine. There is no risk-free option except to completely remove the feature so managing the risk with clear eyes is the best approach to me.
@dom_walden is spot-on I think. The behavior he describes is definitely what we talked about but maybe it got mixed up somewhere.
Oct 31 2019
One way to output this data would be as a histogram with the average time per month and per wiki. It might be helpful if we see big shifts in the average time, maybe a policy or procedure changed on a given wiki. Or, even more interesting, maybe the tool changed somehow.
Oct 29 2019
@MaxSem Thanks for that. Turns out that it's not specifically just using EL but having whitelisted schemas whose data is kept for longer than the normal retention period. We do not have any of these special schemas.
Oct 28 2019
Thanks y'all for working to get this one right.
Oct 25 2019
@mforns Thanks for that info. It was very helpful.
Oct 24 2019
Is there a way for me to discover the schemas that this team has created? Our institutional memory is fuzzy. It'd be great if I had an authoritative source of the schemas we created which are still gathering data.
Oct 23 2019
@DannyS712 You've claimed this task so we've not been working on it further. Do you intend to come back to it? If so, we will wait but if you've moved on, we can jump in and finish up the work.
You will be reimbursed the $5 fee if you make an expense report.
Oct 22 2019
I can +2 the base patch.
Oct 21 2019
Oct 17 2019
This is very cool. Thanks for sharing @dom_walden!
@Samwilson Thanks for clarifying that. I'm glad you put the decay in there.
Oct 16 2019
@dom_walden Thanks for that detail. As for backoff, I was thinking that in other retry scenarios I've created, the delay between tries gets longer and longer the more times you try. This is in an effort to help the downstream system recover if it's under strain. I'm assuming we aren't doing that.
Four retries seems fine from my perspective. What's the interval? Does it degrade or backoff?
I wanted to share a general bit of guidance with regards to these "security" fixes. I think it would be helpful for us to think more in terms of defensive coding instead of secure or insecure or even more specifically whether we trust the source of the data or not.
Oct 11 2019
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.
Oct 9 2019
@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."
Oct 8 2019
Oct 7 2019
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.
Oct 3 2019
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.
Oct 1 2019
Who is the primary audience for these reports? Where do they end up?
Sep 30 2019
Moving back to Ready as we are changing the design in general.
Sep 19 2019
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.
Sep 17 2019
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