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
