Clarify language on repository requirements and the need for registration

[Kevin-Mattheus-Moerman]

The JOSS submission requirements state:

In addition, the software associated with your submission must:
-     Be stored in a repository that can be cloned without registration.
-     Be stored in a repository that is browsable online without registration.
-     Have an issue tracker that is readable without registration.
-     Permit individuals to create issues/file tickets against your repository.

I believe it would be better to alter the last point to include without registration i.e.:

Permit individuals to create issues/file tickets against your repository without registration.

[arfon]

• Permit individuals to create issues/file tickets against your repository without registration.

I think that's what we mean by this yes. Although I worry a little that this favors people using GitHub & GitLab only (i.e. places where people might already have an account?)

[danielskatz]

I think we need to make this a little more specific, perhaps something like "without registration other than as needed on community-accepted coding platforms (e.g. GitHub, GitLab)"

I'm not sure if this is exactly right either though

maybe "without registration specific to your software"

[jedbrown]

I think "without registration" is a red herring -- almost every platform requires registration if only to manage spam. I think it's enough that the issue tracker be viewable without registration and that registration be automated (no human in the loop). Note that there is a lot of scientific software developed using independent GitLab instances -- Gmsh, VTK, and ParaView to name some prominent cases that should be welcome in JOSS (hundreds of citations per year).

I would exclude instances in which a person needs to be in the loop to create an account, such as the GitLab instances run at many universities and national labs.

[platipodium]

I agree with @jedbrown that there are good reasons for platforms to require registration and that JOSS should embrace this by not excluding registration-enforced issue trackers for submissions (as long as registration is automated). Two recent developments underline this:

1. The European data protection laws have been making it more difficult for researchers at public institutions to officially deploy on GitHub or GitLab, and have been moving towards self-hosted instances.
2. The registration on those self-hosted instances is moving towards a very thin registration layer leveraging account management through authentication providers (public orgs, academic institutions, orcid, GitHub, ...).