The problem with this is how to encourage anyone to vote on it. In my institute, I was told that getting my colleagues in my univ. to vote on it may not help as Instructure could disregard them as a cluster of correlated votes, so local advocacy does not help. Then I saw the fate of a *really* popular idea (and obvious design omission) being archived, so popular and distributed does not guarentee anything proceeeds to the next step either.
So, I'm wondering how to take this further. Adding yet another feature request may help, but we are then starting to make the case to fix the problem all over again, and will have the same discussion in three months from now.
I'm probably just missing an obvious step in Instructure's logic, it would really help to avoid wasting more time if Instructure could help out here:
- we need GB history (its implemented, this implicitly recognises it adds value to GB)
- above a certain threshold, GB history stops working at all
- did the requirement for this functionality go away above a certain threshold?
- If "yes", please explain why the need disappeared, not obvious to the end user here
- if "no", then it's a documented bug design oversight change in user requirements during implementation :smileyshocked: and should be fixed.
Inviting institutes to go away and implement it for themselves based on the API is not really the way to go, a lot of duplicated effort, clearly a bad idea.
I can appreciate that there may be performance limitations resulting from the way GB is implemented but that should not affect the specified requirement of the design.
On the bright side, at least this behavior is only in Canvas - imagine if your car (brakes) behaved like this, work fine up to some limit, then stop working above a certain speed...
This discussion post is outdated and has been archived. Please use the Community question forums and official documentation for the most current and accurate information.