Re: Proposal for a team of admins

[Julien Bect]

Le 12/01/2017 à 12:12, c. a écrit :
> On 11 Jan 2017, at 10:58, Julien Bect <address@hidden> wrote:
>
> > * When the EHP [1] is created, we have of course to create its OF-repo by cloning 
> > its main repo.  But for other packages, we also have to create an OF-repo [-> 
> > no additional work].
> Why "of course"? Externally hosted packages could just be externally hosted, 
> developed and deployed.
> How these packages are developed and distributed should in no way interfere 
> with the working of OF.

Hi Carlo,

Sure.  I was writing under the assumption that, for EHP distributed as 
OF packages, we should continue to keep a clone of the repo (exactly as 
we currently do).  Which my interpretation of option 2.1.

So, my "of course" simply meant: because the clone need some human 
intervention to be created (in other words, I am not considering 
automating this task in my proposition).

Nothing more.


> So if the OF leader(s) are not happy with how the code of a package looks like 
> they should not necessarily
> clone it as-is and host it on OF.

Yes, I agree, OF admins are (and should continue to) be allowed to 
refuse to distribute a certain external package if they are not "happy" 
with it.

But I would like it much better if we could argue rationally about such 
decisions, based on some explicit, published (and 
as-objective-as-possible) list of requirements.

IMO, package acceptance based on the "happiness" of admins is not a good 
way to attract more contributions.


> I think that looking at other people's code and trying to convince them to 
> adapt it to what he beleived to be
> the minimum acceptable quality standards of OF is a large part of what Carnë refers to 
> "community management"
> in his latest post and is very tirying and time consuming.
>
> Such code does actually not even necessarily be proper "packages", for example 
> for a function consisting of
> a single file the complete package structure is definitely overkill.
> Contributions of tis kind may still be useful per-se (e.g. I found the now gone 
> physical_constants package
> to be very useful ...) but especially are a great way to get new contributors 
> involved with Octave development
> without being confronted with a steep entry barrier.
>
> I do understand OF leader(s) may not wish to have their own "reputation" or that of OF 
> linked to the "quality"
> of such software, but I still think we would benefit from maintaining a list of 
> such contributions.
> So if you like this list could be maintained elsewhere, e.g. on a dedicated 
> page in the wiki taht would be linked
> to from https://www.gnu.org/software/octave/ just like Octave Forge.

Sure, why not.

Nobody can prevent you from building such a list (and don't misinterpret 
me: I like the idea and would probably contribute to this as well).  But 
then this is not the same thing as "Octave Forge packages", and I just 
don't think the OF admins should have much to do with it.

The main "controversial" issue IMO is about the distribution of EHP as 
OF packages.  We are currently doing, but not really advertising it.  I 
propose to continue doing it and, progressively, to make it more "official".

Remark : If you decide to make this list idea happen, I suggest to use a 
VCS to maintain this collection of links, rather than the wiki.  The 
README.md (markdown) of github or SourceForge projects is quite 
convenient for this.  There are many examples on github.

@++
Julien