[Gzz] ACM HT03: Paper Results (fwd)

[Asko Soukka]

---------- Forwarded message ----------
Date: Mon, 7 Apr 2003 16:12:22 +0100
From: Les Carr <address@hidden>
To: address@hidden
Subject: ACM HT03: Paper Results


I am sorry to inform you that your submission
        Bridging Javadoc and design documentation via UML diagram image maps
has not been chosen as a full paper for the ACM Hypertext 2003 conference. The 
procedures have been very thorough, and only 25% of the submissions were 
selected as full papers. Most papers were reviewed by 5 referees whose comments 
are attached below.

If you look at the Web site (www.ht03.org) you will see there are many 
categories of dissemination still available. You may wish to submit a version 
of your work in the form of a two-page Short paper, a four-page Technical 
Briefing, a Poster or a Demonstration (deadline for all categories 30th May).

The Program Committee is keen to see your work represented at the
conference in the following context:

*** The committee particularly felt that the results that you
describe would make an arresting poster. If you would be prepared
to submit a version of your work to appear in the conference poster
sessions, please email the Poster Chair address@hidden

*** The committee particularly felt that the results that you
describe are are of sufficient scientific value to warrant exposure
as a Short Paper. If you would be prepared to submit a version of
your work to appear as a Short paper, please email the Paper Chair
address@hidden



Thank you for your interest in HT03: as you can see from the web site there are 
many opportunities still available. We are anticipating a lively conference and 
would value your participation.
---
Les Carr & Lynda Hardman
HT03 PC CoChairs

===================== REVIEWS ====================
REVIEWER SCORE: 4
--------------------------------------------------------
REVIEWER SCORE: 4
***Comments to Authors
There are a number of minor errors and typos in the paper - I suggest proof
reading carefully. A few are:

- Categories and Subject Descriptors - there is a ; before D.2.2

- Table one "to fi nd" should be "to find"

- Sec 4.4. Para 2. "we keep it best" should this be "we think it best"?

- Sec 5.1 last two para. "final diagram 5 is compiled {new line} 4 from the
element}" should this be one paragraph without the 4?

- Sec 5.2. 1st para. "the treshold" should be "the threshold"

- Sec 5.2. last para. "but tehy clearly" should be "but they clearly"

- Sec 5.3. 4th para. "In the first phase 6 all reST.." is this a reference to
Figure 6?

                                    

***Summary Comments
This paper describes a set of software that is used to maintain hypertext links
between Javadoc code and higher level design documentation.

The paper describes what looks like a useable and useful system, however the
authors do not attempt to use any technology beyond simple linking and
references to previous hypertext systems work are thin on the ground (mainly SE
refs).

This means there is little reflection in the paper on how the system might
benefit from/influence discussion of common hypermedia ideas. There is no 
attempt
to manage the link structures independently or adapt the view of the 
documentation
for example. In addition the link model used is no more than automated hrefs.

Thus while the paper does a reasonable job of presenting the work, it does not
really contribute to the larger research field in any way. What are the lessons
that hypertext designers, authors etc. should take away with them, other than
that this is an interesting tool to use in their java development?

To be published here the authors need to work harder to position their system in
relation to existing HT work. It would also be nice to see some trials detailed
to look at whether linking in design docs is really useful, and which types of
linking are most critical.

                                    

--------------------------------------------------------
REVIEWER SCORE: 7
***Comments to Authors
You are working on an important problem and you have both built some good tools 
and applied them to a good example problem.  Thus, I am giving your paper 
pretty strong support.

However, the paper has substantial flaws that you need to correct if you want 
it to be remembered three years from now.

First, the writing is very inconsistent and in places is rather weak.  There 
are problems at the grammatic and spelling level that are too numerous to name. 
 This is especially true in sections 4 and 5.  

