| |||||||||||||
Android, forking, and controlAndroid, forking, and controlPosted Jun 9, 2011 10:09 UTC (Thu) by modernjazz (guest, #4185)In reply to: Android, forking, and control by swetland Parent article: Android, forking, and control
> At a certain point, it's easy to get the impression that your time is intentionally being wasted by
> people who have no interest in ever accepting your work.
For what it's worth, this isn't unique to kernel patch review: I suspect that almost anyone who has been in academia long enough has a story about how one of their papers has been "held hostage" by a reviewer who appears to be motivated by delaying its publication. And while I'm sure there are cases where that's really true, I think more commonly the true source of "obnoxious" reviews are people not understanding or appreciating what you're trying to do. Perhaps the main culprit is lack of time: if you aggregate all the different forms of review together (student exams and presentations, papers, grants, and administrative proposals), a typical academic may spend more time evaluating other people's work than doing his/her own research. That adds a lot of time pressure to get reviews done quickly, and contributes to occasional sloppiness. It's the dark underbelly of a system that, despite its warts, is basically necessary for any large undertaking to make progress.
I'm not saying this is what happened in the case of Android (I don't know enough about the details to know), but just a bit of outside perspective on the weaknesses of review processes in general. I suspect there's no way to avoid problems altogether, but one positive step might be more recognition for people who do a good, conscientious job of reviewing.
(Log in to post comments)
Android, forking, and control Posted Jun 9, 2011 15:47 UTC (Thu) by PaulMcKenney (subscriber, #9624) [Link]
Heh! It did take me about ten years from first submission to high-end-academic conference acceptance of an RCU-related article. The first article in a high-end academic journal giving a detailed description of RCU will likely appear within a year or so, about 15 years after first submission.
About five years of that time was due to me learning how to describe RCU coherently to an academic audience. For the rest of the time spent, the issues described in the parent article apply, particularly the part about lack of time. All too often academics are doing their review in the wee hours of the morning, which makes it hard for them to wrap their heads around something truly new and foreign. So a successful academic paper needs to be sailing some place new, but it had better be sailing really close to shore.
So again, this comes down to communication: papers where the reviewer can quickly and easily understand what is new and interesting about the submission are more readily accepted than papers that cover less-familiar material. So in that sense, yes, this problem is inherent in review in general, not just review of kernel patches.
|
|||||||||||||