Re: Feedback on our evaluation criteria

[bill-auger]

On Tue, 14 May 2024 21:33:33 +0000 Fischers wrote:
>   However, he would like to have link to the detailed evaluation
>   of the relevant criterion. He explains, if I am the one running
>   the repository, I want instructions of how I can improve the score.

there is no elaborate or comprehensive specification of the criteria - for most
of the criteria, it would not be possible to give explicit generic instructions
- the guidelines are (hopefully) detailed enough such that any webmaster should
know what what each entails - if not, one could ask on this mailing list for
advice about specific cases

for example: "no non-free JS" -
solution: get rid of the non-free JS - write your own JS to replace it if
necessary - the criteria can not presume or predict which JS are used, which
are important for site functionality, or which could be re-written or replaced

for example: "does not log user activity" -
solution: turn off logging - simple enough, but _how_ to do that depends on the
specific software and/or the server OS - there is really no way to give
instructions that would not essentially be a primer course on "how to be a
webmaster or sysadmin"


On Tue, 14 May 2024 21:33:33 +0000 Fischers wrote:
>   2. The evaluations are inconsistent among different repositories.
>   For example, we say that "[t]he worst thing that github.com does is
> ...
>   But we don't say this about, e.g., GitLab, which has the same issue.

other than savannah, they all have that issue - none have adequate licensing
documentation - the reason why github is singled-out on that one flaw is just
historical - github was the first on the list beside savannah - that statement
could be made generically; but myself, i would remove it - it is not doing any
work; because there is a specific criteria for "encouraging good licensing
practices", which is sufficient to make the point


On Tue, 14 May 2024 21:33:33 +0000 Fischers wrote:
>   we could perhaps link to an email list discussion where we refer
>   to a particular instance of important functionality breaking

the next revision will have exactly that - the very previous email sent to this
list has a patch to add that feature - in the past, that information was
available only by searching the past discussions on this list - now a
checklist is kept for each host, including links to the most relevant past
evaluations; but there is no single "instance" - it is not possible to
consolidate everything discussed about a specific host or criteria; because
these discussions involve emails from many people and can span weeks, months, or
years

for example: https://libreplanet.org/wiki/ERC/Notabug


On Tue, 14 May 2024 21:33:33 +0000 Fischers wrote:
> I believe we could assist non-GNU projects in exercising their freedom
> if we would publish criteria and evaluations of ethical repository services.

that seems to me to be the definition of these criteria - everything is
published - what is missing? - would you prefer if it specified:

  "These guidelines are perfectly relevant to any software project and any code
   host. Anyone, either as a user or an project maintainer, may adopt them;
   and any service operator may apply them."

IMHO, that goes without saying


On Tue, 14 May 2024 21:33:33 +0000 Fischers wrote:
> 1. Clarify that the criteria apply only to source code hosting websites;
>    some projects may want to use non-website source code hosting.

the criteria can apply to any hosting service operated by any software project
or any third-party - whether or not those are websites is irrelevant - the
criteria are not judging the service software - they are judging the site
operators' treatment of their users - eg: which unethical practices do they (via
software or otherwise) encourage hosted projects to follow, or impose upon
people (anyone) who try to read or get source code from that host


On Tue, 14 May 2024 21:33:33 +0000 Fischers wrote:
> Finally, I remarked during our conversation that it is inconvenient
> to have only criteria for GNU projects, not also for non-GNU projects.
>
> 2. Create a new grade "C-" with the full title
>    "C- -- Acceptable hosting for a non-GNU package".

that wording is plainly because GNU can dictate what is "acceptable" only for
itself - GNU has no authority over non-GNU projects; so it would be pretentious
to define what others should or should not accept - independent projects must
decide for themselves what is acceptable; because only they have the authority
to accept or reject these principles in the context of each their own projects