You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Both numbers should be equal. Or at least relatively close. After all, caching the data and being out of date from a few hours or days would be entirely acceptable for any of our purpose. Being months old, I suspect it's not the expected behavior
If a user action is required to update the cache, I'd consider making sure it can be easily found it from either the source code or the link at the end of the image. Neither seems to hold.
Also, I'd expect the indentation to be the same for every contributors. But the first one is more indented for some reason. But this one is far less important as an issue
Screenshots
From github:
From your image:
Prefix of the source code of your image:
Desktop (please complete the following information):
OS: Ubuntu
Browser Chrome
Version: 103.0.5060.53 (Official Build) (64-bit)
Additional context
I have wondered whether you only considered people who contributed to the open collective, but I doubted it, because I see we have 2543 donors (I honestly have a hard time believing it, even if it's only .1% of our user base. Thanks for allowing it). However, I saw at the start of the images some really active past contributors who have not been present with us for years and I doubt they interacted with the open Collective
P1 high frequency, high impact
P2 low frequency, high impact
P3 high frequency, low impact
P4 low frequency, low impact
Examples of high impact - a problem affects users during an essential process (expenses and payments > onboarding and registration > contributing) with no workaround.
High frequency - >10% of users affected (measured as a proportion of total potential users for this case).
The text was updated successfully, but these errors were encountered:
It's likely that the Redis cache was stuck due to an old version of the codebase from a year ago. I just flushed the cache for ankidroid. It should be better, maybe only in a few hours due to others layers of cache on the CDN side.
Thank you. Appreciated.
Out of curiosity, did you just flush out for our project? Since it's usually not something checked very often, I could have imagined that other team have the same problems and may have missed it. So I'd humbly suggest checking whether other cache has not been updated since this old version of the codebase (admittedly, I assume some teams may have not been updated because they became inactive, I've no idea how to arrange that.)
By the way, thanks for letting us pull this image from your server. It's nice to have on our github thank's note
Describe the bug
The
contributors.svg
image don't get updatedTo Reproduce
Steps to reproduce the behavior:
Expected behavior
Both numbers should be equal. Or at least relatively close. After all, caching the data and being out of date from a few hours or days would be entirely acceptable for any of our purpose. Being months old, I suspect it's not the expected behavior
If a user action is required to update the cache, I'd consider making sure it can be easily found it from either the source code or the link at the end of the image. Neither seems to hold.
Also, I'd expect the indentation to be the same for every contributors. But the first one is more indented for some reason. But this one is far less important as an issue
Screenshots
From github:
From your image:
Prefix of the source code of your image:
Desktop (please complete the following information):
Additional context
I have wondered whether you only considered people who contributed to the open collective, but I doubted it, because I see we have 2543 donors (I honestly have a hard time believing it, even if it's only .1% of our user base. Thanks for allowing it). However, I saw at the start of the images some really active past contributors who have not been present with us for years and I doubt they interacted with the open Collective
Triage Template (core team only)
This template is for members of the team to triage for prioritisation. For more guidance see https://www.loom.com/share/369ab467fbc64dec848085d38ff57ca0:
P1 high frequency, high impact
P2 low frequency, high impact
P3 high frequency, low impact
P4 low frequency, low impact
Examples of high impact - a problem affects users during an essential process (expenses and payments > onboarding and registration > contributing) with no workaround.
High frequency - >10% of users affected (measured as a proportion of total potential users for this case).
The text was updated successfully, but these errors were encountered: