Photo directories and fellowshipping roles

Hi,

I was recently called as a 'Technology Specialist' to my ward's 'Welcoming Committee'.

My ward is a SLC-located YSA-specific ward, focused at university students.

Most if not all of the companion wards in my stake and adjoining stakes have traditionally utilized several tools to increase fellowshiping in these very high turnover units. One of the most critical objectives is to maintain a names-to-faces awareness by the ward's leadership of the constantly changing congregation.

1. Each Bishop has a large whiteboard in their office with all (active only?) members photo's with magnets to provide an immediate visual overview of present ward organization. Pictures are approximately 1.5"x2" and have the member's name printed on them.
2. The ward website is frequently used to generate a hard-copy of what is humorously called the 'Ward Menu', as even us kids can grudgingly admit that having a hard-copy list of names and faces can often be easier to browse than an electronic form.
3. A variant of 1 and 2 is also desired, eg a high-density page(s) of thumbnail pictures with only names.

My Bishopric has recently tasked the Welcoming Committee in general, and me in specific, to devise a mechanism to efficiently generate several different photo-centric tools for different purposes.

1. Pictures for the whiteboard need to be ready for display no later than the Tuesday following the new member's first Sabbath of attendance (when they submit their new member information)
2. A directory with photos needs to be available for print on demand. This can be generated from the 'All Members with Photos' view from the Ward web site if necessary.
3. An expanded directory for Bishopric use is also desired. This would add the names of currently assigned home teachers, current calling and date of sustaining, and a yes/no indicator of whether an MRN is present for the member.

The Y/N note about MRN is because the Bishop can only give Temple Recommend interviews to members for which the unit has records of. This is not intended to replace or even supplement any of the records involved in the interview process, rather it is used to indicate that records had not yet been recieved for the individual at the time of the last printing, so the Bishop should check other records directly before proceeding. Quite frequently, members will ask for temple recommend interviews during the 'Meet the Bishop' first meeting, it's easy enough to catch those cases, but the week following can get confusing when you've had a net change of over a hundred members in a 3~4 week window.

As this project has snowballed over the past month, along with the new school year triggering a significant membership shift, there's been several issues come up that I've been uncertain as to where to find answers to. I'm sure there's a policy or explanation for them, I'm just not sure where to look or who to ask.

1. What is the policy regarding publication of birthdates, or where can I find the policy? I've seen directories from many-many years ago that dropped the year for members older than 18 or 21, is that still usable or should it be only visible to the Bishopric/Leadership?
2. Is coordinating a project like this delegatable to a non-leadership calling? Can it be done by non-clerks with approval by the Bishopric? Is there a field-by-field policy of what may and may not be delegated?
3. Can MLS make custom print layouts, and integrate photos from external (linked?) files, or is it limited to custom report queries only?
4. Can Custom Reports be saved as digital files, or only printed as hard-copies?
5. I'm aware of the policy directing that unit 'business' should not be done on any public-facing provider other than *.lds.org (although I don't have the reference handy), what restrictions are there on processing the data on a personal computer with the objective of creating alternative print layouts?
6. Is the Python scripting engine approved for installation on church asset clerk computers? What about Imagemagick? One of the objectives is for the directory system to be maintainable. I've setup less tech-savvy individuals previously with imagemagick, 'in' and 'out' folders, and a batch file for automaticly scaling any digital camera picture for use on the ward website. Python would be ideal for creating a CSV > XML converter to merge the various MLS exports, and then print them.

Thanks.

I can answer a few questions, and others I'm sure will chime in with additional responses.

mogura wrote:3. An expanded directory for Bishopric use is also desired. This would add the names of currently assigned home teachers, current calling and date of sustaining, and a yes/no indicator of whether an MRN is present for the member.

The Y/N note about MRN is because the Bishop can only give Temple Recommend interviews to members for which the unit has records of.

The MLS "Household Report" contains all this information. Because it includes the MRN, you don't really need a separate "Y/N note about MRN" because it will be blank if the record has not actually been received.

mogura wrote:1. What is the policy regarding publication of birthdates, or where can I find the policy? I've seen directories from many-many years ago that dropped the year for members older than 18 or 21, is that still usable or should it be only visible to the Bishopric/Leadership?

I'm not sure where to find such a policy.

