Sync policy

What is the policy in storing a copy of the calendar in a Google calendar? Is there an official word on this? I know it is possible, but as we all know, just because a Church employee did something, does not automatically make it the mind and will of the Lord... : )

The closest thing I have found to official policy is at https://www.lds.org/help/support/keepin ... ation-safe, specifically "Do not store data found in Church applications in consumer cloud storage apps".

Do we consider the church calendar to be a Church application? Would the names/ages/locations of children found in any given ward calendar, or the name/email/phone number of every person who has ever scheduled an event, be considered 'data', or even 'membership data'?

I think anyone here can read that I have some discomfort with it, but I am really asking if there is an official policy. Or better, any way we can be sure that the quote above does not apply to the membership data found in the Church calendar application?

The sync function is an explicit part of the calendar application and has been since the start. Things like that don't get added just because a developer feels like it. They are approved by the appropriate general authorities and probably also by the church's legal department. If it violated the policy then I expect it would have been removed like most exports have been. Generally, the calendar sync doesn't have sensitive information--just the date, time, location and description of the event. There isn't any information about members.

The calendar's sync section says "Events in your Church calendar can be synced with you Google, Microsoft Outlook, or Apple Calendar." They even give you directions on how to do it. I think it's pretty safe to say it's OK to put it in Google calendar.

However, the sync URL does say "This URL is provided for your own personal use. It should not be shared with anyone else." So, making the church calendar public would be prohibited.

eblood66 wrote:The sync function is an explicit part of the calendar application and has been since the start. Things like that don't get added just because a developer feels like it. They are approved by the appropriate general authorities and probably also by the church's legal department. If it violated the policy then I expect it would have been removed like most exports have been. Generally, the calendar sync doesn't have sensitive information--just the date, time, location and description of the event. There isn't any information about members.

Promise, not trying to ruffle feathers here. Was just looking for something official. So, sorry about my tone, it wasn't intended.

That said, as an IT PM myself, I certainly do not submit every function to the VP for approval, and wouldn't dream of submitting anything to legal. Sure, if they see it afterward and it wasn't something they asked for, I and the whole department could get fired... but I know from experience that just because something goes live, doesn't mean that it was explicitly part of the original scope. Scope creep is something we fight every day. Of course, also doesn't mean it was scope creep. If you or I had our hands on the original requirements documentation, that would be an [?odd?] example of the 'official policy' I was looking for. So, sorry for my flippant tone before, I didn't mean to disparage anyone, and never thought poorly of any of the employees... I was just trying to prevent 'official policy' from being preempted by "has been since the start", "probably", and "expect". Now, maybe there is no 'official policy' available to mere mortals like me.

On the other hand, I attached here an example of a calendar event synced for next weekend. This one only has 2 members' names, one a child, and the time and location. This particular one doesn't have any contact information (for information contact [email] or [phone number]), but others do. This one does not explicitly (only implicitly) give age or birth date, but others do.

I think I may be misunderstanding what 'membership data' or 'church application' means. I would welcome education. Is there an official policy? Or is it just probably fine, because it always has been in the past?

I'm not sure what you'd consider "Official Policy". I've been referring people to the Meetinghouse Technology Policy. I think it's a little narrower in defining what's not to be shared to the cloud.

Most functions (like calendar sync) do get vetted by a higher authority, so in this case, I don't think there's a problem. Other apps have had export functions removed. But they were things like the directory which is clearly membership data. You may or may not be able to see Calendar 3.0 yet, but the sync is still there. It may be one of the few apps where "export" is still allowed.

I suspect the writers and reviewers of the Keeping Church Information Safe page didn't consider the Calendar app when they made that pronouncement. Normally, calendar events don't have member's names. I don't see the "scheduled by" field in my Google calendar. So, all that's left is what's typed into the event and description fields.

Interesting, thank you. I didn't consider the calendar application to be a "meetinghouse technology", but I do see that 4.9.3-4.9.4 do directly address "any membership related data" in "cloud-based services". Though, to me, this actually seems more broad, not narrow, but does bring up a good point. Perhaps I have been looking at this backwards.

Is the problem that the Church's calendar application was never intended to have membership data, like name of person being baptized, contact information for an event, and so forth, in the event and description fields?

Or do I have a misunderstanding of what constitutes "membership related data", and information like names, phone numbers, birth dates, addresses can in fact be stored in the Google cloud servers?

Thank you, this conversation is helpful for me.

cawilson wrote:Is the problem that the Church's calendar application was never intended to have membership data, like name of person being baptized, contact information for an event, and so forth, in the event and description fields?

I don't think the calendar is intended to have specific information like name, age, or contact information of individual members. If your ward is putting that information in, it might be something to consider with regards to policy and protecting membership data. The contact information of the event scheduler that's automatically attached to an event doesn't sync outside of the official Church tools, as far as I know.

I'd note that the kind of information cawilson described as on his calendar is probably the same kind of information that is likely to be included in a weekly announcements email which will then likely end up on Google's or Microsoft's servers as well. Hopefully leaders are reasonably careful about the information they enter into the calendar and send in announcements. But there is a certain level of necessary information about events that is likely to be impossible to avoid ending up in peoples email store or calendar unless we entirely abandon modern communications methods.

So, personally, I have no concern with using the existing calendar sync. Now, if only my ward and stake actually used the lds.org calendar I might actually enable the sync.