[Gretl-devel] Re: Function packages quality measures
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!
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.
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" ;-)
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.
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.
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.
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.
thanks
sven