mogura wrote:2. Is coordinating a project like this delegatable to a non-leadership calling? Can it be done by non-clerks with approval by the Bishopric? Is there a field-by-field policy of what may and may not be delegated?

There is certainly no field-by-field policy of what may be delegated. I believe the bishop has wide latitude in making assignments as long as he preserves confidentiality appropriately.

mogura wrote:3. Can MLS make custom print layouts, and integrate photos from external (linked?) files, or is it limited to custom report queries only?

MLS can make custom reports, but there is very limited flexibility of layout. There is no ability to integrate photos from external files. There are various MLS Export files (CSV format), or the result of any custom report can be exported as a CSV, so customized applications could be created to manipulate and format this data.

mogura wrote:4. Can Custom Reports be saved as digital files, or only printed as hard-copies?

Every ward or stake administrative computer should have PDF print driver called CutePDF, which can be used to save a PDF image of custom reports. Also, as I mentioned above, the custom report data can be saved as a CSV.

mogura wrote:5. I'm aware of the policy directing that unit 'business' should not be done on any public-facing provider other than *.lds.org (although I don't have the reference handy), what restrictions are there on processing the data on a personal computer with the objective of creating alternative print layouts?

The policy can be found at Authorized Church Web Sites. The restrictions on transporting or processing confidential data can be found in Policies and Guidelines for Computers Used by Clerks for Church Record Keeping (the Security section), which says that such information should be password protected and transmitted only to authorized people for Church use.

mogura wrote:6. Is the Python scripting engine approved for installation on church asset clerk computers? What about Imagemagick? One of the objectives is for the directory system to be maintainable. I've setup less tech-savvy individuals previously with imagemagick, 'in' and 'out' folders, and a batch file for automaticly scaling any digital camera picture for use on the ward website. Python would be ideal for creating a CSV > XML converter to merge the various MLS exports, and then print them.

As you can also read in the policy document, additional software may be installed with proper approval. Work with your stake technology specialist, who can get the appropriate approval from the stake president.

You might want to look at the MLS Companion application, which includes a feature for importing photos. (Not sure about printed reports.)

Also, this thread -- Ward Photo Directory Template -- has some ideas for a photo directory.

mogura wrote:

1. What is the policy regarding publication of birthdates, or where can I find the policy? I've seen directories from many-many years ago that dropped the year for members older than 18 or 21, is that still usable or should it be only visible to the Bishopric/Leadership?
2. Is coordinating a project like this delegatable to a non-leadership calling? Can it be done by non-clerks with approval by the Bishopric? Is there a field-by-field policy of what may and may not be delegated?

I know of no policy. This is all "bishop's prerogative". I'm not sure who is raising this concern, but as a suggestion, you may want to consider calling this individual as an "assistant clerk". I don't know of anything preventing the ward from having multiple membership clerks. I know some members are very sensitive about their information. So doing it this way should prevent any issues now or in the future.

mogura wrote:I'm aware of the policy directing that unit 'business' should not be done on any public-facing provider other than *.lds.org (although I don't have the reference handy), what restrictions are there on processing the data on a personal computer with the objective of creating alternative print layouts?

I don't know of any policy. However, I would be of the opinion that it should require the bishop's approval and with full disclosure to the bishop of all the information that's being taken to this personally-owned computer.

Note that it is forbidden to run MLS with live data on a personally-owned computer as well as trying to reverse-engineer the MLS data files.

Thanks for the comments. I'm aware of CutePDF, good to know it's available on clerk machines.

Just to clarify a couple things, the Bishopric called me as a member of the Welcoming (Fellowshipping) Committee, with the task of "Get the data from the clerks minus ordinance data and make these following types of resources, in as transferable and maintainable manner as possible."

The two primary technical requirements are that I need to integrate pictures (Can pictures be integrated at all into MLS?) and make specific print layouts (appears to not be possible in MLS presently?). I can of course do that all in python and xml/xsl.

Observations:

1. This project is not to make an alternative non-MLS records source, rather it is only intended to visually layout the MLS derived data in an alternate format, and combine with an external source of pictures. I guess this meets the requirements for MLS being the sole source of data? Essentially, the objective is that the ward clerk can generate new reports > formatted directories on demand from current MLS data, the interim XML step is only to feed the XSL template.
2. For data security, does locking the device with secure user accounts suffice for transferring data to a non-church asset, or does the data need to be data-level secured in addition to any system-level discretionary user access? I consider the policy re PDA's to apply as well to non-PDA devices used to analyze 'church information', but it's not clear whether the requirement is at the data-level or if system-level is sufficient.

