HT/VT Web Site

[WelchTC]

The [thread=502]HT/VT Website Overview thread[/thread] has started some discussions at the Church about how could utilize the community to build this type of application officially for the Church. Here are some of the challenges that we face and we would appreciate any feedback you as the community could give us in order to decide if this is a project that we can properly control and outsource to the community.

1. How do we securely integrate this into internal systems here at the Church that are currently under development without exposing sensitive and critical data to the community. If we provide API's or other Web services to integrate into these systems, do we expose the Church and the privacy of the data to people wanting to use those API's for non-approved purposes?
2. How do we maintain quality of the code that is being submitted.
3. How do we prevent code from being submitted and accepted that has "back doors" into confidential data.
4. How do we best "beta test" such software?
5. Should we open this application up to anyone who would like to contribute?
6. What roles should the community play? (Development, Documentation, User Interaction, QA, Project Management, others I'm missing). How would we handle these roles. It is easy to say "all of these" but how would we do that? How do we have a community project manage the app, for example?
7. What should we be concerned with that I've not mentioned?

Many features have already been discussed. I'd like to post some of the basic objectives we would need to accomplish and open this thread up to other objectives and features not previously mentioned in the other thread. Remember, we are in exploratory mode. We are not committing to open this project up to the community but are simply exploring if it is feasible as well as getting great ideas from the community.

1. Assign responsibility to priesthood bearers and sisters for particular individuals and families.
2. Report on activities (visiting, calling, writing...) by those assigned responsibility to watch over another.
3. Make confidential comments visible only to Bishops/Branch Presidents.
4. Produce reports including: who is assigned to who, who is not assigned a responsibility to watch over another, who has no one assigned to watch over them, summary of activities by the assigned and by those watched over.
5. All this must be available via the web.

Let us know what you think.

Tom

[rmrichesjr]

I think it's a great idea to be considering outsourcing something like this to the community. You asked for thoughts/ideas, so here are a few:

To be able to securely integrate this with internal systems, the security aspects of the high-level design should probably be done in-house, with reviews as appropriate to ensure adequate protection mechanisms are built in from the foundation up.

For code quality and assurance against back doors and such, one approach would be to assign a small number of Church-employed developers to be part of the team, to be involved in and to some extent oversee design, coding, reviews, etc. Code review by a combination of internal Church employees and the rest of the community team would seem to be a good approach for both effectiveness and efficiency.

On whether to open the project up to everyone, perhaps one model to consider would be something like what is used for early morming seminary teachers. An interview by the prospective developers' eccliastical leaders would provide a fairly good screen against someone who would want to insert back doors or other problems. At least when I taught early morning seminary, CES paid the teachers a small stipend, reportedly mostly for the purpose of enabling CES to fire the teacher if they wanted to.

Another thing to look into is whether the employers of volunteer developers claim copyright on anything the developer writes. The employement agreement with my former employer included a clause that gave the employer ownership of the copyright on anything the employee wrote, even off hours, developed entirely without any use of company resources, etc., for anything that was related to the company's business. I understand some open source processes require developers to affirm that their employer disclaims ownership of copyright on what the developer will be submitting.

[russellhltn]

One thought might be to have the church do the API and the community do the UI. The UI never gets access to data that the user isn't permitted to see. That would solve a number of problems and lifts a fair-sized burden from the church developers.

For testing, MLS has a demo ward/stake. Perhaps that can be extended to LUWS?

[WelchTC]

Great comments...keep them coming.

Tom

[HaleDN]

I would assume that using the new LDS Account to authenticate / authorize users for a specific church unit would help alleviate much of the security concerns, as long as the secure data access is done via web services which validate that the user has logged in. The only data which you could retrieve would be for the unit that you already have access to via LUWS. (So yes, there is still a privacy concern, but not significantly more than what has already been exposed)

If this assumption is valid, then other non-employee developers can still work on the site (except for those portions which requires direct access to the full data).

[HaleDN]

As far as verifying the quality of the code and ensuring that no security holes are introduced... I think that we can follow the model that many other open source applications have utilized. As long as enough people are actively working on the project, you will be able to quickly identify bugs and keep the quality up.

You would only have a few trusted individuals who are "committers" on the project. It is their responsibility to review any code submissions, ensure standards are met, and test are written before their changes are merged into the main part of the code base... otherwise the changes are rejected. This ensures that only small, incremental changes are made by "unknown" contributors and larger, global changes can really only be made by committers. Individuals who gain a reputation for good, quality code can be upgraded to a committer role, while those who have questionable contributions can be demoted so that all submissions are scrutinized more closely.

[russellhltn]

As for testing - expanding on my idea of the test ward/stake, how about test membership record numbers and test logins to LUWS? The logins can be shared among testers allowing multiple people to test the different roles. Done right I think we can run the test on a live system without messing up the real data. We just have to be careful about move-in and move-outs that they don't go to real units.

Then again, how does the church test their back-ends? Do they have a membership system testbed?

Oh, and those test units: Ward Unit #108, Stake Unit #2224445.

[brado426]

What about creating test Web Services that are somehow made available only to developers via the Internet (perhaps anyone that has an account with a custom access level on this message board?) The Web Services contain fake test data, but are otherwise identical to the Web Services that are used internally by Church systems. Perhaps a website could be created that displayed committed data (for testing purposes).

This way, applications could be developed and tested outside of the Church infrastructure, but would, in theory, function properly once they were brought internally and pointed to the internal Web Services.

Brad O.

[JamesAnderson]

I have an idea or two as well.

There could be three open test periods once the development is close to release.

1. Final alpha: At Church headquarters, using Church employees and department volunteers.

2. First beta: Outside (this community) developers.

3. Second beta: Outside: This community and actual priesthood leaders and others who might wish to communicate with computer skills to simulate what happens when new people are called and have to interact with the system, typically for the first time or after some time with new updates. An update to the code should be done during the beta to similate how to debug on the fly for actual users who encounter problems using the system.

In all three cases several things would be happening: The test units would have move-ins and move-outs and leadership changes and that last one would be accelerated more than you would have in a normal ward or stake. Maybe people in the community could play the role of the 'leaders' that are called and released, as some of those here like myself are serving in various leadership positions that relate to all of this. Even that could help make the final product ready for prime time.

Any thoughts?.

[mkmurray]

By the way, Tom, this is really exciting news!

How do we securely integrate this into internal systems here at the Church that are currently under development without exposing sensitive and critical data to the community. If we provide API's or other Web services to integrate into these systems, do we expose the Church and the privacy of the data to people wanting to use those API's for non-approved purposes?

I understand what you're asking, but yet I don't think I am grasping all of the concerns...Are you speaking about security vunerabilities of the data itself, exposure of internal Church systems, or maybe both? If it's the data, what type of data might be passing through the app of a secure nature? If Church systems, are we talking solely about databases, or does it go further than that? If I can get a better idea of the concerns here, I might have some decent comments to contribute...Thanks.

What roles should the community play? (Development, Documentation, User Interaction, QA, Project Management, others I'm missing). How would we handle these roles. It is easy to say "all of these" but how would we do that? How do we have a community project manage the app, for example?

Ya know, I think "all of these" might be the right answer though (perhaps with the exception of "Project Management," that might be best left to Church employees). But I really do think we have a diverse enough crowd here to merit such diversity in community roles. Everyone here knows there strengths, time constraints, preferences, etc. There are some here that just love to develop no matter what it is; others may love to try and find the bugs in the system and even have access to automated tools to facilitate QA; I have even seen a few posts on the forum of those who love to help improve the documentation. Perhaps we open the choice of roles to the user, allowing each volunteer to take on up to 2 or 3 roles. Another option would be to have some questionare describing skill sets and experiences, and allow Church employees to assign roles as deemed appropriate (I have a feeling it might get weighted heavily toward the "Developer" role, and it may take some encouraging from Church employees to get some to take on some other roles).

One thing I would like to say is that I really appreciate what the newly created User Interaction team at the Church has done with the updated look-and-feel of all Church sites. I think some cooperation and/or guidance from that team would be terrific. I really like what brado426 has done so far, and I think it would be neat to have it fit right in with the look of other Church sites.