search

SuffolkLITLab / docassemble-AssemblyLine

Quickly go from a paper court form to a runnable, guided, step-by-step web application powered by Docassemble. Swap out branding and pre-built questions to meet your needs.
https://suffolklitlab.org/docassemble-AssemblyLine-documentation/
MIT License
42 stars 5 forks source link

Cleanup use of the `user_role`, `user_ask_role`, `user_started_case`, `typical role`, `user_detailed_role` and possibly other signals #181

Open nonprofittechy opened 3 years ago

nonprofittechy commented 3 years ago

Problem statement

figure out how to represent information about both whether this is a pleading that starts a case or is continuing a case; whether the party is the person who initiated the case; and the specific name of their role in the case. (Role meaning which side of the "v" in the case caption they are on and the name of that side of the "v" in the particular case).

There are four possible names for roles in the case caption:

There are also "in re" or "in the matter of" cases, usually involving juveniles, where the case is about the named person's interest but formally nobody is suing anyone and a litigant is not petitioning the court for anything.

Most forms ONLY care if the user started the case or is responding to a case someone else started. In some forms, the "starter" is called Plaintiff, and others it is called "Petitioner" and the person responding is called "Defendant" or "Respondent." But the interview does not need to distinguish. It is enough to set the value of both "plaintiffs" and "petitioners" and let the author use the one that is appropriate for the case. That is our current practice.

A small subset of forms are general purpose and are filed in existing cases that can be of either the "petitioner/respondent" or "plaintiff/defendant" variety and the interview author does not know in advance. An even smaller subset require the end-user of the form to identify specifically whether they are one of "petitioner", "plaintiff", "respondent", or "defendant". We want to be able to ask a question that gets to that very specific role for the small number of forms that need it, but we do not want to force end users to get so specific if it's not necessary for the form. They are likely to lack the context to be able to answer the specific choice among those 4 possibilities. We should only force the choice on them when there is no better option.

Goal

Use a minimum number of clear variable names.

What is going on now

We have several variables that appear as though they might overlap. We want to enable interview authors to make forms of the appropriate level of detail for their needs but also that require the fewest clicks/customization to do so that is feasible.

Possible scope

  1. Identify every place each of these variables are used. In the Weaver, in the AssemblyLine repo, and in existing interviews.
  2. Identify the purpose behind each use.
  3. Figure out if any of the uses could be functionally combined.
  4. Identify needs that are not met by the current usage.
  5. Identify the risk and benefits of changing existing code and figure out the most appropriate solution.

Existing variables (more info to be gathered, w/ line numbers)

user_role

expected to be exactly "plaintiff", "defendant", or "unknown".

~Used to define that value of the ALPeopleLists plaintiffs, defendants, petitioners and respondents to either users or other_parties~

Seems to only be used as a suggested template variable, i.e. not used in interview logic.

user_ask_role

Used to set the value of user_role to plaintiff or defendant

user_detailed_role

This is a new, currently unused question. It is a model question for forms that need the detailed role but not used in them yet. As an example: https://github.com/SuffolkLITLab/docassemble-Interpreternotice.

It can safely be changed without breaking any existing code.

user_started_case

This was one attempted fix of user_role in order to make it possible to meaningfully ask the "which court?" question. It is not set in the Weaver. It has 8 line references in the ql_baseline.yml file.

Used to define that value of the ALPeopleLists plaintiffs, defendants, petitioners and respondents to either users or other_parties

It is inferred from: al_form_type and also the value of ~user_role~ user_ask_role if al_form_type is not enough information.

typical role (key in interview_metadata['form_name'])

This is referenced in the runtime code, but it is a fallback that is never reached from a newly weaved form. It looks safe to remove completely. We may need to add some documentation for people who are converting MAVC forms to AssemblyLine.

In theory, having this in the metadata could allow you to use an umbrella interview that interacted with some initiating and some responding forms safely, but we do not rely on this in existing code.

The concept of "typical role" didn't seem to map on to most of our forms. It wasn't helpful to know if the user was usually the Plaintiff or Defendant. If we want to keep this in the metadata block to ease umbrella interviews, we could just rename it to user_role so it doesn't look like it has a different purpose.

al_form_type

This is worth mentioning here because if the form starts a case, we know the user's role is either Plaintiff or Petitioner. We may not need to ask any follow-up questions.

Brainstorming solutions

nonprofittechy commented 3 years ago

See also

nonprofittechy commented 3 years ago

One thing to determine: is user_role needed on any forms that do not display the name of a court?

nonprofittechy commented 3 years ago

There is also a confusing, but not really related issue: some forms need to track whether the person filling in the form is the person who is a party in the case or their attorney/advocate/helper. Usually this is only important to make questions more responsive and does not impact the final form. That is not in this scope.

purplesky2016 commented 3 years ago

I created a graph to summarize the situation as I understand it, but it may not be accurate, so please feel free to make corrections. Hopefully it will help us better visualize the scenarios.

https://docs.google.com/drawings/d/1_nlMBzjHV_3blTzzeVkLjOeBNw3upa7luN8MluqG460/edit