Church information downloaded to personal digital assistants (PDAs) for authorized use by priesthood leaders should also be password protected.

Responses to Alan_Brown:

1. 'Household Report': The current plan is to append the list of new members onto the bottom of the list from MLS for the purposes of the photo directory. As such, there will be individuals in the Bishopric's directory that may not have records in the ward yet as of last printing. This is only a convenience index indicator, and doesn't replace the more detailed (and authoritative) records report.
2. 'Birth dates': Wiki suggests that birth-year of adults is 'sensitive', no reason to consider it otherwise. Shouldn't be a challenge to throw a LEN slicer at it.
3. 'Column delegation': Future members with directory maintenance responsibility may not be as tech-savvy, so if the data is cleaned as much as possible there's less risk of problems. The less they have to manage, the better.
4. 'Custom layouts': This is the core objective of this assignment.
5. 'Policies': Thanks for the links, my personal policy is to insist on the actual policy, rather than 'wing it'.
6. 'Software': At this point, the only things I'm considering is Python, Imagemagick, and my own developed .xml, .xsl, .py, and .html files. Python's license is here: http://www.python.org/download/releases/2.6.2/license/ and imagemagick's is here: http://imagemagick.com/script/license.php Both are as far as I can tell should be acceptable for church use. My files are free-domain and entirely my own work.

Responses for BoomerBubba:

Thanks for the links. MLS Companion is rather over-kill for this project, only directories and pictures need processing, and it's intended to be done by non-clerks and non-tech savvy members.

The photo directory thread was very helpful too, but I think my fellow nerds there have way over complicated what it takes to generate photo directories. I'll post the code later today for what I've created, the photos directories can be viewed and printed from any XML rendering web browser on Mac, PC, or Linux without installation of any software.

Responses to RussellHltn:

1. I'm raising the question, as it's a random niggly stuck in my head from when as a little child watching my dad do clerk work "Daddy, why don't the grownups have birthdate years?" I heard it was policy, just wanted to confirm that as opposed to 'tradition'.
2. The absolute most that would be distributed from the clerk's machine would be the Organization, HT/VT, and Membership (without Ordinance data) CSV exports. The goal is that a python script on the clerk's machine will mash them together into an XML file, which can then be sent to designated members with the XSL files and pictures.

Imagemagick's purpose is to resize and crop random source pictures to ward web site demension requirements. This is not needed for photo directories since HTML attributes for the IMG tag can control display sizes.

mogura wrote:

1. What is the policy regarding publication of birthdates, or where can I find the policy? I've seen directories from many-many years ago that dropped the year for members older than 18 or 21, is that still usable or should it be only visible to the Bishopric/Leadership?

