Right now it leads to the home page, but that seems confusing. Is there an official Code for Boston or Code for America page it could lead to?

The medical expenses fields need to be corrected. PR #71 was addressing this, but probably now conflicts with PR #77, so #71 is being retired until #77 is finished.

Should we or shouldn't we type check? Implicitly or explicitly? If we type check, what shall we use to do that? For example, Flow can do implicit or explicit type checking.

A 'Feedback' button seems like a good idea. I'm not sure if/how we want to handle our issue template to be more flexible so it can be for bugs and suggestions both.

Do we want it in the menu bar after the beta warning? Do we want it elsewhere? Also, do we want a survey after the 'Results' page to ask some guided questions about the user's experience? Maybe that should be in a different issue.

@lianilychee to sync w/ @carpeliam on particular license

(Not for MVP) Right now the result chart/graph's ticks are annual income amounts. Considering clients will probably be putting in weekly amounts, presumably because they're more familiar with them, it might be more useful to the client if we initially show the tick mark values as weekly amounts. We can probably find a way to allow the user to switch to monthly or yearly amounts too.

To reproduce:

Open the demo in a browser

• Hit "intake new client"
• Hit "submit"
• Hit "create visit"
• Hit "next" until on the "Household Size" screen
• Leave the default value 1 in 'Number of members in the household'
• Increase value of number of 'Number of dependents' and/or 'Number of children under 12'

Expected behavior

• 'Number of dependents' and/or 'number of children under 12' should be limited by number of household size, value should stay have 0

Actual behavior:

• values increase past actual house old value

Create this function. Return value might be percent state median income (as a decimal greater than 1?), but may be a bracket, depending on limitations of gov documentation data/requirements.

We should consider changing the type of graph to a "stacked area graph" that combines the client's income as well as all benefit programs.

see: http://www.datavizcatalogue.com/methods/stacked_area_graph.html

Create this function. Return value might be percent federal poverty level (as a decimal greater than 1?), but may be a bracket, depending on limitations of gov documentation data/requirements.

Regarding the right-sidebar results elements - the details seem to be not revealing themselves. This seems like it might be happening when the string is below a certain length. The details element is in the DOM, it just remains hidden.

Alec suggest this may be a problem with the React Semantic UI Reveal component, which is what he says that functionality is built from.

This answer is needed fairly urgently. I recall something about clients using tablets to fill out the form. Is that still the case? If so, what browsers will they have access to? If not Chrome, we'll need to really dig into making this compatible with other browsers. Also, do we need the page to be fluid? It could probably be used with a tablet in landscape modes for some sizes of tablets without cutting off part of the page. Not sure about portrait mode.

Replicate:

1. Go to 'Current Household Income' form page
2. Enter '200' into monthly earned income value
3. Go forward two steps to Future Household Income

Expected result:

• Monthly income value should be 200.

Actual Result:

• Monthly income value is 2.

Environment:

Chrome v61.0.3163.100
Commit: f64d563

Github told me this: 'Now, GitHub will help potential first-time contributors discover issues labeled with help wanted or good first issue'. That seems like a decent plan, especially since the issues we assign to 'beginner friendly' don't always fit that description.

Is this part of the MVP, or was it just for demoing making a page? If it is for the MVP, do all fields need to be represented? For example, all income fields? Etc.

Desired Outcome:

The longest line is center-justified, and everything else is justified to that.

Pages:

• Current Benefits
• Citizenship Status

Should we give different feedback for null, undefined, and NaN? If so, what kind? Should they cause different errors? See some discussion in #63.

It might be a good idea to let the client put in a custom benefit amount if they want so that if there are special circumstances around the benefit that we can't account for, there's a way for them to still get accurate results (some benefits can have an effect on the results of other benefits).

I'm not sure how it would translate to the chart at the end, but 1. there may be ways and 2. I think the benefit results are more important than the chart.

Context

Currently, we have exactly 5 tests. Of those, 2 pass and 2 fail, and 1 fails to run. As a basis for future tests to be written, we should first fix these tests if they are testing useful logic or remove them if they are not.

Goal

Fix or remove the 3 failing tests.

Images:

Result I'd Expect:

• Selected button would appear 'selected'

Actual Result:

• None of the buttons can be selected

Environment:

Operating system and version: 2008 macbook running Lubuntu 16.04
Browser type and version: Chromium, 62.0.3202.62 (Official Build)

