[rkward-devel] JSS paper, round 2

Mon Nov 15 16:12:54 UTC 2010

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/commented_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).

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.

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.

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 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.
> 
> - 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.
> 
> - 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'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.

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

> - 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.

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?

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20101115/12e02957/attachment.sig>