[Savannah-hackers-public] requirements page

[Ivan Zaigralin]

Dear Savannah hackers;

During our recent discussion in address@hidden Karl Berry expressed an 
interest in improving the requirements page:

On Thursday, March 02, 2017 22:33:58 Karl Berry wrote:
> The policy has always been that Savannah
> administrators can exercise judgment,
> and not be required to blindly accept
> every project submission that meets the
> technical requirements. I see that we have
> failed to state that on
> https://savannah.gnu.org/register/requirements.php;
> we can work on that.

I think this is a fantastic suggestion, for the following reasons:

(1) Allowing submissions to be rejected based solely on subjective judgment of 
a single reviewer is highly unusual for hosting services. Indeed, most 
commercial hosting services do not even have a human intermediary present 
during the submission process, so many users have already come to expect that. 
Also, subjective evaluations of things like whether the submitted code is 
"generally useful" are usually associated with software projects, not hosting 
projects, so users would almost certainly appreciate clarity on this issue 
before they invest time and effort in preparing a submission.

(2) Karl is absolutely right, in my opinion, to suggest 
https://savannah.gnu.org/register/requirements.php as the correct place for 
this policy to be clearly stated, and not 
https://savannah.gnu.org/maintenance/HowToGetYourProjectApprovedQuickly/
The policy is clear, and the precedent is consistent: meeting all the 
objective and/or technical requirements currently listed in requirements.php 
is sometimes not enough to get a project accepted. Failing a subjective test 
does not merely slow down the acceptance process, but may well prevent a 
project from being accepted at all, and have done so in the past. So passing a 
subjective evaluation by a Savannah admin is clearly a requirement, not merely 
a way to speed up the process.

(3) Nothing currently listed in the two pages cited above can be interpreted 
as a clear statement of the standing policy. In particular, it's not at all 
clear that subjective criteria and/or personal judgment will have bearing on 
the process. All of the examples below come from the 
HowToGetYourProjectApprovedQuickly page, not the requirements page.

> No storage or back-up-only project: we exist to help people develop software
> and technical documentation. Other hosting services offer storage space. We
> expect to be used primarily and not as a back-up, although we do not
> require all parts of the project to be hosted at Savannah.

There is no reason for user to suspect a subjective judgment call here. Since 
the Savannah code of conduct suggests to assume good faith, the only way to 
determine the intention of a submitter at the moment of submission to is ask 
them whether the project is in active development. In the absence of strong 
factual evidence to the contrary, there seems to be no good reason to reject a 
project which is not a self-admitted data dump. This is an objective test, 
since the submitter can at any point make it very clear what the project 
leaders' intention is.

reference: https://savannah.gnu.org/maintenance/CodeOfConduct/

> We discourage submitting simplistic text-only projects, such as a single
> text or html file containing a list of urls. Such things are better
> maintained as straightforward web pages than incurring all the overhead of
> a full project at Savannah. Nonetheless, if you think your file is special
> and deserves its own dedicated project, we will consider your argument.

Whether a project is text-only can be made objective enough by requiring the 
submissions to contain nontrivial amount of code for which there is an 
interpreter or compiler, and which are therefore clearly not "mere text". In 
particular, a test for whether a project is a single text or html file 
containing a list of urls can be done by a simple algorithm, so that's clearly 
objective. So one reasonable way to interpret this paragraph is to assume that 
Savannah admins may use their subjective judgment to *accept* a project which 
failed an *objective* test, not the other way around.

> This ensures a level of quality for projects hosted at Savannah

There is virtually no way to interpret this as a suggestion that a subjective 
quality test will be applied. All that can be gleaned from here is that 
quality is the desired effect of the approval process.

(4) In line with the ideas stated above, I'd like to suggest adding the 
following paragraph to the bottom of the page

https://savannah.gnu.org/register/requirements.php

<h3>Other Requirements</h3>

<p>Savannah is a non-commercial, volunteer-powered project with
extremely limited computational resources (such as disk
space). Reviewers can exercise judgment, and are not required to
accept every project submission that meets the objective technical
requirements listed on this page.</p>

Optionally, the previous paragraph can be extended to provide more specific 
guidelines, if the Savannah team deems this to be helpful for the potential 
submitters:

<p>A judgment call can be made with respect to how generally useful the 
program is, how simplistic it is, whether it is a one-time experiment, 
etc.</p>

Optionally, some references can be given to further elucidate the policy. For 
example, my last submission https://savannah.gnu.org/task/?14370 can serve as 
an example of a project which was deemed not "generally useful" in the 
subjective opinion of the reviewer.

(5) I believe a statement such as the one in (4) is by far the best way to 
inform the users of what the rejection policy is really about. Simply listing 
a few example criteria will probably not suffice to cover all the possible 
reasons for rejection, and will probably not be enough to destroy the 
assumption of objectivity: an assumption many users make about a hosting 
service. Using the word "subjective" while describing this policy would be 
ideal, but I feel that contrasting the Other Requirements with "objective" 
requirements, as I did above, does the job reasonably well.

Please let me know what you think: is this a good idea in the first place? Is 
that a good way to express the standing policy?

I know my posts are long, so triple-thanks for your time.

signature.asc
Description: This is a digitally signed message part.