[rkward-devel] JSS paper, round 2

[Stefan Rödiger]

Am Montag 15 November 2010, 17:12:54 schrieb Thomas Friedrichsmeier:
> Hi,
> 
> I'll break the threading in order to bring this mail up to the top of my
> inbox. Using threaded view, I had to scroll a looong way down in kmail.
> I'll also quote everything from Stefan's mail, and my first reply, so you
> can send any subsequent replies to this new thread.
> 
> On Saturday 13 November 2010, Thomas Friedrichsmeier wrote:
> > Hi,
> > 
> > On Saturday 13 November 2010, Stefan Rödiger wrote:
> > > Thomas gave me a kind reminder to add the next version of the JSS paper
> > > to SVN. If you want add your content and make changes. Maybe you could
> > > give a brief feedback on the list what you plan and how long it likely
> > > will take.
> 
> --- Adding a break, here, just so you don't skip over Stefan's question
> ;-). Knowing what contributions to expect when is crucial to coordinating
> the remaining work.
> 
> > I've started adding my comments. I'm roughly half-way through the paper
> > so far, so with a bit of luck I can give you my revision by the end of
> > the weekend. Much of what I'm doing is editing for style and moving a
> > few sentences around. I'll address the larger issues by mail (and I'll
> > make a start, below).
> 
> Ok, took me a while longer to get finished. Get my version via "svn up" or
> from
> http://rkward.svn.sourceforge.net/viewvc/rkward/branches/jss_dec_10/commen
> ted_versions/rkward_jss_thomas.odt?revision=3188 .
> 
> I found structure of the "usage" chapter (currently: number 6) a bit
> confusing. It seemed to be arranged along several different lines at once:
> The GUI concepts and technologies employed, the layout of the main window,
> and a task oriented ordering. I've tried to sort this out a bit. Now there
> is one section (the first sub-chapter) describing the layout of the main
> window, and the generic window management / customization features. Then
> there is typically one section per type of tool view / document view. I
> think breaking it down that way is probably an improvement, although I am
> *not* convinced, that the current order of the sub-chapters is optimal. We
> will probably want to re-arrange those (but they are fairly independent,
> so not a big deal).
> 

Okay. I'll will give my thoughts on it later.

> I've also edited liberally, shortened, here, extended there, and moved
> sentences around. All in all this makes the change-tracking *look* as if I
> had changed just about anything about this chapter. While this is not
> quite true, I do wonder, how to proceed from this, best, since it will
> probably make merging other people's changes quite a feat.
> 
> Stefan, ideally, *if* you have the time right now, I think it would be
> good, if you could go through my changes, accept the ones you like, and
> upload a new version, for everybody else to work with.
> 

Okay. I'll upload the new version till Wednesday.

> Failing that, but hoping you have *some* time, at the moment, perhaps you
> can still skim through the changes to make sure you are ok with the
> general direction of my changes. Then others can base their edits /
> comments on my version, and we can sort out any fine points that you do
> not agree with, later.
> 

I did a bit an consent mainly if not to all.

> Failing that, it's probably still a good idea for the rest of you to take
> my version as a base for your comments / edits, as it's also a bit more
> complete.
> 

I second that.

> > I see that I've also promised to look up a whole bunch of references.
> > I'll do that separately, as it will probably take some time, and
> > probably doesn't block any other work.
> > 
> > > Meik & Thomas: As far as I remember you worked on a plugin download
> > > feature. Is this something to include?
> > 
> > I'm added a short note that this is under development. Since this feature
> > is not in an official release so far (and we'll need to do some more work
> > on the details, too), there's not much we can write about this so far.
> > 
> > > Prasenjit: You worked on the plot history feature. I already added some
> > > notes to the manuscript. It would be great if you could write this
> > > section.
> > 
> > I've moved those bits from the "technical" section to the "usage"
> > section. Of course adding some detail on the implementation will also be
> > interesting. So actually there's two places to edit for this feature.
> 
> I've added a short bit to the "usage" section. It's sort of a shame to
> write so little about such a cool feature, but I think going into more
> detail will not be too exciting at this point.
> 
> Prasenjit, if you have some time to add a few words about the
> implementation to the "technical" chapter, that would be good.
> 
> > My "broad" comments so far:
> > - The paper looks quite comprehensive. Reading it, I see we have a lot to
> > show, and I think we're on a good track, overall.
> > 
> > - The "technical" section has a lot of forward references to the "usage"
> > section. I think it should be moved behind that. As far as I can see this
> > will require almost no changes to the remainder of the text. I didn't do
> > that, as it would have defeated the change-tracking, though.
> > 

