In today’s tough economic times, we have been challenged by Church leaders to do more with less. Doing more with less does not mean that we need to spend longer hours at the office taking quality time away from our families to get the work done. Instead, it means we need to be smarter in how we work. We need to leverage available resources including the skills and abilities of Church members. The implementation of such a project is much more difficult than it sounds.

Before we could engage members on a project, we had to share several tools and refine processes. Our preparation included building a license agreement, creating a wiki, deploying a source version control tool, defining an issue-tracking program, setting up a “sandbox” server and ensuring data protection. Here are some of the specific tools and processes.

In today’s tough economic times, we have been challenged by Church leaders to do more with less. Doing more with less does not mean that we need to spend longer hours at the office taking quality time away from our families to get the work done. Instead, it means we need to be smarter in how we work. We need to leverage available resources including the skills and abilities of Church members. The implementation of such a project is much more difficult than it sounds.

Before we could engage members on a project, we had to share several tools and refine processes. Our preparation included building a license agreement, creating a wiki, deploying a source version control tool, defining an issue-tracking program, setting up a “sandbox” server and ensuring data protection. Here are some of the specific tools and processes.

Individual Contributors' License Agreement

A prerequisite for participation on any Church project is for individuals to review and agree to the Church’s Individual Contributor’s License Agreement. This agreement is meant to protect both the Church and the individual from legal action resulting from source code, artwork, or other contributions. To contribute, follow the steps outlined under the “Requirements for Participation” section on the Wiki home page.

We use a wiki to collaborate on specifications, design ideas, and functional requirements allowing us to create requirements documents and easily update them in an open forum.

Subversion – (example) https://dev.lds.org/svn/{project}

To access and collaborate on source code, we needed to deploy a source version control tool. There are many products available, but we have chosen Subversion. With Subversion, we can easily track source code changes, create tags for different versions, and create branches of projects. In addition to Subversion, we have built a custom administration module that allows us to create new Subversion repositories and maintain the permissions for various projects.

Once we have the project defined via the wiki, and a place to store source code, we need a tool that allows us to keep track of all of the tasks, bugs, and features of the software. The Church uses JIRA, an issue-tracking program, internally. A new instance was deployed that will allow us to track all of the issues and bugs around the various community projects.

Community Development Server – (example) http://tech.lds.org/{sandbox}

To test our software with the community, we needed to set up a server where we can deploy applications. This server, which we are calling the “sandbox” server, will host development builds and will automatically kick off builds of the projects so that developers and testers can see their work integrated with other people’s work.

Member and Leader Data APIs

It is very difficult to ask the community to help us build applications without providing access to membership or leadership data. However, because of privacy and security concerns, we cannot allow access to real membership data. We have, therefore, created some membership and leader application programming interfaces (APIs) that will access fictional member and leader data but will access real data when an application is deployed within our production environment. We have also created a tool that we call CODA (COmmunity DAta) that will allow the community to type in and create fictional data to help us maintain and update our sample data set.

Many of the projects we sponsor will require the use of the LDS Church Java Stack. The stack can be created using Maven and the Church’s Maven repository. This same stack code is used in many of the Church’s applications. You can read more about the Church’s Java Stack by visiting the LDSTech Wiki Java Stack page and the Stack Site.

We hope to streamline the process of engaging individuals engaged in helping us build more products. This will result in more products being built that will benefit members of the Church worldwide and will also help Church employees do more with less.