Hi,
this is what I have in my mind for few months:

1. TAGs.
We should work out a coherent system of TAGs (beside the dataset type and version). I my opinion it would be something like this:
    1st level TAG - general functionality: estimator, test, other(?).
    2nd level TAG - area of usage: statistics, general econometrics, financial econometrics, spatial econometrics, dynamic econometrics, other(?)
    3rd level TAG - complexity (for example number of public functions): simple (DHF_test), advanced (gig).

2. Redundancy
At the beginning we should decide if we allow the redundancy or not?
If 'yes', there is no further action in this area, but if 'no' we should:
    - decide whether given packages are redundant.
    - which one is going to be left.
If we withdraw redundant package we should decide if there is sense and/or possibility to write a wrapper for at least basic functionality. Remember: some packages may consist on other packages.
    - The problem occurs when we want to write a wrapper but we can't. In such case we may:
        * ask author(s) of combining redundant packages
        * combine packages by ourselves
        * let both packages to exist

3. Package verification
Allin wrote a nice code for fast verification of sample scripts. This would be a start point, but later we should:
    - Check if package is complete: name and email(!) of the author, TAGs, version, help (we should think about PDF in the gretl (like gig has) or available at the packages server to download) and sample script.
    - Allin's code verifies the sample script, but at least for estimators and test we could ask authors of sample data and benchmark results. We were talking about it at Ancona this summer and I know that there may be some copyright issues, but is such case we can think about artificial data.
    - If package collapses we:
        * should withdraw the packages from the server
        * can look at the problem and try to fix it by ourselves or contact the authors; here we have such possibility that the problem lies inside the gretl (for example backward incompatibility) - I don't have an idea what we should do in such case?
        * until the package is not fixed it cannot be uploaded to the server

4. Team work
I think we could think about 'maintainers' of the:
    - 1st level TAG? or
    - 2nd level TAG? or
    - other(?)
IMHO we could have maintainers of the 1st level TAG.
If you agree I would be the 'maintainer' of the maintainers which means I would take a decision on miss classified packages and give a green light for fixed packages to be uploaded to the server and I don't know what else.

What do you think?

All the Best,
Marcin



W dniu 10.11.2014 o 12:21, Marcin Błażejowski pisze:
Sorry for (huge) delay, by the paper for JSS consumed almost all my time. But for two weeks the paper is "conditionally accepted" so it's high time to do some funny work.

The process of package verification is very complex. I was trying to start this work twice on summer and I found a lot of things (beside the list I've posted to the Gretl-devel in the email "Comprehensive quality control for function packages"). Let me explain just two main topics:

1. Tests
Here we have the easiest work: since certain test tests certain thing, we can even run the script with procedure for testing the tests. This is not very complicated and possible to workout in few days.

2. Redundancy
Let me give an example: HEGY and DHF tests: do we really have a redundancy here? Rather not, but in case of Jack's "Hegy" and Ignacio's "GHegy" rather yes. So we need procedure for deciding which one should stay or how to join them into just one package. This is (theoretical) easy, but...
2* Some packages consist on (or in more precise word: use) another package(s). So in my opinion in case of wasting the redundancy (what is basic thing in informatics) we MUST write wrappers.


What I (now) want to do: this is may last really busy week, so up to 20th November I prepare draft of such procedure with my proposals. In case of the Team I think that we could split the work according to type of the package: tests, estimators and so on.

Best Regards,
Marcin


W dniu 06.11.2014 o 17:52, Riccardo (Jack) Lucchetti pisze:
On Thu, 6 Nov 2014, Henrique Andrade wrote:

Em 5 de novembro de 2005, Allin escreveu:

(...)

I won't go into all the specifics -- although I think you're right -- but
rather I'll address the general issue here.

We could really do with some editoral control over the function packages.
Up till now we have been totally "laissez faire", but if the packages on
the server are supposed to be a showcase for adding to gretl's built-in
functionality they need to be pruned and consolidated. I wonder if we could
assemble a committee of 2 or 3 members to work on this.


I would like to be one of them. I really like to test that kind of stuff :-)

I believe that the Polish team has already done some preparatory work in that direction and it would be a shame it that gets wasted, so in my opinion the best thing would be to join forces.

If nobody minds, I'd like to put forward a proposal: Henrique, Sven and someone else (nominated by Tadeusz, Marcin and Paweł) become the package maintenance team, with the following responsibilities:

* short run: classify packages with a set of criteria like the ones we've been discussing so far, and make proposals about them (also in the light of the expanding set of features that Hansl has been gaining over the years). For example, Claudia's clustered_ols is IMO quite valuable in terms of example script, while for example I wonder whether we really need "cnumber" any longer, since a possible Hansl equivalent implementation may reduce to the 7-liner

<hansl>
function scalar cnumber (matrix X "set a variables matrix")
  matrix A  = X ./ sqrt(sumc(X.^2))
  matrix En = eigensym(A'A) # compute the roots of AA
  scalar cn = sqrt(maxc(En)/minc(En))
  printf "Condition Number = %12.2f\n",cn
  return cn
end function
</hansl>

On the other hand, more complex stuff like HIP may become an add-on. Sven's previous message was a very valuable start at this.

* medium run: verify that all the packages install and run the provided example script on the widest possible assortment of OSes (various flavours of Windows/Linux/OSX): perhaps, it'd be nice to have someone with some OSX competence in the team, since I assume the people I mentioned can patrol the Linux/Win territory quite well.

Of course, I don't mean to force anybody to do things they don't have time for or don't feel like doing, so I don't want anybody to feel obliged.

-------------------------------------------------------
  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-users mailing list
Gretl-users@lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users


-- 
Marcin Błażejowski
GG: 203127


-- 
Marcin Błażejowski
GG: 203127