[rkward-devel] RKTeaching [was: Usability: Reading CSV]

[Thomas Friedrichsmeier]

Hi!

On Fri, 9 Oct 2015 11:16:52 +0200
Alfredo Sánchez Alberca <asalber at ceu.es> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20151009/adc10967/attachment.sig>