Page 1 of 1

Lack of stake access

Posted: Fri Jul 27, 2012 8:51 pm
by johnshaw
Utterly disappointed by the lack of access to this solution by the stake. We sent a message today to all our units, something we do each Friday. I included a note about the live status of the newsletter. A Bishop called and wanted help with a post he was working on, without access I was unable to help. He was frustrated, and likely we lost the only chance of adopting that solution.

What do i tell him, call the GSC?

Posted: Fri Jul 27, 2012 11:27 pm
by aebrown
JohnShaw wrote:Utterly disappointed by the lack of access to this solution by the stake. We sent a message today to all our units, something we do each Friday. I included a note about the live status of the newsletter. A Bishop called and wanted help with a post he was working on, without access I was unable to help. He was frustrated, and likely we lost the only chance of adopting that solution.

What do i tell him, call the GSC?
The Church can either wait to deliver tools until they are fully perfected, or give them to us when they are quite useful, but still need more work. I personally agree with the philosophy of getting useful tools into our hands sooner rather than later. That gives the development team a chance to incorporate real-world feedback into the next phase of their development, which is a good thing.

The GSC has nothing to do with the development plans, so there's no point in telling him to call them. In the case of the newsletter, I would hope that there are people at the ward level (clerks, executive secretary, website administrator) who have the technical competence to help a bishop -- and they have full administrative access to the ward's Newsletter. I would suggest that one of them could help.

Posted: Sat Jul 28, 2012 1:45 pm
by russellhltn
JohnShaw wrote:A Bishop called and wanted help with a post he was working on, without access I was unable to help.

Without the ability to share his screen, your ability to help may have been quite limited.

Stake DO have the ability to create stake newsletters, so if that wasn't enough then access to the ward newsletter may not have helped.

I suggest you look into one of the free screen-sharing applications. Just make sure both computers are personally owned to comply with any licensing.

Posted: Sat Jul 28, 2012 3:36 pm
by johnshaw
There needs to be a better alignment with ICS design and ward/stake organization. The only policy I've seen about technology responsibility in a stake or a ward is role for the STS. We had a previous thread about the Clerk being the CTO in a ward, in that thread I was trying to figure out whether a ward clerk should assume a technology responsibility like the stake clerk does, the overwhelming response was that responsibility did NOT reside there, but in the STS - I am just really confused.

Posted: Sat Jul 28, 2012 4:22 pm
by jdlessley
JohnShaw wrote:There needs to be a better alignment with ICS design and ward/stake organization.
As far as I can tell they are aligned. The Hanbook states that the stake clerk and assistant clerks are responsible for training unit clerks and assistant clerks. The STS is an assistant stake clerk. He should be training the unit clerks and assistant clerks on the use of equipment and applications.

While the STS is the primary agent at the stake for technology within the stake, he does not have to be the only person that every member of the stake goes to to learn how to use technology. The principle here is that he trains people in the wards. In our ward he would train the clerks and ward website administrator who use most of the technology and are also ward default administrators for online applications using ward administrators. These clerks and website administrator ensure the other ward administrators are trained and familiar with their responsibilities. Ward members then go to the trained clerks and website administrator for questions and issues. Any questions and issues they cannot adequately respond to are directed to the STS or the clerks go online to the forums and wiki.

Having been an STS I viewed my responsibilities as managing the hardware and software and provided input to the stake president for policies. I trained unit representatives to be their unit point of contact for technology and technology training.