Birds of a feather flock together.
Our affiliation does reflect our own quality to some degree.
On the other hand, the prestige of institutions is becoming less important due to the internet and social media.
And really top people can transform a not-so-top institution into a top one.
It is fine to have creative or personalized email addresses, but use your judgement, e.g. sexybaby@hotmail.com is probably not suitable for professional communications.
If you have multiple email accounts which you cannot check with sufficient frequency, just set automatic forwarding to a single (default) account. You can also setup (e.g. via SMTP) that single default account to reply on behalf of the other aliases.
If you do not intend to use a particular email account, disable or delete it so that people would not expect reply from there.
The deadline is approaching and we have this paper that might or might not be ready. Should we submit?
A lot can be learned only by going through actually paper review cycles. So it pays off to do our best to meet the deadline.
On the other hand, a bad submission might get its potentially good ideas scooped by the reviewers without receiving much useful feedback.
Thus, I recommend submitting only those with a reasonable chance of getting accepted but let the first author make the final call as the tie breaker.
A related post: why strong labs sometimes submit weak papers
Never, ever, send your code to others and ask them to debug whatever functional or performance issues you have.
That is the most effective way to signal you being a liability rather than an asset. It is like asking others to wipe your ass for you.
Spend time figuring out what is going on inside your own code, and ask specific questions if you need help. Take a look at stackoverflow.com, a good forum for coding questions.
If you are a university professor and you boast on social networks about sending your students to other schools for higher degrees, you are essentially acknowledging that you (and your school) are not as good.
You should be able to understand and implement an existing research paper (e.g. SIGGRAPH) or software system (e.g. a renderer/simulator) as well as reproduce the corresponding results.
Otherwise, you are not ready for a research or even a development position.
As a reference point, my first HKU PhD student, Jun Xing, once managed to reproduce 3 SIGGRAPH papers in a span of about 5 days (for sports).
Here is my current workflow to produce a video or prepare a talk for a research project.
Write down the story/script in plain text and rough drawings. Do not use any specific media at this early stage as it can prematurely limit our creativity.
Commit the script into a storyboard via slides (e.g. PowerPoint).
I then gradually flesh out the storyboard into a video and talk using the same set of slide files. This might sound unusual, so let me explain.
Start with video. When I was in grad school I learned time-line based tools (e.g. Adobe Premiere) to author and edit videos. But recently I found it more natural to use slides instead of time-lines for research videos. The main reason is that a research video usually contains short video segments glued together by narration, which involves more storyboarding than time-line manipulation.
I first produce the individual video segments using specific tools (e.g. dumping individual frames from my renderer and convert them into a video via MovieMaker), and embed them into PowerPoint slides. PowerPoint provides a rich set of tools for annotation, animation, and transition, which I find handy (and harder to do via Adobe Premiere). I automate all object animations and slide transitions, and dump the entire project into a video file.
I submit the video along with the paper, and go screw around.
PowerPoint allows flexible manual control, but it can be tedious due to lack of automation/scripting tools. Thus, it is important to properly decompose the above process into (1) automatic creation of (video) components and (2) manual insertion/combination of these components into the slides. It is a trade-off among quality, control, and manual labor.
When the time comes to prepare the talk, I can simply start with my slide file, which already contains the script, the video segments, and associated effects. I just need to turn off those automatic animations and transitions that I wish to manual control, and add additional information for a talk, usually verbal stuff such as previous works, algorithm details, and future directions.
I find this much more efficient than starting new slides from scratch.
I also find that for those projects that I were too lazy/busy to make videos, the talk slides I ended up doing are often not too far from being videos.
It is almost always a good idea to have a video to present the gist of our project in a few minutes, more appealing and efficient than absorbing the same amount of information from reading the paper.
Presenting algorithms is a good exercise to think and talk in an intuitive and straightforward manner. Hard to do when facing a deadline, but I like to prepare the presentation while writing the paper.
As an example, here is an early version of the video-slide file for my siga14 paper autocomplete painting repetitions.
There is a course in the upcoming SIGGRAPH Asia 2014 conference on how to make a SIGGRAPH paper.
The content has not been completed decided. If there is anything particular you like to hear about, feel free to leave a comment below within the next 13 days. You can do so with anonymous or real identity.
Please also help spread and share this.
Theme: Rubric. Get a free blog at WordPress.com