Oct 17 2020
Oct 14 2020
Oct 7 2020
The team that owns the endpoint:
has tests for it running in the CI with every build
does not break existing functionalities by creating different versions of the endpoint instead of changing the existing one
Where does the QTE team help:
Having one dedicated person on the team OR helping the team with their test plan
Oct 6 2020
Oct 2 2020
These crashes are still occurring in 6.7.1, pulling into 6.7.2 for re-investigation
Sep 30 2020
Sep 28 2020
@Ladsgroup I was doing some CI experiments for iOS. I deleted the files stored by the actions and the repository itself, so we should be back under the quota as an org.
Sep 25 2020
Thanks @Pchelolo !
This is borderline unbreak-now from the apps teams perspective as it's breaking a key component of the apps (the explore feed) for German users. The specific endpoint the apps use that is timing out is https://de.wikipedia.org/api/rest_v1/feed/featured/2020/09/24 cc @Charlotte @JMinor
Sep 24 2020
Sep 22 2020
Sep 21 2020
Looks like the error string is page-protected-other
Sep 18 2020
Sep 17 2020
Reopening as it's still an issue in the iOS app. Will triage it through the iOS board for potential client-side workaround.
Sep 14 2020
@holger.knust this bug is separate from T256491. It looks like the root cause had to do with assumptions about the cache-control header as per this comment. Marking this as resolved as I can no longer repro with the steps in the description.
Sep 10 2020
@mpopov Thanks for checking the PR on a PR! Apologies if it felt mixed or unclear. The goal was to make the library easier for us to use and maintain going forward by replacing Objective-C structures and norms with their Swift equivalents. We stopped new development in Objective-C over two years ago, so it’s important that the library fits in with Swift norms. We’re willing to take the tradeoff of updating any legacy Objective-C logging code.
Sep 9 2020
I think we haven't yet talked in a more holistic way about how the instrumentation might be organized, structured, etc., and I think Joe's patch speaks more to that.
Correct, the patch is mostly about making the instrumentation side a bit easier to use & maintain long term.
Sep 8 2020
I'm unable to repro this on the latest iOS public beta - 14.0 (18A5369b) and Wikipedia app beta 6.7.0 (1753)
Aug 24 2020
It might be worth investigating the alternative to performBatchUpdates to see if it fixes this issue. There's a spike that uses that new implementation on the ModernCollectionViewUpdater branch
Aug 21 2020
@JMinor another option for this occurred to me - what if there was one string per-language Wikipedia in the language of that wiki? So for example, English Wikipedia would show "from English Wikipedia" no matter what the user's UX language preference. The localization language for this string would match the wiki language.
Aug 19 2020
@ABorbaWMF thanks for reporting. You can workaround the issue in the build you have by searching for language code. So for example, Mon shows up if you search for mnw. The bug will be fixed in the next build and the languages will be searchable by name.
@ABorbaWMF thanks for reporting this. It should be fixed in the next beta.
@ABorbaWMF nope, should be all set after general testing on our end. Core Data is a framework Apple provides that had a part deprecated that we were using. Thanks!
@Mholloway this task is resolved. The notes from @Robocel above are guidelines to use when adding styles going forward, and if there's any action item to this, it would be to add that to a readme. I'll put up a patch for that.
Aug 18 2020
We removed the unnecessary call to becomeFirstResponder() but it was ultimately fixed in newer iOS 14 betas.
Aug 17 2020
Would either need to update the layout code for the button and lower label or disable swipe actions on this cell
Aug 14 2020
shnwiki was added along with the changes for T239605
Agreed, a patch is up that adds all the missing languages and makes the process for adding new languages a lot easier.
A bit more than nqo was missing. Here's the full list:
Aug 11 2020
@bearND thanks for the thorough writeup! No questions at the moment.
Aug 6 2020
Aug 4 2020
Blocked by simulator-only bug that makes the app mostly unusable - articles take a very long time to load. More info in the PR description.
Aug 3 2020
Current active users (iOS/Android)
New users per month (iOS/Android)
Jul 29 2020
Jul 28 2020
Definitely worth doing if/when we revisit onboarding, but not worth keeping captured as a separate ticket
Unable to repro on 6.6.2, iPhone X
Jul 27 2020
So we are all on the same page this will *reduce* the number of pageviews, see plot. For 2020/07/24 data for IOS the reduction is about 8% on data marked now as 'user'
Confirmed, that's expected given that we're now excluding requests to save for offline viewing and requests from versions older than 6.6.2.
Jul 22 2020
Recreating it is an option. It'd probably be easier to recreate than downloading to a laptop and attempting to restore.
Hi @Andrew, 1 wouldn't be a problem. For 2 would the data be restored or would I need to recreate it from scratch?