We keep that in mind and postpone it for the moment being.

> > - I know you put a good amount of thought and work into chapter 5 (about
> > download numbers and LOC). But I'm afraid I feel it makes the article
> > weaker, rather than stronger. You said the main purpose of this chapter
> > is to demonstrate that RKWard is an established and actively developed
> > project. But I think we show that quite well in the usage and technical
> > sections, too. And I don't think the data we can realistically gather
> > for this section is sound enough to add anything substantive to this. I
> > don't think the reviewers will accept this, but even if they did, I
> > think it would rather raise some eyebrows, instead of help the paper.
> > 

Okay. Actually it was not that much work just an idea. That's scientific work. 
Elaborate, evaluate, discuss, then use or dismiss. ;)

> > - Chapter 8 (the comparison) is beyond the scope of the article, too, I
> > think. It's a good summary, and we should put it somewhere, for instance
> > in the R wiki: http://rwiki.sciviews.org/doku.php?id=guis:projects . But
> > the JSS will publish a whole series on R GUIs, with separate articles on
> > the different GUIs. Chapter 8 looks more like a summary to that entire
> > (yet to be published) series of articles, rather than to our article on
> > RKWard. Of course it still makes sense to compare RKWard to the
> > competition, as we already do at several places in the article. Just that
> > summary table is not ours to make, I think.

I also second that. After I started to review available information during the 
last weeks I came to the realisation that this would become a never ending 
story anyways. For example Cantor has these days many features which were 
planned distinction from RKWard. Moreover there are so many GUIs / IDEs for R 
... 

> > 
> > - I'm not sure, what you were up to with chapter 9. If you're looking for
> > a sample use case, I'd suggest to make up a very straight-forward case:
> > 1. Import data from CSV. 2. Conduct a t-test on that. 3. Create a plot.
> > 4. Edit the generated R plot code to achieve some fancy effect, such as
> > a background image, or whatnot. I'm not entirely sure, whether such a
> > use-szenario is needed at all, though.
> 

The example would have been some GUI element for Bioconductor. But That's to 
much since even Bioconductor is unfortunately not "part" of RKWard. Lately I 
worked with some packages. Really nice.
Regarding the example I think this is something to go for though I think that 
is really a lot.

> I've added a basic outline for that as chapter 7. Of course it's not yet
> written. Volunteers?

Let's say feedback till end of the week? If nobody steps in here I'll start 
it.

> > - We could pick up the t-test as a sample plugin for the "Programmers'
> > Niche". The "programmers' niche" could be moved to the appendix, and
> > would need very little explanatory text besides the code. We already
> > have a good deal on the plugin framework in the "technical" chapter, and
> > we can't include a complete reference, anyway.
> 

Okay. I planned something more simple (Wilcoxon test) since it has few 
features but t-test is fine since it is a common work horse.

> One more item:
> - Screenshots: I like your selection of screenshots. However, I'm afraid,
> we'll need all screenshots in English. Any volunteers to work on
> re-creating the screenshots?

They are just placeholders/reminder. Even if they would be in English they 
wouldn't have the quality for publishing anyways.  I think first we should tag 
which stay, which go out and we some are needed. For example the "RKWard 
special paste" GUI was something I almost have overseen. I'm not aware of a 
competitive product with such functionality. Am I wrong here? Is there some 
some more functionality unique to RKWard and not obvious to the user?

> 
> Regards
> Thomas

Regards
Stefan