Submitting change suggestions for Church tools

[greenwoodkl]

From the outside of the black box that is Church IT it sure seems like an inefficient game of Telephone to wait for "enough" reports of technical problems to bubble or trickle up through layers of possibly non-technical leaders to coordinating councils and hope the messages aren't lost or distorted along their journey.

We can submit FIR tickets for facilities issues through an app and a standard interface, but not issues for digital tools? Are the feedback links on the website a useful communication method to submit bugs and feature requests, or do those also languish without first having a matching verbal message bubbling up to coordinating councils first?

If sending messages up the chain is the only acceptable method, it seems that providing some standardization to the reporting process, possibly standard submission of logs, screenshots, and standard questions would bring some order to the chaos? If I could submit a ticket online that could then be reviewed and approved by my bishop and then escalated up the chain, then I don't have to rely on trying to communicate the technical nuances verbally. Or I suppose I could draft my own email and start sending feedback that way.

[scgallafent]

There are two different things going on here that need to be treated differently: (1) submitting feature requests and (2) submitting problem reports.

I'll tackle the easy one first. Right now, unless the project has a project-specific method for submitting a problem report, the best solution for technical issues is to submit problem reports using the feedback links on the web site. It's not ideal, but it is what exists. That feedback makes it way to a team that will then work on getting it to the right place.

IF it is a clerk-related tool and you are in that capacity and it is blocking the work, the Global Service Center is another option. A clerk calling the GSC because they are unable to activate recommends is appropriate. Anyone (clerk or not) calling the GSC to complain that their young men leaders don't currently have access to quorum lists is not appropriate and could quickly overwhelm a finite resource.

Some projects have established direct feedback channels. For example, Member Tools has a feedback function that sends an email to the Member Tools team. That feedback is reviewed by a church service missionary that works directly with that team. If it is a technical issue (something is broken), that becomes a bug report and the team can act on it. Feature requests don't go to the development team. They will be routed to project management.

That kind of interface doesn't exist for every project. In some cases, the volume of feedback would overwhelm the development team and they wouldn't have any option except to just ignore it. For example, when LCR is in beta, feedback from the beta (only) used to be routed to a different system where the team could review it to see whether there were defects that needed to be addressed during the beta process. Handling all of that feedback was a pretty big task and that was only for a subset of the users.

Yes, you can submit tickets for facilities issues through a standard interface and they get to the right person. That works because your problem report is associated with a specific building. That building is associated with a specific facility management group and the report is routed to that FM group. Someone at the FM office processes the report, they know which building you're talking about, and they dispatch one of the FM mechanics to address it.

That doesn't work when it comes to software. If you have an issue with LCR, there may be one of several teams that needs to address that based on what part of LCR it is related to. To create some standardized bug reporting system would require a new project to be spun up to build out a system for managing a database of projects and routing feedback based on that. If it comes down to building something that makes it easier for you to submit bug reports or building something that makes it more efficient for a bishop to accomplish an important task for his ward, the bishop is going to win every single time.

Posting problems here will potentially help you find a solution if it is a problem that some other community member has solved. Posting here is not a method for contacting a development team. There isn't an official Church presence here, even though some of us have "Church employee" name badges by our names.

As for submitting feature requests ... there are a lot of people who aren't submitted bug reports but are instead asking for functionality changes. This is where your comment about waiting for reports to trickle up through leaders comes into play.

First, let me first make a few things clear:

#1 - Developers do not typically make feature decisions. While they have some input into the process as things are designed and have a more direct route to suggest features, they don't make the final decisions.

#2 - You don't make feature decisions. These projects are not open-source projects where somebody comes up with a great idea that they suggest implementing, a bunch of people "+1" the message, and then someone who thinks it is a neat idea goes and builds it.

When it comes to determining what goes into a product, product managers work with councils that are responsible for those products. They decide which features are appropriate given Church policy, legal constraints, and other concerns. Those decisions then become development tasks.

So, if there is some feature that you feel really needs to be implemented, you have a few options:

* You can come rant on the forums. That won't accomplish much.

