Hôm nay vừa được thông báo kết quả 2 paper nộp hồi tháng 4 cho ICSM (International Conference in Software Maintenance), hội nghị được coi là top trong ngành hẹp Software Maintenance của Software Engineering. Acceptance rate năm nay là 35/162 = 22%, tức là cỡ 5 bài nộp thì 1 bài được nhận.
Kết quả không được thỏa mãn lắm. Nhóm tớ nộp 2 bài, một bài được nhận dạng short paper. Acceptance rate cộng chung với full paper là (35+29)/162 = 40%. Một bài thì bị reject.
Ngay từ khi nộp tớ đã nghĩ là bài thứ hai sẽ khó được nhận, vì phần evaluation quá dở: cài đặt chưa tốt, kết quả rất thấp so với các phương pháp khác (ngoại trừ thời gian thì rất nhanh). Các review cũng nhận định như vậy. Họ rất khen về giải pháp và cách trình bày (the main idea is solid; combined with editing for clarity this paper can be very competitive; is admirable for the formal and complete presentation of a traceability link recovery framework; easy to understand and generally well written). Tất nhiên phần eval thì bị chê tơi bời (this paper needs an expanded evaluation including decisive discussion and comparisons over a more convincing number of parameter variations; lack of examples; the results are not justified, the recall is low and the precision may not be accurate).
Kinh nghiệm cho paper này là phần eval thiếu thuyết phục. Nhưng quả thật trong 3 tuần khó mà làm mọi thứ một cách nghiêm chỉnh và đầy đủ được. Nhất là khi phải chuẩn bị cả 2 paper một lúc.
Bài còn lại thì cả nhóm đều chắc mẩm là phải được full paper, vì mọi thứ đều rất ổn. Thế mà các reviewer chê tơi bời nên chỉ được nhận short paper. Họ bảo bọn tớ không compare tool của mình với các tool tương tự. Tớ đoán là các reviewer chắc chắn là các tác giả của các tool đó và họ không hài lòng vì bọn tớ không compare nhưng lại so sánh trong phần related work là tool của bọn tớ ngon hơn. Họ cho là không fair. Điều này cũng có thể đúng vì bọn tớ chỉ so sánh thông qua con số trong paper chứ không chạy lại.
Kinh nghiệm cho bài này là ở một vấn đề mà đã có nhiều người làm quá rồi, thì phải eval và viết related work thận trọng, không nên claim strong quá làm các reviewer phật lòng. Nhưng có lẽ tốt nhất là nên xử lí những vấn đề mới hoặc giải pháp lạ mà ít người đã làm hoặc đã nghĩ ra.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment