transfer to QuantEcon org??

[sglyon]

This is to start a discussion about whether or not we should transfer this repository in to the QuantEcon organization.

I've been contacted recently by more than one source asking about the status of this code and the relationship to quantecon. Parties have suggested that with the repo in my name, with me being the primary contributor, there is a fair amount of uncertainty regarding the future maintenance of the code. If the repo were housed under the QuantEcon umbrella, that might send a stronger signal that we have at least medium run goals to keep this package going.

I use this code in my research, so I plan on maintaining it going forward. But, unless someone asks there's no way to send that signal.

I'd be happy to move this over. Before I do that I'd like to write up some quick docs. And make sure the rest of the team is on board.

cc @jstac, @cc7768, @mmcky, @albep, @vgregory757, @albop

[jstac]

I would be very happy to have this code as part of QuantEcon, and to support its development in any way we can (e.g., support RAs who can write tests and documentation, as well as add functionality). The mission statement we put in for the last Sloan grant matches this kind of activity perfectly.

[albop]

The transfer looks like a good idea. @spencerlyon2 : Something else comes to my mind after reading the README file: whether you should maybe change the name of the package. If you do plan to make significant changes (to me, you already have) then it is not a simple port, but a fork. It would then be cleaner to use another name, both in terms of fidelity to the orginal authors and in terms of stressing the importance of your contributions. branstorming mode: What about two different name space: X as the new package with the julianesque api and the new stuff and compecon which would import the matlabesque functions, maybe just a compatibility layer.

[albep]

I think this is a great idea, as the routines in this repo do have meaningful differences compared to other available packages, which make them better suited for certain uses. I can definitely see why people have been interested in knowing about the status of this code, and how the QuantEcon umbrella would help with reducing the uncertainty.

I'm also happy to help with the docs!

[vgregory757]

I agree, I think it does make a lot of sense to integrate this into QuantEcon. I use it as well, and also wasn't sure how it was going to be maintained in the future. We could also use it on the lecture site to demonstrate how it's used to solve models. I'd also be happy to help out with the transition!

[sglyon]

Thank you everyone for the support here. @albep and @vgregory757 I will definitely be in touch with how you can help out here. It is very appreciated.

I'm glad the responses seem to be unanimous that we move this under the QuantEcon umbrella.

@albop your idea about different namespaces is great -- so great in fact that is is already implemented! If a user does using CompEcon you get the Julian API + extras, if you do import CompEcon; using CompEcon.Original you get the matlab API (implemented as a convenience layer that wraps around the Julian part).

I have thought about this some more and here's my proposal for how the move happens:

• I move all the Julian API part for function approximation into a new package QuantEcon/BasisMatrices.jl. This would contain the parts of this library that do function approximation by building basis matrices of different types: chebyshev, B-splines, piecewise linear, and complete monomials.
• I keep the matlab API (right now in module CompEcon.Original) in a package named CompEcon.jl. This could either stay here at spencerlyon2/CompEcon.jl or (preferably) be moved to QuantEcon/CompEcon.jl
• The other tools I have (e.g. 1d solvers with brent/bisect/ridder and optimizers like golden_method) could move directly into QuantEcon/QuantEcon.jl unless we would like to find another home for them. The reason I would vote to move them into QuantEcon.jl is that there is already very similar functionality in other Julia packages (e.g. Roots.jl or Optim.jl), but the API and implementation here is sometimes more convenient for use in my research code -- which might suggest it could be more useful to other economists also.

If anyone has any suggestions for how to tweak that game plan please let me know.

Otherwise, @jstac will you please re-temporarily-grant me admin rights on the QuantEcon org so I can do the transfer on github?

Thanks

[jstac]

I'm fully on board, including moving the Matlab API to QuantEcon/CompEcon.jl and the various tools to QuantEcon/QuantEcon.jl.

@spencerlyon2 I've given you owner privileges to QuantEcon so you can set this up in the way you suggested.