* You can send feedback. That should make its way to a product manager who can bring up appropriate suggestions as potential enhancements. And then it might get implemented. Or it might get dismissed. There are plenty of things that people suggest that aren't going to make it into a product because they don't align with Church policy, legal requirements, or the priorities of an application.

* Stake presidents have access to an area seventy who has a more direct route to the departments responsible for products. If they feel strongly that a change in functionality would improve the work, they can make that suggestion to that area seventy who is a position to make that suggestion to the appropriate departments if he feels it is worthwhile. This is the game of "telephone" you're talking about. Even those suggestions might not make it into a product. My stake president has a feature change that he feels strongly about and he and I have talked about it extensively. He also knows that it's just not going to happen. Sorry, president.

There is a subset of users here who are happy to rant about how the Church IT department screwed up or the development team blew it because they didn't do something that is perfectly obvious to the person making the rant. My suggestion: "stop it." You may have great ideas and you may even be a great software developer, but you don't know the details of those things you criticize. The thing that is perfectly obvious to you may have been discussed extensively and ruled out for any one of a number of reasons. As I said a few weeks ago, "there are plenty of talented people working on the issues and telling them how to do their jobs seems a bit presumptuous."

[russellhltn]

The most common "feature" request is to get access to information about other members. That data is subject to a number of privacy laws. It's not the church's data. It belongs to each member listed. It can only be handed out for reasons outlined by law and based on responsibilities outlined in the Handbook. The church can't just declare "every member a leader".

It didn't used to be that way, but that is the world we live in now.

I strongly suspect that's the issue behind the current problem.

[greenwoodkl]

scgallafent,

Thank you for your lengthy reply and thank you for splitting my post. I'm sorry if it muddied the water in the other thread.

It is a hard tension and boundary to keep, but I generally want to seek an understanding of truth and the lay of the land rather than criticize. I do find it frustrating to come to the forums or send feedback into the black box of the website, mostly because there isn't much of a feedback loop. Have I been heard, ignored, or was there enough turnover among staff and my message was lost in the shuffle? I don't want to waste the time of the church service missionaries, product managers, and volunteer developers here on the forum who are trying to help by proposing a change or feature that has already been through the rounds and rejected. "Discussed extensively and ruled out" as you put it. I know the Church is not a traditional software company with open-source projects, but I do find websites helpful such as FamilySearch's use of Get Satisfaction (when it was more active) or similar idea platforms where there is a modicum of feedback such as Under Consideration or Not Planned, etc... I also am a bit curious if it is overkill to submit feedback via the website for online tools functionality as well as by email for Member Tools for similar functionality between both platforms? Are they independent enough product management teams that suggestions should go to both teams for consideration, or is some level of parity between the functionality of tools on different platforms a goal?

[sbradshaw]

In case it's helpful, most of the mobile apps have a "Send Feedback" link in Settings (Member Tools is slightly different, it's a "Contact Us" link under help). This is similar to the general Feedback links at the bottom of the Church website, but is routed more easily when sending feedback about the app. Bug reports and feature requests can be sent, and they will be reviewed by employees or service missionaries, escalated up to developers if needed, or added to a report for product managers when it comes to feature requests, but unfortunately it is somewhat of a black box like you say.

[johnshaw]

greenwoodkl,

The plain truth of the matter is that members of the church are not the customers of the apps, it is the church departments, and those councils that are technically the customer or client - It helps me to understand that.

Also, you can join the beta groups for at least Gospel Library and Member Tools - The idea is to test during beta and provide feedback, and often 'suggestions' come through that area (under the conditions from above).

[greenwoodkl]

johnshaw, what is the process to participate in the beta?

[scgallafent]

I also am a bit curious if it is overkill to submit feedback via the website for online tools functionality as well as by email for Member Tools for similar functionality between both platforms? Are they independent enough product management teams that suggestions should go to both teams for consideration, or is some level of parity between the functionality of tools on different platforms a goal?

When it comes to membership (Member Tools, LCR, Directory), they all eventually consolidate into a single product management group. Sending it both places won't hurt, but it's going to end up with the same group of people.