Closed poorgeek closed 9 years ago
:+1: Looks good. Like you mentioned in scrum, just needs a further breakdown/analysis on 32bit vs 64bit browsers.
What I said during scrum, or at least tried to say, was that I didn't think adding the 32bit vs 64bit checking was really needed and that what I've already posted should be sufficient. I'm trying to keep the rules fairly easy since if we mention 64bit browsers then we have to explain how to find that information as well as increase the complexity of the table to say what is/isn't possible for the browser.
It sounds like you're saying that whether your browser is 32- or 64bit is required information for determining how many LARs can be processed?
That's correct. You don't want to give the user of a 32bit browser the impression that they can process up to 500k LARS. I don't believe there is enough memory in the browser for that.
Resubmitting pr.
For #350, added an initial set of browser reqs to the Common Questions based on the timings done by @doelleri's in his timing doc. Given how long processing takes in the current desktop application, its safe to assume that a user will most likely run out of resources, before they get tired of waiting for the HMDA Pilot to complete the validation of their file.
I chose to set the dividers using the breakout of LARs per 2012 filers, and whether they could complete syntactical and validity edits in 15mins or less. After reviewing the data, the determining factor on whether the user can complete the syn/val validations in the given period of time is if they have opted-in to using the census data locally. After comparing the # of 2012 filers and the timings, the browser reqs below are being proposed.
One thing to keep in mind is that the requirements, aside from browser, are pretty flexible. These instructions could get REALLY lengthy and require that the reader take several things into consideration. What is below is a very simple "rule of thumb" that should work for most users and still cover over 99.8% of filers.
For review by @ericspry, @debseidner and @lesgou.
/cc @pkaplan, @doelleri and @LinuxBozo