When I was creating a ward directory several years ago, I remember reading a policy in the church handbook (no access to one now, so I can't give the page no.) that publications should not include individual's birthdays (even with the birth year deleted) without their permission. But I've never heard of anyone not giving permission when asked.

mogura wrote:I need to integrate pictures (Can pictures be integrated at all into MLS?)

No, there is no ability to store pictures in MLS. So you'll have to store pictures externally and figure out how to link them. To link, there obviously has to be some unique key; the MLS membership export file has a column called "Indiv ID" that you might want to use, since names might be a bit tricky to reliably link on. You might find the wiki article Export (MLS) helpful, as it details each field of the export, and then you can tell the clerks which non-sensitive columns you need.

mogura wrote: and make specific print layouts (appears to not be possible in MLS presently?). I can of course do that all in python and xml/xsl.

Indeed it is not possible to make specific print layouts in MLS. Since MLS doesn't have pictures, using MLS for layout really isn't an option anyway.

mogura wrote:For data security, does locking the device with secure user accounts suffice for transferring data to a non-church asset, or does the data need to be data-level secured in addition to any system-level discretionary user access? I consider the policy re PDA's to apply as well to non-PDA devices used to analyze 'church information', but it's not clear whether the requirement is at the data-level or if system-level is sufficient.

You quoted the relevant policy for PDAs. You'd have to consult with your local priesthood leaders for local interpretation, but in my opinion, since a PDA would most likely have only system-level passwords, that would be sufficient in this case as well.

mogura wrote:Imagemagick's purpose is to resize and crop random source pictures to ward web site demension requirements. This is not needed for photo directories since HTML attributes for the IMG tag can control display sizes.

There is a standard application recommended by the Church for image manipulation called Photofiltre that can be loaded on the ward computer with no extra permissions (your stake technology specialist can download it from mls.lds.org). But if you want to use Imagemagick, as I mentioned previously, just work with your STS for permission, as you would need to do for Python, anyway.

Alan_Brown wrote:No, there is no ability to store pictures in MLS. So you'll have to store pictures externally and figure out how to link them. To link, there obviously has to be some unique key; the MLS membership export file has a column called "Indiv ID" that you might want to use, since names might be a bit tricky to reliably link on. You might find the wiki article Export (MLS) helpful, as it details each field of the export, and then you can tell the clerks which non-sensitive columns you need.

That is what I would do. One thing I wonder about is at what point MLS enters a new record and thus assigns an Indiv ID. In the case of a new ward member who shows up on Sunday, triggering the clerks to request the record, does that get captured in the MLS export file immediately, before CHQ responds? I think so, but would need to verify that.

One more gotcha to consider: In order to get a sanitized export file from the clerks in a reliably consistent format, someone should probably write a script for them to use to filter the MLS export file. They can do it manually, but it would be error-prone. Also, editing the export file manually would probably be done in a spreadsheet, which would alter the internal format of the file.

Currently I'm using the Individual ID to track pictures, though I realized there's a risk of theoretically a moved-out ID could be reused on a move-in. I think rather, I'm going to suggest using an MLS custom field, or have a separate spreadsheet lookup. I might do that anyway to track website picture id's.

Here's the python code I currently have, this reads directly from the MLS exported CSV's and makes an XML file that's also purged of any ordinance data. For new move-ins without an Individual ID (externally appended from the weekly photo index) the Individual ID element in the XML file is populated with the camera image file name.
And the corresponding .XSL data to render the photo lists, currently configured for 4x across whiteboard-ready printing (see comments for 8x thumbnail pages)

mogura wrote:Currently I'm using the Individual ID to track pictures, though I realized there's a risk of theoretically a moved-out ID could be reused on a move-in.

From the many challenges you face in this project, you can eliminate that one. The Indiv ID field is not reused if a member moves out. Such keys are simply retired.

An alternative to installing software, is to use
a LiveCD such as Knoppix that already contains
the software you need, such as ImageMagick
or Python.

A flash drive can also be used for your data.

Because nothing is installed on the computer,
you don't need to go asking for permission.

- Atticus

Another alternative is to work with what's already on the computer. That will help when the computer gets restored or replaced. You might try working with Picasa™ or PhotoFiltre. If OpenOffice is installed, you might checking to see if Python scripting is already there.

All programs listed can be downloaded from mls.lds.org, so one would assume they are pre-approved.

mogura wrote:Here's the python code I currently have, this reads directly from the MLS exported CSV's and makes an XML file that's also purged of any ordinance data. ...

I suspect that the problem your Python script is having reading HomeTeaching.csv (as well as VisitingTeaching.csv and Organization.csv) is because your csv.reader statements lack some parameter such as quoting=csv.QUOTE_ALL, or some variation. The MLS export csv files put quote marks around every field, regardless of content.

That may not be the case when you are reading the file named Membership-purged.csv, which by its name I assume to be already edited by you or the clerks. If it was edited and saved by a spreadsheet, that would have altered the quote formatting of the file to be more like the format Python seems to prefer by default.

The logic of matching the HT and VT files to the membership file only by Preferred Name is a little iffy. The Church developers did not favor us with any unique IDs in that file for reliable joining of these files. It would be more nearly reliable to match not just by name, but also by phone, address and email.

BTW, although your HT logic would probably work in your YSA-only ward, it would fail in a family ward, where the Household name field is constructed not only from the head-of-household's name, but also the spouse.

Overall, I think, the narrow task of creating picture-formatted reports is not the biggest challenge of this project. It could be accomplished in any one of several scripting or application languages, including those already installed on the administrative PC in the clerk's office.

The larger problem seems to be one of managing the overall process of tracking these pictures, including the ambitious requirement to track members both before and after they are entered into MLS. If you also are planning to manage the process of uploading each of those pictures to the website -- which lacks any decent integration with MLS -- that opens up a whole different layer of activity to be performed by the website administrator. (Is that you?) No doubt you, as the developer, could handle all that if you are also the user for each of these processes. Are you planning to create and document a GUI covering them all so that you can hand it off to end users after you depart?

Greggo wrote:When I was creating a ward directory several years ago, I remember reading a policy in the church handbook (no access to one now, so I can't give the page no.) that publications should not include individual's birthdays (even with the birth year deleted) without their permission. But I've never heard of anyone not giving permission when asked.

That reference is CHI, book 1, 2006, p 151. You are close in that membership directories should only include names, addresses, and telephone numbers. Members must give permission to include e-mail addresses (To me this has been given if publicly available in the LUWS). Only authorized stake and ward leaders may be given lists that include age.

jdlessley wrote:That reference is CHI, book 1, 2006, p 151. You are close in that membership directories should only include names, addresses, and telephone numbers. Members must give permission to include e-mail addresses (To me this has been given if publicly available in the LUWS). Only authorized stake and ward leaders may be given lists that include age.

The statement I was attempting to reference must be outdated, as it was before 2006 (I'm sure the previous version did not mention anything about e-mail addresses). I didn't know we had an updated CHI.

It occurs to me that along with the photo of each new member not yet in MLS, your process needs to capture the full name (spelled and formatted exactly right!) and DOB. Those are the two key data elements the clerks will use to request the member's record.

Then, when the record comes in to MLS a few days later, those same data elements can be used to associate the temporary record and picture with the actual MLS record and Indiv ID. Then there is a task to maintain this temporary table, including some rule to purge the temporary roster of folks whose records never show up for some reason.

You really need an application with a proper interface for an end user to handle all this. The more I think about it, the more I think that user should be an assistant ward clerk. These steps parallel the steps that membership clerks already perform, both online and on paper, and the clerks are already cleared to deal with any confidential information.

That does not even touch the other process downstream -- keeping the website updated with photos. (Whose job is that in your ward?) BTW, when taking the photo in the first place, it is important to secure the subject's permission to post it on the web site or print it in a general directory. (Some members might even exercise their right to be excluded from the directory entirely.) If you use the LUWS directory as the source of a general-membership directory, that detail has to be resolved only once.

I just wanted to clarify that this does not in anyway replace or augment the membership records process, rather it is a mechanism to visualize records recieved, and records anticipated with the primary objective of reinforcing names-to-faces in a high turnover unit.

There is already an established process in place for collecting member's information for processing by the membership clerk.

What I'm trying to do right now - while waiting on the next iteration of data (hooray for last minute multi-month overseas business trips) is figure out what the policies and protocols are. As you you will be able to see from my present process explanation below, it's a bit confusing for me.

In my ward, as is standard, the clerks are responsible for clerks stuff which you all no doubt are far more familiar with than I am, as I'm not currently nor have ever been a church clerk.

The communications committee has been responsible for ward website and electronic communications maintenance.

The welcoming (fellowshipping) committee, of which I'm a member again, is responsible for greeting the new members, collecting data and pictures, and distributing the member data to the clerks, bishopric, elder's quorum presidency, and relief society presidency.

So to to now the new members will gather in the Bishop's office for a group welcome/introduction, the welcoming committee will gather their information for the clerks and arrange followup visits, and someone with a camera from either the communications or welcoming committee will take the pictures, then transfer them to the communications committee to upload on the website.

Now in my fidgety mind I can see lots of room for improvement and efficencies, but this is the Lord's Work, not my day job so I'm not going to stick my nose in (yet) and rock the boat. The further complication is, as the counselor in the Bishopric described the calling, I'm a 'technical specialist assisting the welcoming committee', and my primary taskings are side-channeled direct to the Bishopric and Clerks and such, in addition to the regular fellowshipping of the general committee calling.

I spoke with the communications committee about who to work with for website uploading, and they were happy to delegate it back to me since I had been doing tech support for the individuals previously responsible for that.

The immediate complication is that because I'm out of town, I'm dependent on weekly data feeds from the clerks and committee members to generate new directories and photo lists. On my end though, the current situation is that with the MLS exports (cleaned of ordinance data), a spreadsheet in the MLS Membership export format for new members, and a folder of pictures, a single double-click batch file fires off a python script to mash them together. I then view the XML file via different XSL files in Firefox, and 'print' the results in CutePDF and email back to whoever's printing out the updates prior to the weekly Bishopric meeting.

I think this process is readily maintainable and transferable, all they need to do is install python to run the batch file, and request weekly spreadsheets. Imagemagick is only needed if you want to automate resizing pictures, extra time in mspaint can do the job as well.

I'm surveying committee members about processing the new member data in a spreadsheet, but we have to remind ourselves that not everyone views 'upgrades' as truely more efficent, and they may very well have a valid point.

mogura,

I have a somewhat better understanding of your ward's organization, but this is absolutely new to me because I've never been in a YSA ward. I also have never heard of a "welcoming committee" or a "communications committee." It does seem that those locally invented callings do, in fact, augment the work of the clerks, but I guess that is not for you or I to judge.

Just from an pure IT process point of view, I still don't understand:

1. Who names all those picture files, and in what application? Is it just purely manual?
2. In the case of photos for move-ins not yet in MLS, where is their name and other identifying info stored? Who does that, and in what application?
3. Who renames the photo files with the Indiv ID later when MLS creates a record?
4. Who manages the queue of temporary membership records so it doesn't duplicate the permanent membership records, and doesn't accumulate orphan records for those who never become official ward members? In what application do they do that?
5. Where does all the not-yet-in-MLS member data get merged with the MLS-driven member data when the reports are produced?

As I said before, printing the reports with photos seems to be the easy part of all this. Once the data is captured, its just a matter of executing some code, which could be written and executed in lots of different tools. The overall process of capturing and maintaining the data is the hard part.


Addendum: Okay. I finally get it now. The file name of each picture is the display name of the member, until there is an Indiv ID. So each week, the user looks for such filenames in the directory, looks them up in the membership file to see if there is a new record with an Indiv ID, then renames the file. The code to merge these members into the report just doesn't exist yet. Right?

here is a Ward Picture directory option available on the ward/stake website. You have to be an administrator in order to add pictures. Also be aware of the limit of 135 x 180 pixels in place for each picture.

I would personally like to see them change this to a filesize based limit or else something larger. It is almost IMPOSSIBLE to see a family of 5-10 people's faces at that size.

Also, I would suggest cropping down the picture and/or resizing it only the person's face due to the above limitation, otherwise the picture directory is almost useless as faces are indistinguishable.

Has this been working out for people? Our ward is about to begin a journey of getting everyone's picture taken, uploading the pictures to the ward website, and also creating a ward picture directory. I'm spending a lot of time reading through the forums for different options, and this one looked like an option to pursue.

Is this working okay? Is it easy to maintain/update? Does anyone have some example screenshots like http://ldscompactdir.sourceforge.net/screenshots.html ?

Thanks!

Like boomerbubba I would have significant concern if our unit wanted to implement a photo gallery of sorts. Construction can be a massive task, but maintenance is also significant.

I wouldn't see much value in such an undertaking. It may be good to ask what benefits are expected and how those benefits will be achieved and sustained. Ward talent listings have come and gone several times in the last 40 years of my poor memory, and though it was a "great idea" each time, it was only supported by a few leaders, which would lead to a prompt and rapid demise. Last I checked, MLS contains somewhat hidden fields capable of holding member talent information, which in our ward at least are blank. A very significant component of your unit leaders need to be fixed on long-term development, maintenance, and use of a new system in order for it to become a valuable tool.

I would vote no, unless you turn the responsibility over to the women's auxiliaries.

JJ

jpjonesxyz wrote:I would vote no, unless you turn the responsibility over to the women's auxiliaries.

I'm confused by this statement. What difference does it make which auxiliary produces a photo directory? Could you elaborate on what you meant by this?

nutterb wrote:I'm confused by this statement. What difference does it make which auxiliary produces a photo directory? Could you elaborate on what you meant by this?

Probably said in jest, eluding to a woman's ability to better follow through with a task of this nature?

mkmurray wrote:Probably said in jest, eluding to a woman's ability to better follow through with a task of this nature?

Sometimes I think the only flaw in the internet is its inability to consistently convey tone of voice. Thanks.