There are also organizational and content problems that you need to address.  
For this to be an effective scholarly document, it needs to address other 
attempts to build systems for connecting software documents.  Find the 
following and decide whether you should cite it:
-- Work by Ellis Horowitz and students on SODOS and DOC (is this correct?).
-- HyperTies system by Osterbye (name is missing Danish accent characters)
-- Work by Maletic on automatically finding connections among software 
documents using LSI
-- Berkeley PhD dissertation by Linton on using RDBMS to store program analysis 
information
-- Yi-Farn Chen`s CHIME system for linking software documents
-- Requirements traceability research
I guess my point is that you`re telling us what technology you`ve considered 
and you do show that you`ve read a number of the obvious documents on Web and 
HT interfaces.  However, you haven`t shown that you`ve thought about the prior 
scholarly work on managing software documents.  Yours is not the first system 
to link software documents and you haven`t shown very clearly why I should 
think that it is important.

Why are UML diagrams the right point for connecting software documents?  Can 
they replace an alphabetized index or table of contents?  Do you need more ways 
to make connections?  Are you thinking about linking other types of software 
documents (bug reports, requirements, user manuals, testing results)?

Your paper spends too much time telling us the sequence of design and 
technology choices that you`ve made.  Section 4.3 is a clear example of this.  
It lists evolutionary steps on the way to full linking through the UML image 
maps.  I don`t see what I learn from this sequence.  What is the key message 
here that I am supposed to remember? 

Some of the writing seems to worry too much about whether or not software is 
Free.  I like Free Software, but I don`t think has a very sustainable economic 
model for many classes of software.  Thus, I see "Freeness" as something to 
mention when you are telling me whether or not (and how) I can get your 
software.  I don`t see "Freeness" as a critical quality in and of itself.

In summary, you have indeed built some cool software that would be useful to 
lots of people.  That`s neat and it`s interesting to hear how you designed it.  
But you need to take a step backward, read some relevant literature (cite some 
of it, too), and change the paper so that it spends some time explaining how 
you have improved on these earlier systems.
                                    

***Summary Comments
This paper describes how the Gzz project has built a system of tools that allow 
them to link design documents with Javadoc using UML image maps as an 
intermediate linking point.  
                                    

--------------------------------------------------------
REVIEWER SCORE: 4
***Comments to Authors
An excellent conceptual advance and apparently impressive implementation, but a 
woefully inadequate description and presentation of the paper.

There are numerous (~100) small typographical errors, and many inconsistencies 
in referring to figures.

Fragments lacking sufficient explanation: Table 2, Figure 1 (particularly 
opaque), Figure 2, Figure 3 and Figure 6. Figures 7 and 8 are too extensive, 
and captions talk about colours not available in the black and white paper. 
Section 6 should include develop an actual example of use of the tools.
                                    

***Summary Comments
An impressive, novel concept that is really badly described. The authors should 
consider a major rewrite.
                                    

--------------------------------------------------------
REVIEWER SCORE: 5
***Comments to Authors
Comments to Authors:
Revise the paper to correct spelling, grammar and repetition of information and 
to improve readability.

Provide experience of users/software developers in using the proposed scheme, 
if available.
                                    

***Summary Comments

                                    

--------------------------------------------------------
***Comments to Authors
Your paper presents a solid piece of work to solve a specific problem.
Overall the reviewers found that this was highly relevant to the Hypertext
conference.  However, it is more an experience paper than a research paper,
and it suffers from low readability in places, as well as a related work
section which could be improved.  You have created a nice tool, but what are
the general lessons?  What is the relevance of Free Software in this
context, research wise?  How does your tool actually improve developers`
work or performance?  As it stands, your paper is suitable for either a
poster or short paper, where you can focus on the (research) contribution of
your experiences.  Given a rewrite addressing the concerns listed above and
by the reviewers, I have no doubt that you can submit a really strong full
paper for next year`s Hypertext conference.
                                    

***Summary Comments

                                    

--------------------------------------------------------