Please fix Bounced Mail Bug in current version of LUWS
-
- New Member
- Posts: 18
- Joined: Tue Jan 30, 2007 10:45 am
- Location: Edmonton, Alberta, Canada
Please fix Bounced Mail Bug in current version of LUWS
I know there are a lot of suggestions coming into this site for the next version of LUWS, but I really think there are some issues that could be fixed now! The problem with overloading ward/branch/stake administrators with bounced e-mail is one such issue that is a BIG problem, with a potentially simple if temporary solution, that should be viewed as a priority bug fix for the currently deployed version of LUWS.
One of probably dozens of possible (short-term) solutions would be to use a "no-reply" e-mail address in the FROM header and append an appropriate header and footer to every e-mail message explaining that replies to the "no-reply" address will not be responded to and instead refer the recipient to the administrator by name and e-mail address so that the user knows who to contact with questions, feedback, etc. This seems like a simple enough solution which should require very little tinkering in the code (unless the code is a mess).
If you have the connections, PLEASE BRING THIS UP SOON at a development meeting and make sure it gets fixed.
I have presented a potential solution for this version of LUWS. For the next version, perhaps there is a better way to deal with bounced mail. I'll even put out a suggestion for the next version: Have the system periodically report to the ward/branch (not stake) administrator which users (by name and e-mail address!) need to update their profile with a current e-mail address --- but please, don't send instant feedback for the potentially dozens (or hundreds if a stake notification/broadcast) of recipient e-mail addresses that bounce!
One of probably dozens of possible (short-term) solutions would be to use a "no-reply" e-mail address in the FROM header and append an appropriate header and footer to every e-mail message explaining that replies to the "no-reply" address will not be responded to and instead refer the recipient to the administrator by name and e-mail address so that the user knows who to contact with questions, feedback, etc. This seems like a simple enough solution which should require very little tinkering in the code (unless the code is a mess).
If you have the connections, PLEASE BRING THIS UP SOON at a development meeting and make sure it gets fixed.
I have presented a potential solution for this version of LUWS. For the next version, perhaps there is a better way to deal with bounced mail. I'll even put out a suggestion for the next version: Have the system periodically report to the ward/branch (not stake) administrator which users (by name and e-mail address!) need to update their profile with a current e-mail address --- but please, don't send instant feedback for the potentially dozens (or hundreds if a stake notification/broadcast) of recipient e-mail addresses that bounce!
- jeromer7
- Member
- Posts: 228
- Joined: Thu May 17, 2007 12:46 pm
- Location: Bellevue, Nebraska
-
- New Member
- Posts: 18
- Joined: Tue Jan 30, 2007 10:45 am
- Location: Edmonton, Alberta, Canada
"Just don't use that feature..." solution
I usually opt-out of e-mail notifications too, although mainly because of another bug. You bring up another point that seems to be a recurring theme in this forum. "If it's broken, don't use it. Then come up with your own solution" (because no one has any clue when or if the issue will be fixed, or even if it has been acknowledged by the development team).JLRose wrote:As the Stake Web Site Admin, I clear the check mark if a submitter has selected e-mail notifications for their submission. It is just too gruesome to have to deal with all the bounces that come back to my personal Inbox from throughout the stake.
- WelchTC
- Senior Member
- Posts: 2085
- Joined: Wed Sep 06, 2006 8:51 am
- Location: Kaysville, UT, USA
- Contact:
We are reading and watching this thread. As I mentioned previously, we are getting a very slow start on this project. There is not any active development on the new project at this time. So all input will be reviewed before we start.dragev wrote:I usually opt-out of e-mail notifications too, although mainly because of another bug. You bring up another point that seems to be a recurring theme in this forum. "If it's broken, don't use it. Then come up with your own solution" (because no one has any clue when or if the issue will be fixed, or even if it has been acknowledged by the development team).
Tom
-
- New Member
- Posts: 18
- Joined: Tue Jan 30, 2007 10:45 am
- Location: Edmonton, Alberta, Canada
What about maintenance work on current version?
I guess I'm wondering why this type of issue, and this issue in particular, isn't being considered as maintenance work for the current version of LUWS (I'm assuming that there is bug fixing going on all the time), instead of the usual response here in this forum, that the problem will addressed in the next version?tomw wrote:...There is not any active development on the new project at this time...
- WelchTC
- Senior Member
- Posts: 2085
- Joined: Wed Sep 06, 2006 8:51 am
- Location: Kaysville, UT, USA
- Contact:
I'm sorry it is not getting done as quickly as possible. All of our resources are busy working on projects of more importance as defined by our leadership. Hopefully we will be able to get some time to fix some of these issues before the next release is started.dragev wrote:I guess I'm wondering why this type of issue, and this issue in particular, isn't being considered as maintenance work for the current version of LUWS (I'm assuming that there is bug fixing going on all the time), instead of the usual response here in this forum, that the problem will addressed in the next version?
Tom
- jeromer7
- Member
- Posts: 228
- Joined: Thu May 17, 2007 12:46 pm
- Location: Bellevue, Nebraska
tomw wrote:I'm sorry it is not getting done as quickly as possible. All of our resources are busy working on projects of more importance as defined by our leadership. Hopefully we will be able to get some time to fix some of these issues before the next release is started.
Tom
Well, I'm just encouraged that these forums are available and we out in the hinter lands have the ability to share our real-world experiences with the Church's products. Being a software development manager myself, I fully appreciate the balance of resources versus customer desires.
It would be helpful for us to have some visibility into what is on the list for MLS, LUWS, etc., as has been discussed in a different thread. However, I understand the overhead this would be unless it's just giving us access to something that already exists.
LDSTech is a great step forward and I really appreciate the effort.
JLR
- WelchTC
- Senior Member
- Posts: 2085
- Joined: Wed Sep 06, 2006 8:51 am
- Location: Kaysville, UT, USA
- Contact:
When we have a definitive list, I'll see if I can get it published.JLRose wrote:Well, I'm just encouraged that these forums are available and we out in the hinter lands have the ability to share our real-world experiences with the Church's products. Being a software development manager myself, I fully appreciate the balance of resources versus customer desires.
It would be helpful for us to have some visibility into what is on the list for MLS, LUWS, etc., as has been discussed in a different thread. However, I understand the overhead this would be unless it's just giving us access to something that already exists.
LDSTech is a great step forward and I really appreciate the effort.
Tom
-
- New Member
- Posts: 15
- Joined: Fri Jan 19, 2007 9:49 am
- Location: Palo Alto, CA
Yes, please. Please post a spec for the next versions of MLS and LUWS. Of anyone, the Church developers must be the most tired of hearing the same old bugs and feature requests repeated over and over again for the past three years from frustrated Stake/Ward Clerks and Webmasters. I would suggest that makeing a spec available to an interested group of end-users (tech.lds.org'ers) would quiet alot of common requests and gather critical feedback so the very precious development cycles at the Church are not wasted. If there's no one available at HQ to write the spec, I'm certain this could recruited. There are laundry lists available, but these are begging for a single-minded direction.tomw wrote:When we have a definitive list, I'll see if I can get it published.
We understand that the Church is not run by popular vote and that direction at the COB almost always comes from top-down. Consider the MLS and LUWS user-base as a large counsel and gathering feedback prior to developement work as "couseling with your counsels". Then I would budget for maintenance;)
Looking forward to what's coming,
-Greg
- WelchTC
- Senior Member
- Posts: 2085
- Joined: Wed Sep 06, 2006 8:51 am
- Location: Kaysville, UT, USA
- Contact:
Great advice. Thanks!grhart wrote:Yes, please. Please post a spec for the next versions of MLS and LUWS. Of anyone, the Church developers must be the most tired of hearing the same old bugs and feature requests repeated over and over again for the past three years from frustrated Stake/Ward Clerks and Webmasters. I would suggest that makeing a spec available to an interested group of end-users (tech.lds.org'ers) would quiet alot of common requests and gather critical feedback so the very precious development cycles at the Church are not wasted. If there's no one available at HQ to write the spec, I'm certain this could recruited. There are laundry lists available, but these are begging for a single-minded direction.
We understand that the Church is not run by popular vote and that direction at the COB almost always comes from top-down. Consider the MLS and LUWS user-base as a large counsel and gathering feedback prior to developement work as "couseling with your counsels". Then I would budget for maintenance;)