On Thu, 2 Jan 2020, Sven Schreiber wrote:

> Am 02.01.2020 um 07:57 schrieb Talha Yalta:
>> Hi Everyone,
>
> Hi Talha,
> very nice to hear from you again, and a happy new year!

Yes! Welcome back!

>> About a month ago, I have been checking out a specific function package
>> (the name and its author is not important), and I saw that it was quite
>> buggy. Moreover, it was faulty method-wise as well !!!
> ...
>
> IMHO (also as part of the team of moderators of contributed function
> packages) the main route to improve function packages is exactly what
> you did: Users should ideally first contact and notify the author about
> the problems with the package. That's what I have done repeatedly in the
> past as well.
> But of course that still means that the gretl community should also know
> about the problems. In that sense I think that the name of the package
> _is_ important. Then we can check whether we all agree there is a
> problem, and what to do about it.
> Here "gretl community" can mean at least two things: Either the people
> on the mailing lists. Or sometimes you may not want to go public right
> away, in which case users may also contact the moderation team. (Maybe
> we should add a note to the list of packages how to contact the
> moderation team.) In principle the gretl bug tracker on Sourceforge can
> also be used I guess.

I agree with Sven: I'd contact the package author first, putting the
package moderation team (Sven, Allin, Artur and myself) in cc. If there's
no response, then someone should step in to fix the package, or remove it.

>> 1)- It would be useful for the main program to put some sort of
>> disclaimer about the packages; warning the user that these are not
>> official, some of them are seldomly updated (if at all), likely to be
>> full of bugs and errors etc.
>
> I agree that the increasing integration into the main program
> (especially the menu attachment) could give a wrong impression. Maybe
> the main dialog window of the package should get some sort of
> disclaimer. (However, I wouldn't say "likely to be full of errors" ;-)

Uhm, I don't know, Talha. The same disclaimer would be applicable to
CRAN, or OctaveForge, or CTAN, for that matter. I don't see why we should
take responsibility for what package authors do (or don't).

>> 2)- Setting up some sort of peer review process where packages are
>> checked and verified by a developer.
>
> To some extent this is what we did when we introduced the moderation
> process. A number of packages have been removed as a result of that. Or
> they have never been approved in the first place. For example, the
> latest submitted package is still pending (not yet approved) until the
> authors answer some questions about it.
>
> However, let me be very clear that the moderation is not a full check or
> review. The responsibility for a package rests with the respective authors.
> In terms of capacity the moderation team is unable to do further checks
> than we are currently doing. But we'd be happy if -for example- there
> were a group of additional experienced gretl users like you who would be
> available to do some cross-checks. Maybe that is something we should
> pursue.

I 100% agree with Sven.

>> 3)- A means to comment or rate packages can also be useful.
>
> I'm less enthusiastic about this idea. Considering some opinions in the
> internet about gretl itself I wouldn't want to confront authors of
> contributed packages with this kind of hate speech.

Again, we do have the mailing lists: if someone has something to say (good
or bad) about a package, I'd say that's the best place to go. And that's
google-searchable too.

>> 4)- Adding usage statistics maybe. These data can be censored by
>> presenting as rankings etc. This would also encourage writing better
>> packages.
>
> One problem is how to measure that, given that we already are having
> difficulties to get an idea about the usage of gretl itself (Jack did a
> presentation about that at the latest conference). But in principle I
> guess that download numbers from the package server might be feasible.

That would be nice, yes.

>> Allin went through in the beginnings.) However, it is possible to lose
>> this reputation fairly quickly with a few bad extension packages.
>
> We absolutely do not want bad packages, of course. We would always
> remove a package that gives wrong results, even if it were the only
> remaining package.
>
> The gretl policy is based on the collaboration of all users: If somebody
> finds a problem, we really depend on that feedback. Then we can act. In
> that sense, please tell us about the problem you found. Again, if you
> don't want to do that in public, you can also send a private message. If
> the package is changed or removed as a consequence, that would be
> announced by the moderation team on the users mailing list.

Amen, brother!

-------------------------------------------------------
   Riccardo (Jack) Lucchetti
   Dipartimento di Scienze Economiche e Sociali (DiSES)

   Università Politecnica delle Marche
   (formerly known as Università di Ancona)

   r.lucchetti@univpm.it
   http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------_______________________________________________
Gretl-devel mailing list -- gretl-devel@gretlml.univpm.it
To unsubscribe send an email to gretl-devel-leave@gretlml.univpm.it
Website: https://gretlml.univpm.it/postorius/lists/gretl-devel.gretlml.univpm.it/