Clarify the requirement for clear pkg documentation being available online on submission

[annakrystalli]

We have had a number of submissions recently which did not have enough documentation available online on submission making it too difficult to evaluate package functionality. Some have more details in vignettes, but not made them available for viewing (eg through pkgdown docs) without first installing the package.

Proposal:

• Update the dev_guide instructions to authors:
  • Specify that, Ideally all pkgs should have pkgdown documentation. They should have a good reason not to that vice versa
  • In the case where it does not, enough detail should be in the README for editors to decide whether the package is in scope.
  • Make it very clear that this is their opportunity to make a case for their package. The more we understand about the package, the easier it will be to evaluate this as in scope or not.
• Add a check to the submission checklist about enough documentation being available on submission for an editor to determine functionality and scope and assess whether the package is in scope.
• Add note in docs and blanket response for EiC to use if a submitted package does not meet the criteria

[maelle]

Having a pkgdown doc at submission also means editor&reviewers could review the organization of the reference index and articles index/ navbar.

[maelle]

We should also make it clear that the README should assume little domain knowledge (potential users, and editors, are not omniscient). E.g. if you do something to interact with knitr engines, what's a knitr engine?