App version or commit id at the time:

Other Notes

• Terminal warnings
  • Unused imports
  • Unused vars
  • Replace non-strict equality with strict equality
  • Misc
• Browser console warnings
  • Change from react-redirect to react-side-effect
  • Deprecated style setting format

Current apparent breakdown from this doc:

• Programs
  • Needed for MVP (don't currently know, but going to assume Standard is one)
    • 505.002: MassHealth Standard
    • (130 CMR 505.003 Reserved) (doesn't appear in doc, may not count anymore)
    • 505.004: MassHealth CommonHealth
    • 505.005: MassHealth Family Assistance
    • 505.006: MassHealth Limited
    • 505.007: MassHealth Senior Buy-In and Buy-In
    • 505.008: MassHealth CarePlus
    • 505.009: MassHealth Small Business Employee Premium Assistance
  • Qualifications
    • Pseudo Code
      • 505.002: MassHealth Standard
      • (130 CMR 505.003 Reserved) (doesn't appear in doc, may not count anymore)
      • 505.004: MassHealth CommonHealth
      • 505.005: MassHealth Family Assistance
      • 505.006: MassHealth Limited
      • 505.007: MassHealth Senior Buy-In and Buy-In
      • 505.008: MassHealth CarePlus
      • 505.009: MassHealth Small Business Employee Premium Assistance
    • Real Code
      • 505.002: MassHealth Standard
      • (130 CMR 505.003 Reserved) (doesn't appear in doc, may not count anymore)
      • 505.004: MassHealth CommonHealth
      • 505.005: MassHealth Family Assistance
      • 505.006: MassHealth Limited
      • 505.007: MassHealth Senior Buy-In and Buy-In
      • 505.008: MassHealth CarePlus
      • 505.009: MassHealth Small Business Employee Premium Assistance
  • Benefits for the same programs (currently we don't have a way to quantify benefits)
• Other data needed
  • Definition of a household As per our client's input, for now we're assuming whatever household the user references will count as a household for all programs
  • Income calculations (possible resource)

The current brainstorming doc I have going on (think this has too many details to work into a spreadsheet):
https://docs.google.com/document/d/1rVL9Wdr5GP_mYwQPuRXrRJOAPu4V3xcE7bFhI9KqYlI/edit#
It contains links to the above resources and more.

• Verify CALC of "% of Federal Poverty Level"
• Verify SOURCE of "% of Federal Poverty Level"
• Replace "% of State Median Income" with "Area Median Income"
• Switch phrasing of title from "% of Federal Poverty Level" -> "Federal Poverty Level Percentage". Do the same for State Med level.
• Add reference to source of calc. info, incl. year, as clear linked text right underneath associated %ages in comment in codebase

Since a form is blank when the user starts working with it, we have a ton of properties that are just undefined. We have to be able to handle that in our functions without throwing errors. I've found it much more useful to have a 0 instead of 'undefined' when calculating using form data.

So far, I've often solved that by adding || 0 to a bunch of stuff and, more recently, made a function that does basically the same thing, calling toCashflow( formValue ) everywhere. Neither of those are great solutions. You have to remember to do them each time. Changing them in each form script isn't ideal either for the same reason. The same for writing out all these properties to give them all an initial value.

Any thoughts for a more uniform and low-maintenance solution? Some process in our setters?

• Turn all instances of these to use the 'name' attribute instead, including the functions that use those attributes:
  • data-key
  • id

The TAFDC line is duplicated on the current income from in the client intake interview. The duplicate line should be removed.

The point of Result.js is unclear due to unnecessarily code
Should be using this keyword in a class function
Test functions outside of class are unnecessarily as they are testing hardcoded values

• Mod status bar to account for the added page
• Build the new page

STATUS BAR MOCKUP

NEW PAGE SPEC

The new page should go after the MassHealth Qualifying Conditions Page, and before the Results page. This allows the user to review/confirm inputs with the client, before jumping to the data viz.

• Don't forget commas for household annual income value
• Copy for MassHealth negative: "No qualifying conditions"

Self-explanatory.

After a discussion with our client, it looks like there's been a mix-up with time frames, so we need to switch those two up, both in the text of the forms and in the property names. It seems desired for the mvp.

• Switch form text
• Switch property names

Context

We've recently got some form of testing running. Let's automate it!

Goal

1. Select an appropriate continuous integration testing platform for this project.
2. Set it up w/ webhooks to our repo such that new pull requests trigger a run of our automated test suite.

If we require new code to include tests, then we can merge with high confidence that code works as expected. Even if we don't, we can at least be confident it doesn't break our existing code.

Context

A couple weeks ago, we set up Jest as our test-runner. Turns out, React-Scripts already used Jest under the hood. No need to reinvent the wheel here.

Goal

Set up the react-scripts test runner and document the test procedure in the README.

Replicate:

1. Go to household size page
2. Change the 'Number of members in the household' value to 5
3. Change the 'Number of dependents' value to 4
4. Change the 'Number of members in the household' value to 3

Expected behavior:
'Number of dependents' value to updated to 2.

Actual Behavior:
'Number of dependents' value does not change.

Environment:
Chrome v61.0.3163.100
Commit: f64d563 'Merge pull request #102 from codeforboston/jest-setup'

From what was expressed at the last two meetings, it occurs to me that we might want the 'About' page to point to our repo's README instead of at any particular organization's page. Also, somewhere along the way (probably when trying to switch from react-redirect), the 'About' page link got broken. Those can be taken care of in one go.

Like the other similar issues - changing the logo, etc. - I'm going to put this on the MVP milestone. Feel free to remove it if desired.

As we get into TAFDC (MassHealth had similar issues) we may be getting into territory where we need the income data of each household member, as well as information about their relationships with each other. If our clients have thoughts on a different solution, it'd be good to know.

Regardless of TAFDC, because each program's requirements are slightly different, we're may have to get at least a bit of trivial detail about each household member, though we wouldn't need each member to fill out their individual incomes. For example, SNAP wants to know if any members are 60 or older, while Section 8 wants to know if any members are 62 or older.

One possibility is to ask two questions. '1. Is there anyone 60 or older? 2. Is there anyone 62 or older? ' Another possibility is to ask for the age of each household member. We could get some other individual data that way that would be useful. It should be pretty reasonable to cook up as I've already tried out a couple of experiments. Yet a third option is to decide that 60 and 62 are close enough to each other for the beta test to treat them as the same age bracket. It probably partially depends on how many of our beta testers' families have elderly members. Project Hope might have some data on that. In general, it could be good to know the most common configurations of households to help understand the situation we're dealing with.

#All of these must be in terms of the fields used in the form, even when they're broken up into parts to accommodate other programs' needs.

CALCULATIONS

• Find documentation for and determine calculations for this benefit program's gross income
  • Gross income earned and unearned income with no deductions (here, I believe)
• This will be taken care of through the exclusions issue, #207 Find documentation for and determine calculations for this benefit program's income exclusions (to determine net income) (documentation: In section 5.3, Income Exclusions)
• Find documentation for and determine calculations for this benefit program's values for these income deductions (here, though not as clear as the hud portal pdf, unfortunately):
  • A. Dependent Allowance
  • B. Child Care Expenses
  • C. Handicapped Assistance Allowance
  • D. Medical Expenses
  • E. Elderly Family or Disabled Family Family
• Adjust forms to match the needs of this program (see the form-question-compling google spreadsheet).

DISPLAY RESULTS - moved to Issue 148
- [ ] Remove graph
- [ ] Put accounting tables in results page, a la this mockup (slides 4-5) this mockup, updated 10/31

Resources (documentation found):

• Our spreadsheet now contains a decently organized set of summations and resources
• http://www.tacinc.org/media/58886/S8MS%20Full%20Book.pdf
• https://portal.hud.gov/hudportal/documents/huddoc?id=DOC_11749.pdf (contains the date 2017) [Edit: link seems to go to the right doc in Firefox, but not Chrome] Apparently not working right now. I've downloaded what I think is a cached version of the document, but we can try this instead for now.
• https://www.hud.gov/sites/documents/43503C5HSGH.PDF (Chapter 5 of, probably, the current available version of the 11749 pdf from what I can tell. Links to all sections here. If you need to find it again, try going to the HUD site and using their search to look for 4350.3 Rev-1 or 4350.3 Full Version. Secondly, if that doesn't work you can try calling someone at HUD. I looked in the 'Contact Us' section, under 'Toll Free Numbers' and followed the 'Publications, Forms, Issuances' link. Pro tip: offices found through 'Policy and Research' were not able to help.

There are still a lot of unanswered questions, but it looks like the form field/input consolidation spreadsheet that shows how each program can get the data it needs might be useful.

What would make it more useful would be a listing of the property name that lines up with each field/input.

• Add a property name column and fill in each field's matching property name

CALCULATIONS

• What inputs are needed from the user?
• What environmental inputs do we supply (FPL? etc..)?
• How is estimated benefit calculated?

New questions that will hopefully answer that last one:

• What count as medical expenses?
• If getting a housing subsidy, which rent counts? Rent share, or contract rent? (My guess is rent share, since we're asking about expenses)
• Does handicapped assistance get put in dependent care as well? That is, does the user need to write it into both places? Or does one count for the other? How best can we ask this question?

DISPLAY RESULTS - moved to Issue 148
- [ ] Remove graph
- [ ] Put accounting tables in results page, a la this mockup (slides 4-5) this mockup, updated 10/31

To reproduce:

• Open the demo in a browser
• Hit "intake new client"
• Hit "submit"
• Hit "create visit"
• Hit "next" until on the "previous expenses" screen
• Select monthly rent input field
• Enter '10'

Expected behavior:

• Input should appear as typed, and be validated as appropriate

Actual behavior:

• Screen is replaced with "TypeError: inputProps.id is undefined", with further backtraces

Putting this here to mark it as needing discussion at our next meeting at the latest.

Should we pretend that only one person is filling out the form? What kind of data do we need individual info about? Can we get someone from our client's end of things to weigh in?

Remove:

• Save results
• Existing clients section
• Login button
• Alert that occurs after one submits a new client's info

Rationale: Current version shows potential functionality. Moving to production, therefore removing non-functional elements.

[Edit] Rather, how does the government treat numbers? What we really want is to be consistent with governmental calculations that will actually determine the client's benefits. Are there standards or guidelines? Some possible questions: Do number stay as raw as possible, only being rounded when displayed? Are numbers rounded on some occasions and floored on others? Is the emphasis on precision or on consistency? Another situation is described in the second comment on this thread. How is a situation like that handled?

If the government doesn't have such a thing, how consistent does this app want to be? And how precise does it want to be?

[Original below]

See the second comment in this thread for an explanation of the actual, and even more interesting, question.

It's impossible to have accurate math (see below), but we can either be more or less accurate. How accurate do we need to be? It's better if we decide sooner rather than later. So two questions come up in my mind:
1. How big of an error is acceptable?
2. What is order of magnitude of the problem if we use our current, plain javascript, math?

Does anyone have any idea of what order of magnitude these inaccuracies will build up to? Is it going to be a few cents, tens of dollars, or thousands of dollars? Is there a way to know?

More detailed description: When programming, it's impossible to have completely accurate math. First of all, our computers use binary math (base 2) and have to convert to base 10 whenever we want numbers. Secondly, there are always going to be times when a program will have to round an number to some decimal place. Each language decides how many decimal places to allow before rounding. So we get stuff like 0.1 + 0.2 come out as 0.30000000000000004.

(Brought up in the math test PR, #63)

Results page should show table shown by this mockup, updated 10/31. It should include every program for which we're doing calculations.

For now KEEP THE GRAPH on that page too, just to aid in development. Also, we may want to consider keeping the graph, though hiding it, and allowing a user to reveal it if they so desire. The graph really does give a good idea of the progression of a program as income changes.

Point the tool's about to Project Hope's about page.

open research Q.

Images:

None

Replicate:

1. Place cursor in any entry field on any page. (Does not matter if it has date or not.)
2. Hit return.

Result I'd Expect:

• Data would be "entered" and cursor would go to the next field.

Actual Result:

• User is returned to previous page. (No data is lost in any field.)

Environment:

Operating system and version: 2008 macbook running Lubuntu 16.04
Browser type and version: Chromium, 62.0.3202.62 (Official Build)

App version or commit id at the time:
eb8bd79

Other Notes

• Add a "you are here" vertical red line to data viz, showing where the client is on the income axis
• Add thousandths separator to x- and y-axis numbers

@lianilychee to sync w/ Andrew on verbiage

Comment at c9e641e, relevant to #40.

Copy of comment from me, since it didn't seem to show up referenced in the relevant issue:

My apologies, I didn't notice that adding commas to the numbers apparently also made the second to last horizontal tick mark on the graph disappear. This is the same whether the largest allowed value is set at 100,000 or 60,000. It currently looks like the problem is with the library, not with the submitted code. No solution yet found.

Relevant to #40, item 2.