per the github suggestion:

Any modern Javascript framework, whether the more generic JQuery or interface frameworks like React, Backbone, or Ember, will provide cross-browser support.

I don't know of a good example of evals for this kind of maintenance grant.

wondering about section 2.2 of this more recent survey of NSF researchers: http://doi.acm.org/10.1145/2753524.2753533

and the goals and understandings of the communities. if it adds anything to what's there in any real way.

This remains an issue but I'm thinking about the conversations around automated patching (what constitutes a good patch). Especially around deletions - if deleting some block is a correct solution but removes functionality, is it a good patch? Here, it's more about correctness in those areas that directly relate to the science question (an algo implementation, for example) or research goal and not expecting 100% bug-free code (that is unrealistic).

On the research software side (and I'm thinking about the push towards a lot of web-based systems), this medium ground is maybe defining expectations of correctness in the implementation directly aimed at the science/research question (so like the data collection in a Zooniverse project) with a second set of expectations for the other parts of the application (bugs in the tutorial are not critical to the science, necessarily, but raise concerns for adoption and community engagement). This would affect the kinds of specs we might want to see or encourage.

We do need something more explicit about mobile apps although it can also be lumped into the follows platform guidelines

Add text for including test data, configs for building databases, etc

Add a note about installer best practices for the platform - target directory, customization for environment variables, etc.

We do not directly cover localization/internationalization. Unclear the scope of that need; however, it might be worth adding (under the unicode statement or instead of) some text for it if localization/internationalization is a stated need of the project or if the stated goals imply that need (if for use in area not predominantly English-speaking, is there any attempt at localization/internationalization?)

Missing header formatting here

A discussion of methods being used in the OS crowd for funding: https://github.com/nayafia/lemonade-stand

This is temporary until the final is released with a DOI (unknown timeline for that.)

might be missing a reference or two?

one that supports any of the things that makes code reusable instead of just blobs of fortran would be fantastic here. So more examples?

unusable code is unsustainable code, ie think about ROI from the funder's side

the docker security white paper

could be a better statement, but added here to make sure containers are included.

meaning, do you really need 200 options for toggling private, private to group, public for a page?

does not remove the sysadmin requirements but is (often) misinterpreted as such. point people to system resources for upgrades (to know what the thing is to update), give them an understanding of how to handle your app in the container for upgrades.

possibly the worst link for a functional description.

this seems picky but google will downgrade sites without it

could include something like Coverity (http://www.coverity.com/), contributed during the revision process. doesn't fit currently now.

needs a better word.

code isn't self-documenting and tests don't capture project decisions in very real ways.

If there are more HPC/GPU/cluster-related guidelines that might be missing, add them.

https://research.googleblog.com/2009/06/speed-matters.html

Note re: robots.txt and web service access - it is a blunt instrument in many ways, relying solely on it to block traffic is indicative of load issues.

how complete do we need to make this list?

add something about describing the process (ie you get booted temporarily for 1 violation, etc).

so if i want to run awesome service framework and i know i need to handle XX requests per minute, i have a better idea if the system can handle that now or if i might have to modify it to meet my needs.

must be a better way to say bad interface design + private info made public != user error.

vulnerabilities in the older browsers, IE.

something about choosing or noting institutional requirements (limited to dept site and templates provided, etc).

could make a statement related - project includes explicit effort to gather info or has performed that prior to start.

section needs a bit more context (esp. ontology/vocab service bits) and examples/references.

Insert more context here. maybe what kinds of things are tested, benefits, etc.

probably not the correct statement re: data inputs, mocking, etc.

currently without a reasonable reference here.

the library crowd does this often, if there's a need to expand?

if it exists, i'm not having luck finding it.

data pipeline scripts vs some data repository code, for example.

being revised for the top two levels (overlap in types not funding, ie the bars don't indicate when a grant ends but that a kind of grant could result in projects at different progression stages)

As applicable

this material must be contained with the software but not required in web site?

specify guideline

e.g., cook book

clarify what QC is

could be a FAQ - Y or N

PID over URL

PID should be used instead of URL

usability vs maintenability?

don't understand this

is this a value judgment

potentially provides an opportunity for misinformation propogation

why so specific?

typo

auto updating can break other software. From geoscientist perspective these are valuable but shouldn't be a deal breaker for assessment.

important for end users but difficult to achieve

too subjective, lower priority

larger assessment framework but not necessary for software, would this preclude forum or comments in GitHub issues?

larger assessment framework but not necessary for software

no password sharing

is this redundant? Documentation?

where are these? In documentation? SHould this be part of testing?

is this relevant to software? It seems releavnt to data. Not necessarily applicable to all

(these first few are mislabeled - not from ssi/esip)

criteria statement?

a principle

very system dependent (hpc)

not about software

not applicable as criteria.

specific understanding of software - not applicable broadly.

review with documentation for duplication - make statement here for documentation archived with code and meets those doc standards.

see previous "constraints" comment

would like further clarification

not sure what this means?

could add penetration testing.

visible

typo

revise for intended use to make it clearer re: license

over-documentation

chuck anyway

typo

installers provided for target platforms & target platforms are indicated in the documentation.

too specific

if needed

add the linting concerns as sub group to testability. & rename testability.

group under identity

also chuck this

update for new software publication practices (not paper necessarily)

Move any doc-related criteria to Documentation (and check Learnability)

Add description re: accessibility for publication/reproducibility and link to accessibility for ARIA, etc.

Group with licensing.