Am Montag 15 November 2010, 17:12:54 schrieb Thomas Friedrichsmeier:
> 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
> 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
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
> > - 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?