search

OpenIntroStat / oilabs

🛑 This package has been deprecated and datasets and functionality have been moved to the openintro package
https://github.com/OpenIntroStat/openintro
Creative Commons Zero v1.0 Universal
10 stars 19 forks source link

Data in oilabs, openintro -- open to some renaming/recoding? #40

Closed rpruim closed 4 years ago

rpruim commented 6 years ago

I don't know how married you are to the current names and coding scheme, but I would love to see some changes:

1) Don't use 0/1 coding for things like male/female, or at least have an additional variable that doesn't use an arbitrary assignment like this. (Perhaps using male or female as the 0/1 -- or better TRUE/FALSE -- code and sex coded with "male"/"female" or "M"/"F" or something similar.)

2) Don't skimp on characters. Make things clearer by using a few more letters. Examples: bdims -> BodyDims, hgt -> height, etc.

3) I love using capitalization for data frame names and lower case for variable names, but I realize that that many do not use that convention. For teaching, I think it is very handy to have data sets clearly distinguished from variables.

4) Don't mask data sets from other packages -- especially not datasets. datasts definitely has dibs. So do other packages that have been on CRAN for a while.

5) Put data into a separate package from functions. That makes maintenance easier and makes it easier for people to use your data sets in other contexts without having to put your functions on their search path.

6) I haven't done a check for consistent naming and coding, but if it is inconsistent, I recommend moving toward consistency unless there is a good reason not to do so.

ismayc commented 6 years ago

@rpruim Might I recommend that you create a PR that fixes these issues so that the reviewers of the package can review changes instead of being the ones having to do the work to make these changes? In general, it is helpful for feature requests such as this to be attempted at implementation by the person creating the request instead of just making requests without seeing how challenging it might be to make these changes.

I am not an author of this package but have found this process to be much more beneficial for other packages I have contributed to and it also provides a higher likelihood of implementation in my experience.

rpruim commented 6 years ago

@ismayc, I'm not going to invest time in this until I at least get a sense that it is wanted. Notice the title of the issue -- my first question is whether there is even openness to the making these sorts of changes. (The answer could vary by the change.)

I also don't have a good sense regarding where all these data sets are in use in the various Open Intro projects. So I don't think I'm in a good position to do the implementing, or to size up how much work it would be.

As for my R programming time in the near future -- it is mostly committed to maintaining my own packages. So aside from an exemplar or two, I'm not likely able to commit time to this.

ismayc commented 6 years ago

@rpruim Since this isn't my package, I'll let the package authors reply as needed and keep myself out of this. It's clear we have very different styles of how to request changes to open source packages. I've let previous issues you've created just sit unanswered because of the sheer amount of time it would have taken for me to investigate further but I thought it important that you see the viewpoints of other package authors today. A further discussion only further floods the inboxes of the package authors and I'd rather not do so as they have plenty to look at already today from all the issues created.

mine-cetinkaya-rundel commented 4 years ago

Much of these suggestions are now incorporated in the datasets that are moved from here to the openintro package.