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 ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
