I think we should discuss whether the feature this work would enable is worth the effort.
Fri, Jun 21
Thu, Jun 20
Thu, Jun 13
Tue, Jun 11
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.
Mon, Jun 10
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.
Mon, Jun 3
Tagging Cloud-VPS for help with review. If that's not the right project, please point me in the right direction.
Fri, May 31
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.
Wed, May 29
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?
We should start with Test. Once it has a feature flag and is fully deployed, enabling/disabling on any wiki is a trivial SWAT deploy of the config change.
Apr 17 2019
I can confirm Leon's experience. I'm looking at this now.
Apr 16 2019
@MaxSem I might be able to take a look at this one.
That sounds like a good move to me! Thanks.
Thanks for planning this out @Tchanders.
Thanks. Max did notice that the cron jobs on staging were not configured correctly. That could have contributed to some of the confusion around what was going on with this. I don't think we can consider it complete though.
Apr 15 2019
It could definitely be misleading. Maybe something like "No matching blocks found..." is even more exact?
Approved and merged. Didn't seem like this needed QA really.
Apr 12 2019
I vaguely remember us discussing this and recognizing it as a limitation of the tool which we weren't prepared to tackle yet.
It makes sense to me. Maybe we consider it fixed. If it comes back, we can reopen or have a new task.
Apr 11 2019
@Krinkle This patch should ensure that the coordinates are numeric, either positive or negative. The only change here, from production, is to allow negative coordinates. This modifies Ed's patch which came after your revert.
I've amended https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ImageMap/+/502888 to completely allow negative coordinates.
Apr 10 2019
Based on the patch and its commit message, I believe the author was following the same logic as is used for the coordinates in a circle or rectangle map. Whatever the spec, I think we can agree that negative coordinates aren't logical in the coordinate system used for polygonal image maps.
@Cirdan Do you have any examples? I'm looking at https://de.wikipedia.org/wiki/Baden-W%C3%BCrttemberg and https://de.wikipedia.org/wiki/Bayern and https://de.wikipedia.org/wiki/Berlin which seem fine.
Nice. It's a bummer we can't install it but I'm glad we didn't have to delve into a bunch of parsing issues.
Apr 9 2019
It sounds like there's not a lot of consensus with this pattern (correct my assumption here if I've misread the other conversations) so I think we should leave the name as it is.
@jmatazzoni Seems like was resolved for the time being.