DESCRIPTION file

[josherrickson]

With the discussion to start releasing pre-alpha builds, we should at a minimum update the DESCRIPTION file.

Most of it is either straightforward, but the following items should be addressed before releasing any versions:

1. Authors: Anyone else besides Josh, Josh, Ben, Xinhe? Who should be the primary CRAN contact person?
2. What license should we use?
3. The URL/Bug Reports link to this repo, which is private. Should we a) leave it as-is, b) remove it entirely (or if it needs to be there, direct to a dummy page e.g. about:blank), or c) create a public-facing repo with only README/issues?
4. I was going to get the title/description from the README. We can of course amend these later, but some simple version should be there now. Any objections?

@jwasserman2 if you end up producing a binary from a pre-estfun commit, I'd strongly recommend branching off there and adding in whatever DESCRIPTION we come up with here (with proper versioning of course).

[josherrickson]

I've got a very rough first pass at the file, DESCRIPTION. I welcome comments here, or commits to simply amend it.

[jwasserman2]

For the license, I think we need to use GPLv3 since the sandwich package does and we're using its code. This is from taking a brief look in the R packages book and GPL license linked there.

For the title, I propose amending to Direct Adjustment of ITT Effects with ... to clarify what kinds of estimates we intend users to make with this package.

I made some tags yesterday that only incremented the version, so once we finalize this, I'll re-make those tags with the updated fields here.

[josherrickson]

Changed to GPL.

[benthestatistician]

Are we using sandwich code in the sense of bundling it, @jwasserman2, or only in the sense of having sandwich dependencies, and modeling code on theirs? If the latter, I don't see that as forcing us into a GPL license, just as the GPL license on R itself doesn't force such a commitment.

I'm not comfortable with the GPL license myself, so I've reverted that commit.

[benthestatistician]

Some additional thoughts on Josh E's questions.

1. Authors. I'd like to add Mark F, as a contributor. Perhaps "contributor" better describes @xinhew0708 's role in flexida, at least at the moment (depending on how much she contributes we may make her an author later). 4ff2243 implements these changes, and also moves me to the end of the list.
2. I lean toward the MIT license, following the KISS principle and other concerns.
3. (a) I'd propose that our URL/bug reports link to point to our development website, wherever it may be. Not rigid about that, it just seems the simplest. If others prefer another model, let's discuss. (b) When it's finally time to go public, will everyone be comfortable with our simply exposing this repo, with its history? (Perhaps under a different name -- but I'm pretty sure that if we change the repo name github will redirect URLs that reflect the old name.) Again, if not sure let's discuss.
4. No objections.

[jwasserman2]

@benthestatistician could you clarify what you mean by bundling it? We import it for use of their functions such as meatCL, but we also add methods to their functions estfun and bread.

[josherrickson]

I'm fine exposing the private repo if you want. So we can keep the URL as is now, and when we finalize a name, updating it.

[benthestatistician]

@jwasserman2 I'm following Wickham's usage (of "bundling"), in the book chapter you link to above.

[jwasserman2]

I see. I don't copy their code over anywhere, I only take a dependency, so it seems by that book we're free to use an MIT license.

[josherrickson]

What about the .expand.model.frame.DA function? I basically just copied stats::expand.model.frame and made a small change to work for our scenario. That seems to fall under the 3rd "bundle" example in Hadley's book. Does that require us to use GPL?

[benthestatistician]

I take it that Hadley's "3rd bundle example" refers to the following?

You’ve copied a small amount of R code from another package to avoid taking a dependency.

If that's correct, then I'd say JE's adaptatio of stats::expand.model.frame() is OK because of the fact it doesn't copy that code in order to avoid a dependency. We've got a dependency on the stats package, in virtue of the fact that we depend on R.

[josherrickson]

I think that's everything. @jwasserman2 the current DESCRIPTION should be good to move to the earlier tags.