Photo directories and fellowshipping roles

[atticusewig]

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

[russellhltn]

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.

[RossEvans]

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?

[jdlessley]

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.

[greggo]

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.

[RossEvans]

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.

[mogura-p40]

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.

[RossEvans]

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?

[atom88-p40]

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.

[coloradotechie-p40]

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!