As a WISE team, we wanted to explain what happens after an issue is reported in WISE—from the moment you notice a problem to when it is fixed and released. Our goal is to be transparent, reduce uncertainty, and help you understand how decisions are made behind the scenes.
Step 1: Reporting an Issue
When something isn’t working as expected in WISE, the issue is reported to the Global Service Department (GSD). GSD serves as the front line for receiving issues from the field.
The S&I Support Team then reviews the report. If the issue is confirmed, they create a formal bug ticket. Creating a ticket ensures the issue is documented, tracked, and visible to the WISE product team—even if it can’tbe fixed right away.
Step 2: Review by the WISE Product Team
The WISE product team meets twice each week to review new bug tickets. During these meetings, the team carefully reviews each issue to:
- Confirm the issue is real and reproducible
- Understand who is impacted and how often
- Clarify any missing details or edge cases
This review step is important because it ensures decisions are based on accurate, shared understanding—not assumptions. If you report an issue and receive questions about what you are seeing in WISE, it is because the team wants to make sure the issue is fully documented for everyone from the Support Team to developers to understand and use.
Step 3: Prioritizing Issues by Impact
Once an issue is validated, it is evaluated based on its impact. Rather than focusing on how new or loud an issue is, we consider how much it affects users and their ability to administer S&I classes around the world.
Factors include:
- How many users are affected
- Whether the issue blocks critical work
- Whether a reasonable workaround exists
- Risks to things like attendance, transcripts, messaging, or reporting
Higher-impact issues are prioritized to be worked on sooner. Lower-impact issues are placed in a queue and revisited as capacity allows. Being in the queue does not mean an issue is ignored—it means we are intentionally focusing on the most impactful problems first.
It is rare but sometimes happens that an issue is so urgent that we must pause work on all projects to immediately resolve a bug. This only happens in the event of a major outage or issue that impacts both WISE users and students. These issues are typically resolved within a few hours of being reported.
To see a current list of known issues and priorities, please see this Help Center article (hyperlink to article above).
Step 4: Prioritizing Work Using Sprints
All WISE work is planned in two-week blocks called sprints. There are 26 sprints in a year.
Before each sprint begins, the product team decides what work will be done during that two-week period. This includes both bug fixes and planned improvements.
Once a sprint starts, the planned work usually does not change. This allows the team to focus deeply and deliver high-quality results without constant context switching.
Step 5: Balancing Bug Fixes and Improvements
Every sprint includes a mix of work. Some of that work fixes bugs you may have encountered. Other work improves existing features, adds new features, or strengthens reliability behind the scenes.
Each sprint is a balance. The exact mix depends on business needs, approved funding, user feedback, the severity of current issues, and how many developers are available. Some important work isn’t immediately visible in WISE but helps prevent problems and improve stability over time.
The WISE team consists of one full-time product manager, an intern, and typically one full-time developer.
In addition, there are other team members whose time is partially dedicated to WISE, but is also shared across multiple products including mySeminary, myInstitute, PDM, WAT, and other products. These team members include a quality assurance engineer, solution architect, functional analyst, database engineer, and project manager.
Step 6: Releases and Scheduled Maintenance
Each sprint includes two releases: one midway through the sprint and one at the end. A release is when completed work is published into WISE.
During a release, you will see a Scheduled Maintenance message. Releases typically take 15–30 minutes. This is when fixes and improvements become available to everyone.
Why Some Fixes Take Time
We understand it can be frustrating to see an issue reported but not fixed right away. Some fixes take more time because:
- They affect a smaller group of users
- They require careful investigation to avoid unintended impact
- Higher-impact issues must be addressed first
- The current sprint is already fully planned
All validated issues remain tracked, even when they are not actively being worked on.
Our Commitment to Transparency
We regularly share updates through our Known Issues & Updates article, which highlights what we are actively working on, what is queued, and what has been resolved. We are striving to be transparent about what we’reworking on and how it benefits you.
Your feedback directly influences how priorities are set and how WISE continues to improve. Thank you for your patience and for helping us make WISE better for everyone!
| If this article needs some maintenance, or you would like to provide feedback on this article, please send an email to SI-ArticleFeedback@ChurchofJesusChrist.org with the article's name and what can be improved. |
|
If this Article did not answer your question, please get in touch with the Global Services Department for further assistance -
|
| Feel free to check out our S&I Community page, where you can engage with your peers to find answers to questions! |