Hi! On Fri, 9 Oct 2015 11:16:52 +0200 Alfredo Sánchez Alberca <[email protected]> wrote: > Well, certainly the package includes a lot of stuff that I use in my > classes, as for example a Biostatistics tutorial and data sets, that > can be ruled out from the base package.
True, may not be something to worry about, right now. But at least the data sets may still be a very useful addition in the mid term. (A biostatistics tutorial does sound like something that would make more sense distributed separately.) > After thinking a little bit about how to split the package, I think > there are two possibilities. One of them is the one you proposes, > from the perspective of GUIs involved, and the other one is from a > teaching persective, that is, packing procedures according to the > contents blocks covered in an typical Statistics course. A structure > like this: [...] > May be your proposal is easier to implement, but from a point of view > of teaching, that is the main purpose of the package, this other one > may have more sense. > > We should give though to pros and cons of both proposals. I think there will not be _that_ much of a difference in the amount of work involved in implementing either proposal, so I'll side with yours. Currently, the first purpose is to split "the problem" into more manageable chunks - either proposal is good for that. The second purpose will be to offer a useful structure to users, e.g. so they can enable those parts of the GUI-functionality that are relevant to their current (teaching) purpose. Your proposal for splitting does require a slight bit more familiarity with what each plugin is doing, so in practice, the difference is probably that in your proposal, you are going to be the one to be responsible for handling the split. Just to add one more degree of freedom: The split does not _have_ to happen at the level of the R package. You could also go with a single R package split into several .pluginmaps. Since RKWard 0.6.3, it is rather easy to enable / disable installed .pluginmaps on the fly. .pluginmaps would be hidden until they are suitable for release, i.e. there would be a single rk.Teaching package which would appear to grow to cover all areas, slowly. The difference between these approaches may be subtle, but I think it might offer a bit more flexibility to change the structure of things later on. Thus, for instance, we could go with a "dumb" split by GUI-menu in order to get started, quickly, but transition to a "smart" split by topic, when time allows. We'd still cause some minor breakage on the users' end, but nothing like orphaned packages, etc. All this aside, Meik has offered to give you a hand, and I'll also renew my offer to help on the technical side. Just to lay out a rough plan on how we could handle this, I'll suggest: 1. We agree on the details of the (initial) split. You provide a list of plugins (or existing .pluginmaps) for at least the first block of plugins. 2. We agree on a place to handle the work (probably some repo on github; could be at https://github.com/rkward-community/external-plugins, or could be "at your place") 3. We set up the repo and file structure as agreed upon. (Could be handled by Meik or me). 4. We focus on the first block of plugins, where - You would be the key person to handle the translation from Spanish to English. - I could take care of adding i18n()-calls to the .js-files as required, also bringing in some of the more recent goodies that help reducing the amount of repetition of UI-labels (which can also cause problems with translatability in some cases). - Meik and I could help with writing some .rkh-files and automated tests (though this may not be a top priority). - Meik would upload new releases once a block of plugins is ready. (These roles may not have to be strictly defined, just trying to outline where our respective skills might fit in, best). Regards Thomas
pgpfEugi7giqd.pgp
Description: OpenPGP digital signature
_______________________________________________ rkward-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/rkward-devel
