Review Time-Frame

Do you always submit the reviews assigned to you on time? Putting it in a different way, do you even begin reading them a few days before the due deadline?

Lets restrict the discussion to journals like IEEE Trans. Signal Proc., which have a short but elastic time-frame for submission of reviews. Conferences and special-issue journals (e.g., JSAC) of course, have inelastic time-frames, so one has no choice but to stick to the deadline. While this always leads to timely reviews, the review quality may suffer. I've had my share of one-line reviews; ``The paper is good and a nice decodability criterion is established.''

From my brief stint at reviewing and submitting my own papers, I guess most graduate students would answer the above questions in negative. Some students, who tend to get several review requests, first look at the paper on the due date after emailing the associate editor for an extension. They usually get a two-week extension, which sometimes expands into two months - not funny when one is on the receiving end.

The truth is, graduate students do not always have spread-out research interests and often get assigned papers that are not exactly in their area. Mix in some procrastination and you have a delayed and lousy review. On the other extreme, students sometime get papers in their exact area as well. Reading the paper is then a delight, and the reviews mostly get done on time.

So how does one optimize one's timeliness ? Perhaps one could use waterfilling. That is, if the paper is outside one's area, realize that the review is going to be bad and get done with it, as soon as possible. The AE may not be impressed by the review but will at least get it on time, and may even decide to spend some time on the paper himself. On the other hand, if the paper is aligned with one's research interests, spend some time writing the review, even if it requires asking for an extension. The review should be extra long if it is a rejection; the authors should gain something out the process.

Plagiarism at IITK

There has been a serious accusation of plagiarism at the biotech dept at IITK. As if this was not bad enough, stories of several similar cases have surfaced from all other IITs. Of course, the Indian media has done its part headlining the graveness of the situation.

For an institute that claims to maintain the highest of the standards, even one such incident is unforgivable. In retrospect however, I think such an incident was bound to happen, sooner or later. When I was a student at IITK, I do not recall reading any emails from DOAA underlining the seriousness of scientific misconduct.

If I am allowed to guess, the students who copied from Wikipedia are not the back-stabbing villains portrayed by the media. Most probably, they were simply unaware of the fact that such blatant plagiarism is easy to spot and would cost them their careers. It is partly their adviser's fault for not predicting it and it is going to cost him his career too. Most of all however, it is the institute's fault for not sensitizing the faculty and students of the issue, especially in the backdrop of other recent cases in academia; see e.g., Hwang Woo-suk case in biology.

All in all, it was a jolt that the institute needed. The brand reputation has suffered but I am sure that we will emerge stronger from the ordeal.

Lab TAing

One of my colleague just got a TA ship and is in charge of teaching the electronics lab. Since I had TAed this lab previously, she approached me for any tips or tricks I had to offer. As I am always too eager to dole out advices, we had a good twenty-minute discussion on what one ought and ought-not to do. The gist of my advice was that role of the TA was to assist the students do the experiments without resorting to any kind of spoon-feeding. Towards this end, I would stress the importance of the following.

1. Do the experiment in advance, even if it is piece of cake. Performing the experiment yourself makes potential problems surface when there would seem to be none. Some of them may be really trivial, e.g., an experiment setup may be such that it may require three probes per person, and you may need to get extra probes beforehand. If the experiment is complicated, you could also jot down the possible mistakes students are going to make.

2. Ask the students to start doing the experiment as soon as they arrive, without waiting for the TA. The students should also be encouraged to skip a problem if they are struck if the TA is not available or busy somewhere. These practices help control congestion especially if you have a large class and for particularly difficult experiments.

3. Never tell the solution, always drop progressively easier hints. Not only will this make the students think harder but also make them smarter, taking some load off the TA's shoulders for future experiments. You could try to give the students some pointers in the beginning but the best practice is to let them figure out everything by themselves. However you must be available for hinting whenever they are struck.

4. Visit each student periodically, see what numerical values they obtained and whether they are in the ballpark. Encourage students to doubt their solutions and "feel" the circuit. The ability to approximately solve circuits is extremely important. When a student shows you his value, think aloud on how you would confirm that the value is approximately correct. Encourage the students to emulate this reasoning style.

5. Encourage proper report writing skills. Depending on the instructor/course, one may or may not have to submit lab reports and those require specific guidelines to be handed out. But the process of jotting down observed values in the lab is also important. Encourage students to write down everything, including what may have went wrong.

6. Drop examples of real-life applications where the said circuits are being used. It takes away the monotony of lab work.

7. Lab exams are the easy part (at least for the TA). These are days when you can relax while the students toil.

Apart from these, I also follow the philosophy that for the time a person is my student, "their business is my business." In particular, I remember a related incident where a co-TA's best student did not show up at the final exam. While discussing the grading policy later, I was surprised to learn from him that he did not even send an email inquiring his student about what had happened as "it was none of his business". I disagree with this ideology but do understand that it may be something cultural.

Proposal Reviews

I recently got an opportunity to review a couple of NSF proposals my professor gave me. Interestingly, one of the proposal was excellent while the other one was mediocre. I thus learned a lot comparing their writing styles.

For those new to the dojo, most state, army and private funding is procured by submitting proposals to the corresponding agencies which are mostly peer-reviewed. The intent of the proposal is to pose research problems, solving which would significantly advance the state of the art. These problems must somehow be related to the authors past work, thereby establishing his/her credibility. In the end, not all problems need to be solved. The idea instead is to establish concrete directions of future research that are promising not only for the author but for the entire community.

While I am no authority on proposal writing, I could point out some "common mistakes" I have noticed thus far.

1. Wish-list: The proposal should not sound like the future-work sections of conference papers. One cannot simply say that NP-hard problems will be investigated without explicating the exact approach. In fact each proposed problem must be devoted a couple of paragraphs at least: one formulating the problem and another giving an insight into the proposed solution methodology and possible challenges.
2. Text-only: Mathematics is a language. Use of equations helps express problems clearly. While it is necessary to keep the description at a higher level, one or two equations per-page is not scary at all.
3. Secret-designs: It is possible for a reviewer to pick up the proposed solution and start working on it. However, proposals which entice reviewers into taking up the problems are always considered the best and always get accepted. Its a risk that has to be taken.
4. Jargon-master: Peer reviewed proposals do not need to use DARPA-like jargon except probably beyond the summary. Buzzwords like cyber-infrastructure should not be used in a proposal that investigates routing protocols.
5. Can-be-generalized: The usefulness of running examples cannot be stressed more. However, generalizing toy-examples is often easier said than done. I have seen at least two proposals that described their approach on toy examples and left the problems at that stage.