Ward and Branch Org Application help

[colbyj-p40]

After completing and assigning geo codes, this allowed for modeling of proposed new wards. Also allowed for comparison of current vs. proposed stats. However, it's tricky or confusing when it comes to knowing who the Active people are...
This comes in to play when filling out the ward and branch org application.
In the second section of the first page I need to input the proposed data, which I can using the info from the proposed models....all except the active numbers for Melch, prospective elders, YM, YW, children. The modeling data does not yield this.
How am I supposed to determine these new active numbers when I don't know who the "active" are from the current ward data?
I could dig into the weeds and contact each ward clerk to get the names of these members who are listed as "active," but I'd like to avoid this.
Is there another way?
thanks

[lajackson]

How am I supposed to determine these new active numbers when I don't know who the "active" are from the current ward data?

In our stake, the clerk fills out the forms as best he can and then prints a list of household names from the proposed statistics. The stake president and his counselors put check marks next to the names of the actives, and the stake president sometimes takes names to his priesthood interviews with the bishop(s).

The list with the check marks is then returned to the clerk, who adds up the numbers. Decidedly low tech, but it is the only way we know to do it.

[colbyj-p40]

thanks for your tips... yes, this could be interesting...

[RossEvans]

In our stake, the clerk fills out the forms as best he can and then prints a list of household names from the proposed statistics. The stake president and his counselors put check marks next to the names of the actives, and the stake president sometimes takes names to his priesthood interviews with the bishop(s).

The list with the check marks is then returned to the clerk, who adds up the numbers. Decidedly low tech, but it is the only way we know to do it.

Is there no place in stake MLS even to record this data element by rekeying duirng a boundary realignment?

So every time an alternate boundary proposal is run with new combinations of Geo Codes, and the other demographics are tabulated by MLS, the "active" component (and maybe some other elements) have to be recounted manually?

If not, it would seem better to export the data from MLS into some external application, capure the new data elements such as "active" there once, and accomplish the what-if demographic processing outside MLS.

[russellhltn]

Is there no place in stake MLS even to record this data element by rekeying duirng a boundary realignment?

You could use Custom Fields, but I'm not sure how useful the resulting reports would be.

[RossEvans]

You could use Custom Fields, but I'm not sure how useful the resulting reports would be.

I don't think it would be very useful because it would not be incorporated into the demographic analysis that stake MLS performs for the purpose of boundary proposals. It appears that stake MLS -- which doesn't really perform geographic boundary analysis at all, but rather demographic analysis -- doesn't even do a complete job of that.

One possible workaround is for the stake to define a simple custom report for ward clerks to run in ward MLS and transmit the results, which would include a key piece of data that stakes are missing: HTVT assignments. That could produce a list of priesthood holders or prospective Elders who lack callings, HTVT assignments, and current temple recommends. (Similar to the report discussed in this thread, except enhanced with confidential recommend data and the MRN key.) The stake already has all this data except the HTVT assignments.

Once all that data, and the stake MLS export data, are imported into some external program -- MS Access, OpenOffice Base, SQLite, etc., it would be quite feasible to create the queries for that proxy definition of active/less active.

An advantage of that approach is that it would produce an objective metric.

A disadvantage of that approach is also that it would produce an objective metric. (After all, even yeast can be "active.") A related weakness is that the metric depends on the quality of MLS data for callings and HTVT, which might vary across units. So enabling priesthood leaders to eyeball and correct the list is probably desirable.

But from a system point of view, the optimal solution is to capture that objective-or-subjective data once, then slice it to reflect various what-if boundary proposals.

[lajackson]

Is there no place in stake MLS even to record this data element by rekeying duirng a boundary realignment?

Well, no. Besides, the actual form used to make the request has not changed very much at all in the last 30 years, not even enough to line it up in a typewriter.

I think if I lived in a place where there were a lot of changes going on, I would work up a spreadsheet with all of the names in the stake and create an active/inactive column. Then, after printing out the boundary reports, I would run them against my master list to generate the numbers.

In the process of considering various forms of a boundary change, though, it is only necessary to have a general idea of the rate of activity. The actual numbers can wait until the decision is nearly made and the form is being filled out.

The stake presidency will usually be aware of those families who are active and will have a good enough feeling on whether or not the proposal will work without having the actual numbers. In most cases, they provide a sanity check after most of the preliminary decisions are made.

Others, of course, may have had a different experience.