Re: [lp] re: Groups - Litigant Portal Data Standardization ver. 3.docx u

Subject: Re: [lp] re: Groups - Litigant Portal Data Standardization ver. 3.docx uploaded

Thanks for the call today.

Just to follow up -

First, i just saw this writeup of best practices in standardization that speaks (with much more experience than I have) to the issue of designing new features vs establishing agreement on what already exists. Excerpted here:

Itâs important to separate design from standards making. Design is the process of trying to address a problem with a new feature. Standardisation is the process of documenting consensus.

The process of feature design is a messy, exciting exploration embarked upon from a place of trust and hope. It requires folks who have problems (web developers) and the people who can solve them (browser engineers) to have wide-ranging conversations. Deep exploration of the potential solution space â discarding dozens of ideas along the way â is essential. A lot of the work is just getting to agreement on a problem statement. This is not what formal standards processes do.

... Clear problem statements and potential solutions must already be proposed and partially agreed, putting formal standards late in the design process when done correctly. ...

They canât tell you if a design solves an important problem or even if it solves it well. SDOs are set up to pass judgement on the form of a specification and consensus surrounding the specific words in spec documents. Working Groups and SDOs are not fitness functions for features.

Second, Chet, thanks for your response, those approaches do seem promising!

~greg

On Mon, Jul 2, 2018 at 6:04 PM Chet Ensign <chet.ensign@oasis-open.org> wrote:

Hi Greg & LP TC members,Â

Greg, just on your last point ->ÂIII) It's really hard to do this kind of collaborative work with a bunch of word documents. Ideally the documentation would live at a fixed URL with commenting and version control to be able to track discussions over time.Â

If you all would like to take a different approach, the CTI and OpenC2 TCs have been having success working with Google Docs. I would be happy to give you info on how they are making it work. Another alternative is that some TCs are using SVN or GitHub and HTML or Markdown to manage their text. Also, TCs are integrating issue management - either via JIRA or via GitHub issues - to tie commenting and record keeping with the edits to the text itself so that they keep an effective change history.Â

I'm happy to help you consider the alternatives if you are interested.Â

Best regards,Â

/chet

On Mon, Jul 2, 2018 at 4:38 PM, Greg Bloom <bloom@openreferral.org> wrote:
Hi folks -

I'll begin this long message by apologizing in advance if I've missed some key things somewhere; I may have simply misunderstood the nature of this process or missed some of the key conversations, or perhaps i'm misreading the documentation! All of these seem like plausible reasons as to why I'm so confused.

But: if in fact I do understand the situation, and i am reading this document correctly, then i have a range of concerns worth sharing in advance of the call tomorrow. Here goes:

I) *Is this a data specification?*

On just a conceptual level, this document doesn't reflect what i would expect to see in a 'data standard.' I'm not a technical person, so i could be wrong here! But it reads more like a list of functional specifications for a specific piece of software, rather than a set of data specifications for exchange of data between different kinds of software.

(For the latter, I would expect fieldnames, format types, indication of required v optional fields, perhaps a logical model, etc; perhaps this content was shared in the UML package, but i believe that requires specialized software and skills to use, so if this content exists I wonder if it could be made available in a more accessible format?)

II) *What assumptions have been made, and why, about how legal aid providers (and other 'solution' providers) work?*

By way of the Open Referral initiative [https://docs.openreferral.org] this is the only area that i have any particular insight into âÂand from what I can tell, the document does not reflect reality.

IIa) The document asserts that a standardized set of categories of services has been established by Open Referral âÂthis is not true. We have intentionally *not* tried to standardize a set of categories of services and/or people. In part, this is because there are multiple competing taxonomies that already exist; also, it seems like a problem that can't be solved with a 'standard.' (During our Denver meeting, I was afraid that I made this point too often and at too great a length, but this documentation seems to reflect the opposite of what I had tried to communicate.)

IIb) The document asserts "Provider may have different capacity for different legal issues and this data element will indicate availability as it relates to particular case types.Â This quantity will need to be maintained on a regular basis by the Provider's system."

I could be misunderstanding the nature of the 'litigant portal' projects involved here, but as far as we have seen from our research in legal aid, 'provider capacity' is often not recorded in any digital format; there's often no incentive for providers to do the work of recording it (or, indeed, sometimes perverse incentives to obfuscate or misrepresent this information); and no institutional mechanism to compel participation. This seems to be a policy problem and/or a cultural problem, not a technical problem; I'm afraid that confusing the former for the latter is likely to lead to failure at best and harm at worst.

IIc) The one positive contribution that I feel confident that Open Referral can make to this effort is a modeling of types of information about legal aid orgs (and/or other social service orgs), the services they provide, and the location at which those services can be accessed... yet section 1B of the document seems to ignore the modeling we've done toward that end, and instead offers a set of information elements that seem overly simplistic ("Provider Description - Free text description from the Provider describing their services and other pertinent information." eh?) or random ("Provider Affiliations"?)

To reiterate: Open Referral has already modeled factual information about provider organizations and their services (and this model has been implemented by major legal aid tech vendors) and I hope to help you all apply that model here. We have NOT articulated a standardized set of categories of services, or categories of people, or capacities of providers âÂand have serious concerns about the effectiveness of any effort to do so. This document, however, seems to manifest the opposite of each of these points.

I can't comment on the rest, but i am worried, because all of this just applies to the first two pages of the specification. Plus all of my points above comprise pretty much the entirety of the points I already made while we were face-to-face in Denver.

Perhaps my confusion can be easily cleared up with some clarifications and pointers in the direction i should have been looking all along.

But that leads to my last point:

III) It's really hard to do this kind of collaborative work with a bunch of word documents. Ideally the documentation would live at a fixed URL with commenting and version control to be able to track discussions over time.

Like I said, perhaps there is a simple explanation that can address my confusion. Sorry in advance, if so. In any case, looking forward to the call tomorrow.

thanks,
~greg

--

/chetÂ
----------------

Looking forward toÂBorderless Cyber 2018,Â3-5 Oct, Washington, D.C.
Organized by The World Bank, OASIS, and Georgetown University

Chet Ensign
Chief Technical Community Steward
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Primary: +1 973-996-2298
Mobile: +1 201-341-1393Â

lp message