Page 1 of 1

How to work with the rules when the rules are seemingly stacked against you?

Posted: Sat Jan 09, 2010 10:39 am
by hiltonc
boomerbubba wrote:The issues raised about the practical problems posed for third-party developers are more than interesting, they are very important. But I think that really deserves its own thread.
Speaking of practical problems, here's one that I'm facing. I'm a developer of software that must interface with LUWS. Yet on occasion (and such occasions are much fewer and farther than between than a particular remark on this forum would suggest :rolleyes:) my software may not handle a particular edge-case very well. The easiest way to solve such a problem, particularly with non-technical users, is to debug it under the user's account. The LDS Account Conditions of Use, however, state that "You may not share your LDS Account password with anyone." That puts me (and others who are similarly careful to comply with policy) in a tight spot.

Any recommendations on how to successfully navigate this area?

Posted: Sat Jan 09, 2010 11:33 am
by russellhltn
hiltonc wrote:Any recommendations on how to successfully navigate this area?
My suggestion would be to create a error reporting feature that can enable the user to save the page in a "raw" format that you can then use to debug your software.

Posted: Sat Jan 09, 2010 12:00 pm
by hiltonc
RussellHltn wrote:My suggestion would be to create a error reporting feature that can enable the user to save the page in a "raw" format that you can then use to debug your software.
Great idea! We then bump up against this, though, from the Rights and Use on LUWS: "You may not post material from this site on another web site or on a computer network without our permission. You may not transmit or distribute material from this site to other sites."

Perhaps getting permission from the Church would satisfy this requirement?

Posted: Sat Jan 09, 2010 12:04 pm
by RossEvans
I don't have a solution to offer for that particular problem. But I can easily list several other problems. The boundary layer between Church developers and third-party developers is a target-rich environment for constructive criticism and ideas. I see:
  • A lack of official documention for export files from MLS, which have design flaws begin with. That is compounded by changes that make developers' tasks more difficult rather than easier.
  • A lack of good test data for MLS or non-confidential test accounts that might be used to log into LUWS.
  • A lack of APIs, either for the public or for registered developers. (There is no such thing as a registered developer outside of the church's own projects.)
  • Policies that are difficult to interpret in good faith because they are ambiguous, incomplete or out of date. When there is a need for interpretation by CHQ, there is no organized mechanism for publishing such guidance to the community. (This forum is probably the closest thing there is to such a venue.)
  • A level of secrecy about long-term roadmaps and impending releases that seems unnecessary in this environment, and no up-front mechanism for regulating disclosure to third-party developers when secrecy is more generally necessary.
  • Insufficient outreach for consultation to learn what potential partners needs' are.
There has been good progress recently, I think, on establishing "community" projects that the church tightly controls on its own systems. But that is not the same thing as partnering with third-party developers who build innovative tools themselves for use by members and local leaders.

Overall, most people involved seem to recognize that there is a need for the work product of third-party developers -- including amateur local clerks and leaders, free and open-source projects, and popular commercial ventures. But I think this space needs to be better professionalized.

Coincidentally, I happened to spend a few hours recently viewing videos from recent outside developers' conferences sponsored by Google. The synergy was palpable, even without being there in person. The Church could do well to emulate some practices from such players.

Posted: Sat Jan 09, 2010 12:14 pm
by russellhltn
hiltonc wrote:"You may not post material from this site on another web site or on a computer network without our permission. You may not transmit or distribute material from this site to other sites."
I guess it's all in interpretation. I don't see a prohibition on emailing to an individual. What you want is a sample for your own troubleshooting. The user is not re-publishing it to another group.

Posted: Sat Jan 09, 2010 12:44 pm
by hiltonc
RussellHltn wrote:I guess it's all in interpretation. I don't see a prohibition on emailing to an individual. What you want is a sample for your own troubleshooting. The user is not re-publishing it to another group.
Oh, that's a great point. I had assumed a different sending mechanism. Thanks for your help, I really couldn't see any practical way out of the dilemma.

Posted: Sat Jan 09, 2010 1:01 pm
by RossEvans
hiltonc wrote:Oh, that's a great point. I had assumed a different sending mechanism. Thanks for your help, I really couldn't see any practical way out of the dilemma.

Good to see a solution there.

If you were supporting a different product that happened to be based on MLS data rather than LUWS data, you might still be in a bind because the data content itself is more sensitive, containing confidential data elements.

I have seen such constraints isolating and troubleshooting in the wild, where the problem is suspected of being data-driven. For example, see this thread. The end-users could not just share their files with the developers.

The underlying problem there was that no one could know with certainty what the MLS-generated data file was supposed to contain because it is not documented. So whether that was an MLS bug or a feature was a mystery.

Developer's conference?

Posted: Sat Jan 09, 2010 4:42 pm
by RossEvans
BTW, I recall a poll measuring interest in a possible developers' conference in April. Has there been any news about that?

As I recall, the suggested topics did not cover most of what is discussed above for third-party developers, except for one session about APIs. I am particularly interested in roadmaps and transition paths because, from the distant noises I hear from the dark forest, I am guessing that some significant changes may be coming soon.

Posted: Sat Jan 09, 2010 5:29 pm
by hiltonc
boomerbubba wrote:If you were supporting a different product that happened to be based on MLS data rather than LUWS data, you might still be in a bind because the data content itself is more sensitive, containing confidential data elements.
I'm counting my lucky stars right now. Debugging blindfolded is not an easy task.