I like this discussion -- civil and yet in disagreement...cool.  

Dan Hanks made the following basic points (summarized):

> 1) parents can update what their kids have done 

This is not applicable to Boy Scouts, btw.  Only Scoutmasters do this --
with 1 or 2 merit badge exceptions.

> 2) leaders add their okay

> 3) parents oversee what the scouts are doing

> 4) Bishops can oversee progress 

> 5) everyone involved on the same page

> 6) lax keeping correlated with having to deal with "pencil and paper" 

Most that I see using the computer write things down on paper and then
transfer them to the computer.  It's still a second step that most don't get
around to taking.  Any current or former Ward Clerks out there will know
what I mean.

Shane Hathaway made the suggestion of using strong encryption for a locally
stored database and then using the central server to archive (for disaster
recovery or whatever) that encrypted database, but *not* the key.  Excellent
suggestion -- that would resolve my concerns.

Charles Fry brought up the point of unwieldy key management.  Years ago, I
filed some patents that address that problem (US Patent #:  6,831,982 and
7,024,395).

Justin Findlay asked "Why should any of this be bigger than troop level?"
That's a good question that gets back to requirements.  Other than for
disaster recovery, scouts moving to a new troop, or a new scoutmaster, why
should any of this be on any computer other than the ward computer or the
scoutmaster's computer?  Despite my privacy concerns, I don't see a
substantial requirement justifying the effort and expense of running a
central server.  Disaster recovery could be done by creating a church-wide
centralized backup server.  Parents can talk to the scouts and scoutmaster.
What really justifies a web application allowing read / write access to a
centralized database for which users and administrators will be blocked from
accessing 99% of the content?  Is there a church leadership access
requirement other than basic reporting statistics that gets down to this
level?

Thomas Haws mentioned, "Nobody above the troop level is interested in the
records, but centralized storage relieves a burden from the family and the
Troop Committee."  

These were some of the comments that got my attention on this thread.  

>From this, it seems that a couple of things are generally desired:

1) centralized storage for disaster recovery purposes

2) ability to transfer records from one keeper to the next

3) ability to transfer records to new units

4) ability to allow the Bishop or parents to see progress

5) desire for something lower cost than TroopMaster.

6) goal of free and open source

Other than posters saying that 'a web data application' would be 'really
useful', these are the points that I've observed.  Even excluding privacy
concerns, I'm not really seeing the requirement / justification for a
centralized web-accessible system.

Given that, I propose two things:

1) the OSS community builds a free open source scout tracking application
that runs on a stand-alone computer, that incorporates a good import/export
function, that integrates with Excel or other office products, etc.  Windows
is the most common platform, but cross-platform portability should be
addressed from the start.  Something like Java Web Start could even be used
to download an encrypted database and launch the client-side app.

2) that someone petition the church to enact a centralized backup / disaster
recovery server for archiving church databases such as the troop database.
Secure access and encryption for everything but the crypto keys could be
archived here.

I make this proposal, since this is something that the OSS community could
achieve without oversight or authorization from the Church (which could take
a while).  The privacy issues are also minimized, since no data is being
stored on web sites.

Does this scaled down version of what's been discussed sound interesting?

Steve


_______________________________________________
Ldsoss mailing list
Ldsoss@lists.ldsoss.org
http://lists.ldsoss.org/mailman/listinfo/ldsoss

Reply via email to