Updating ward members email addresses

Share discussions around the Classic Local Unit Website (LUWS).
Locked
chriswoodut-p40
New Member
Posts: 14
Joined: Thu Jan 25, 2007 7:08 pm
Location: Springville, Utah, USA

Updating ward members email addresses

#1

Post by chriswoodut-p40 »

One of the biggest challenges our ward has is in maintaining the ward members' email addresses. Our ward webmaster has done a great job getting people signed up, but the members themselves won't maintain the email addresses.

We don't mind contacting the members to get the new addresses, but the ward webmaster cannot update the email addresses, the member must do it from their login. They usually do not remember their password, so then it becomes a major chore and most members simply won't do it.

I'm the Elder's Quorum secretary and because of this problem, I maintain my own spreadsheet of email addresses so that we can do email announcements, home teaching reporting, etc, and still hit the majority of the quorum members. It is easy for me to pass around a list of email addresses and ask for updates, but I can't share this info with the ward webmaster to update the website.

That leads me to my next comment.... Assuming the email addresses can be maintained by the webmaster, it would be really cool if a user such as myself could create my own mailing list via the ward website. This way I could select the 10 people I want to mail out to occasionally. This would be handy to select those that report their home teaching to me to send out reminders. Or our committee heads could have a group that they send emails out to. The new member contact information export option is handy to work around this for now.
sochsner
New Member
Posts: 26
Joined: Tue Jan 30, 2007 8:08 am
Location: Henderson, Nevada

#2

Post by sochsner »

Well, I you have the email, you can make a local mailing list. But I agree with you, the website should have more customization.
User avatar
ShellineSE
New Member
Posts: 28
Joined: Fri Nov 10, 2006 3:04 pm
Location: Utah

#3

Post by ShellineSE »

One of the challenges of developing a local-unit website for a global Church membership is that so many of the desired features are better met by third-party applications. For example, chriswoodut needs features common to e-mail systems; elsewhere, there are threads asking for mapping, photo directories, calendaring, scheduling, etc.--all addressed in the marketplace by excellent solutions. Even if we could build a proprietary (i.e., internally developed) LUWS that incorporates these and many other features, is that the best use of "the widow's mite?"

So what is the best way to take advantage of existing technologies (OSS and commercial) to create an experience that meets the widest degree of needs but still protects the personal information of members and confidential Church data?
grhart-p40
New Member
Posts: 15
Joined: Fri Jan 19, 2007 9:49 am
Location: Palo Alto, CA

#4

Post by grhart-p40 »

shellinese wrote:So what is the best way to take advantage of existing technologies (OSS and commercial) to create an experience that meets the widest degree of needs but still protects the personal information of members and confidential Church data?
A suggestion you've probably considered...

Without completely open-sourcing MLS and LUWS, provide OSS developers with an API and let them come up with the solutions. A small, but good example of this is what you've done with the CSV membership directory now available on the LUWS (and the CSV exports from MLS). Many useful, spin-off utilities are possible because of these, without spending a single widow's mite, other than maybe our own. Nonetheless, these utilities are only as good as the information available in the data provided to us. If MLS can't bind a wife's cell phone to her individual membership record and make that available to the LUWS, we're stuck.

Under what conditions would the Church allow MLS/LUWS 'plug-ins' to be developed, things like a sanctioned alternative to LUWS Email Broadcast, a printer-friendly photo-directory, a Home and Visiting Teaching Reporting tool, etc...? How can we do this and still abide by current Church internet policy of not hosting membership data on any URL other than lds.org or using alternative email list managers for official ward business?

Build an open framework and API for MLS and LUWS and let us all take our favorite feature request and do something about it. Granted, there's an initial investment on the part of Church-employed developers, but afterwards, you would be able to delegate the majority of bugs/feature requests and only deal with the minority, the ones associated with the framework and API.

-Greg
User avatar
WelchTC
Senior Member
Posts: 2085
Joined: Wed Sep 06, 2006 8:51 am
Location: Kaysville, UT, USA
Contact:

#5

Post by WelchTC »

grhart wrote:A suggestion you've probably considered...

Without completely open-sourcing MLS and LUWS, provide OSS developers with an API and let them come up with the solutions. A small, but good example of this is what you've done with the CSV membership directory now available on the LUWS (and the CSV exports from MLS). Many useful, spin-off utilities are possible because of these, without spending a single widow's mite, other than maybe our own. Nonetheless, these utilities are only as good as the information available in the data provided to us. If MLS can't bind a wife's cell phone to her individual membership record and make that available to the LUWS, we're stuck.

Under what conditions would the Church allow MLS/LUWS 'plug-ins' to be developed, things like a sanctioned alternative to LUWS Email Broadcast, a printer-friendly photo-directory, a Home and Visiting Teaching Reporting tool, etc...? How can we do this and still abide by current Church internet policy of not hosting membership data on any URL other than lds.org or using alternative email list managers for official ward business?

Build an open framework and API for MLS and LUWS and let us all take our favorite feature request and do something about it. Granted, there's an initial investment on the part of Church-employed developers, but afterwards, you would be able to delegate the majority of bugs/feature requests and only deal with the minority, the ones associated with the framework and API.

-Greg
What you are suggesting is what we are looking at doing. Please be patient as there are a lot of things to discuss internally. The decision will not come from our technical group but from those in charge of "owning" the data. If/when we do come out with some API's or web services, they will also be surrounded by policy on the use of the data. I'll keep you informed as we further our internal discussions.

Tom
User avatar
thedqs
Community Moderators
Posts: 1042
Joined: Wed Jan 24, 2007 8:53 am
Location: Redmond, WA
Contact:

#6

Post by thedqs »

Well hopefully you'll be able to show now that at least the tech members want those features. Though I believe we all know that policy and updates don't come out in a day or a week. Though I am working on a work around in which I create an interface that goes through the HTTPS protocal to the website and access the information that way.. talk about parsing though. :)

Any suggestions on how to make this easier would be nice though.
- David
User avatar
WelchTC
Senior Member
Posts: 2085
Joined: Wed Sep 06, 2006 8:51 am
Location: Kaysville, UT, USA
Contact:

#7

Post by WelchTC »

thedqs wrote:Well hopefully you'll be able to show now that at least the tech members want those features. Though I believe we all know that policy and updates don't come out in a day or a week.

Also, as far as the Church is concerned, policy is not dictacted by what people want or say but rather by inspiration. One of the benefits of these forums is to add a data point for those in charge of devising policy but it does not dictate what they do. I'm going to blog about this concept soon.

Tom
User avatar
thedqs
Community Moderators
Posts: 1042
Joined: Wed Jan 24, 2007 8:53 am
Location: Redmond, WA
Contact:

#8

Post by thedqs »

About my interface it is a java package so that it can be cross-platform, and should be easy to call from any program really.
- David
Locked

Return to “Classic Ward & Stake Sites (LUWS)”