Today (October 7, 2016), I had a meeting with PD to discuss some of the ongoing concern about the CU process. Thank you again to Marissa Dimino for recognizing the need. The folks from PD have indicated that they're looking to be more responsive to community feedback.
I'm reasonably satisfied with their responses. I've listed the information below in my own words, so any Blackboard employees should definitely jump in if I've gotten something wrong.
Without the possibility of a rollback, how do PD and Support plan to respond if a bug is causing major issues for our institution? How do they expect customers to respond?
This was the main focus of our discussion. PD acknowledged that their communication up to this point should have been better and they're going to work on that.
Critical fixes will never be postponed until the next CU. If a major component is affected for a significant number of users, the fix will be prioritized and released as soon as it's ready. How it's deployed (B2 update vs. CU install) will depend on the specific issue. As for smaller bugs...obviously, the reality of the situation is that no application as complex as Blackboard is ever going to be bug-free, and the resources available for fixing them are finite. When twenty institutions have twenty different small bugs they want fixed, a judgment call has to be made. As I understand it, bugs not considered "critical" are prioritized based largely on three criteria (in no specific order):
- How cumbersome is the bug? Bugs that seriously hinder someone's ability to use the feature will be higher on the list than bugs that are merely an annoyance.
- Is there a workaround? Even if the workaround is mildly inconvenient, they're going to be more inclined to prioritize bugs where an alternative solution doesn't exist.
- How big is the bugged feature? Any part of the application that's used more often than others (think Announcements compared to Portfolios) is likely going to be handled first.
Clarification from Jim Chalex:
Also, regarding critical fixes, we will make these available in CUs, or when possible, B2 updates, as quickly as possible. I think the main point is that we would not arbitrarily "hold back" a critical fix simply to follow a CU schedule, thus delaying its availability. Having said this, and as you say, we make these judgments on a case-by-case basis and with our clients in mind.
I specifically mentioned the recent Spell Checker bug (where the HTML grew out of control with every edit) as an example of a large issue that took too long to fix. PD explained that this particular bug was unique in how it had to be handled -- essentially a fix for a fix for a fix for a fix for a fix. In other words, that's going to be the exception as opposed to the rule. It was also emphasized that there's always a certain amount of negotiation when it comes to patches. If you feel like your request for a patch was denied without a good reason, definitely say something and explain your situation. You may not get the answer you want, but those requests are definitely examined.
To their credit, Blackboard's QA has improved significantly in the past year or so. I still wouldn't say I'm entirely comfortable with an irreversible update, but at least they're headed in the right direction, and we know that they consider all options when dealing with patch requests.
Is this new process an indication that support for Managed Hosting and self-hosted clients is stopping (in favor of pushing people to SaaS)?
Absolutely not. The new CU process was adopted at least partially to increase their limited ability to fix bugs in the first place. Many of the bugs have actually long since been fixed in future versions of the product, but the limitations of the bbpatch utility kept these changes from being backported.
On that note, will the switch to SaaS ever become mandatory?
At the very least, not anytime in the near future. SaaS is still fairly new, and they're still exploring how it can be best developed and supported. Response times for SaaS clients can vary because access to the backend of SaaS environments is heavily restricted. This is done for operational security and, more importantly, to prevent "spaghetti code," which is how a lot of these bugs come about. It was freely admitted that SaaS isn't ready for full-scale adoption yet, as they have to work out these process issues. They're also working to reduce the amount of time needed for migration.
Clarification from Jim Chalex:
Regarding SaaS and full-scale adoption, I would put it a bit differently. SaaS is a relatively new deployment method for Learn, and as with anything new, there will be some things to work out, like getting our processes just right. At the same time, it's important to emphasize that it is available for adoption today, we have clients using it now, and others planning to migrate to it soon. It's also important to underscore that we have no plans to discontinue our self- and managed-hosted deployment methods.