Team Guidelines

First things first... Welcome to my team!

Below is a set of guidelines to working with me. This is supposed to act as a README for my team members, and it saves me repeating certain things in separate conversations.

Team work

• We all bring different knowledge and expertise to the team. I will learn from you more than you know. Therefore, don't be economical with your knowledge. Always try to think of how to help others, and also to learn from them.
• Be true to who you are. Know your strengths (and use them) and your weaknesses (and work on them). As such, know when to take the lead, and when to say "I don't know". This is a very important part of collaborative work.
• More on the previous point (copied from Charlie Ebersole): "Wanting to look competent is natural and useful in some settings. However, it’s also important to admit when you don’t know things. Acting like you know more than you do stifles opportunities for others to teach you new things. This is probably going to be an ongoing struggle; that’s ok. Let me know how I can make it easier for you to say when you don’t know things."

Looking after yourself

• Let's state the obvious: you are allowed weekends and holidays! I am also happy for you to take more time off when needed. Just keep me in the picture and we can plan these things together.
• Make sure you work effectively and rest well. Exercise regularly, and be conscious of staying fit and healthy. I personally have neglected this during my own PhD, and paid the price in multiple back and knee injuries that I still work around today.
• Life is much more than work. I want you to be happy and have a good life. Draw clear boundaries and enjoy your life experiences both at work and outside.
• Work is more than this degree/job. Keep me abreast of what you want to do next and I will try to create suitable opportunites for you to develop yourself, making your CV as strong as possible for your next step.

Notes

• Take notes profusely. Document your processes, thoughts, and reflections. It might seem counterintuitive, but this way you'll accelerate your progress. There is a reason why so many good scientists keep lab diaries.
• Come up with a simple system of managing your notes (don't go overboard with this). Once you set this up, you'll be able to just focus on "thinking out on paper". This is greatly beneficial at different stages of developing and documenting your research.
• Learn how to ask good questions. Here are some tips.
• When reading other literature, make sure that you paraphrase immediately when taking notes. If you're anything like me, you'll forget if that well-phrased sentence is your own or copied-and-pasted from a paper. This could obviously land you in hot water. Avoid it by always paraphrasing at ingestion.

Software

The following choices are a result of experimenting with a wide range of solutions over the years. I find these to yield the best results in terms of producing reliable and high quality output, and good support in the academic community. By aligning to these, you will also facilitate effective collaborative work with myself and other group members.
• For documents: LaTeX. See notes below.
• For references: Bibtex. See notes below.
• For presentations: Anything but Prezi.
• For posters: I would avoid PowerPoint if possible, it was not designed for this. I recommend Scribus or LaTeX, but other options are also available. See notes below.
• For plots: I don't really have a strong preference as long as (1) the output looks professional and (2) the tool is 'script-able', i.e. you don't need to waste your time manually plotting or calibrating every time the data changes. You want a script that you can execute and get the output you want. Suggestions: ggplot (R), Matplotlib or pandas (Python), gnuplot.

Preparing manuscripts

• For collaborative document editing, I prefer something like Overleaf over git due to its ease, especially real-time editing. If git is unavoidable, then separate all sections into separate documents and use \input.
• Name your manuscript using this format: (your first name)-(venue name)-(venue year), without the brackets. Example: faiza-noms-2016
• If you're leading, make it super clear who's doing what and when.
• Put the URL of the CfP as a comment at the very first line of the main document. This saves us all needless web searches to refer back to the call specifics (deadline, page limit, guidelines, etc.).
• Always assume a time-constrained reviewer. Your job is to make them interested and spend the time to read your work properly.
• Follow the venue rules. Learn what the page/word limit is, the required format and variations thereof for review/cam-ready/etc., single or double blind, bibliography format, and so on.
• Know the unwritten venue rules: What does this community value? What do they look for in a publication? What is their philosophy on design/evaluation/implications? If you are not familiar with the venue, read relevant past papers and, if you can, speak to someone who published there.
• Learn the basics of writing. Yes, seriously! By basics I mean things like: weaving flow between sections, capitalising titles of sections/subsections, etc. This is especially important for those who consider themselves good writers, as they tend to develop blindness of their faults. You would not believe the amount of time spent fixing such fundamental issues while getting manuscripts ready for submission.
• Do not write the abstract until the rest of the paper is pretty much done. Once the paper is accepted, go back and make sure that the abstract is easily digestable by a non-specialist.
• Put the Related Work section towards the end of the paper. It is usually easier to talk about the "competition" once you already introduced your own work. There are exceptions, of course, especially if motivation is very deeply rooted in the state of the art.
• I'm generally against the "The remainder of this paper is organised as follows..." bit. It adds nothing unless the paper is a behemoth that seriously needs sign-posting at that level. The majority of papers are (should!) not.
• Use Oxford commas.
• Tables and diagrams should be self-explanatory. Along with working on the content itself, make the titles/captions expository.
• Be as consistent as possible in how tables and diagrams are formatted across the whole document.
• Diagrams should be reasonably scaled. A good rule of thumb is that text size inside the diagram should be the same or slightly smaller than the normal text in the rest of the paper.
• Never skew diagrams. Always maintain the original aspect ratio.

References

• Refer to the bibtex file shared within our team (ask me if you don't have access), which will have a collection of major works that are of relevance to our work. Augment this with your own separate file that contains references you collect that are directly related to your own work. If you come across something that you think is of relevance to the rest of the team, present it during the regular team meeting and we'll add it to the shared bibtex if we agree.
• I'm very picky about how references appear in my papers. They need to have full information, be presented in a consistent format, and without redundant information (e.g. tag-ons to conference titles like "Seventeenth", "International", "Annual", etc. You can easily spot these as they do not form part of the acronym).
• To achieve the above, you will need to tidy up the bibtex you get from the internet. IEEE is perhaps the worst with so many faults (author first names are usually abbreviated, venue name is broken into 2 parts, the year is repeated in the conference title, and much more). Google Scholar bibtex is usually incomplete and sometimes inaccurate, so always double check it or just grab the original bibtex from the website of the publisher or the author(s).
• Learn the difference between \cite and \citet. In brief: the former is used for pointing to a reference, the latter is used when the reference is itself a subject in your sentence.
• When multiple references are cited in the same place in the paper, use a consistent order within the citation points in the text. Chronological (in either direction) is a good rule of thumb. Relevance also works, but can get confusing quite quickly if the list is long, which is why I prefer chronological. Some packages (like natbib and biblatex) allow you to do this automatically.

Posters

• Good advice for preparing posters: The Talk-First strategy, and Tullio Rossi's guidelines.
• Advice on LaTeX posters: Quick and easy posters in LateX.
• If you're travelling with the poster, print on fabric not paper or card.

Co-authorship

Because there is no universal policy on co-authorship even within a single field of science, here is my take on it.
• The first author is the leader of the study, period. This is the person who has driven the work (including any required design, implementation, experiments, analysis, etc.), led the investigation, and managed the contributions of different collaborators. Note that "conceiving the idea" is not on the list, as it means very little if the work to realise it is not done.
• I have been stung with author order in the past, and it hurts. So, one of my highest priorities as a team leader is to make sure this does not happen within my team and with my collaborators. I will strive to be fair with everyone, and this works both ways. If you deserve to be up the author order, I will see to that happening. If you do not do your part and lead the work, I will move you down the order. If you do not contribute, I will remove your name.
• For the above to be realised, we need to have honest and open conversations about this. These are not fun conversations, and they are as uncomfortable to me as they might be to you. But experience has taught me that being sincere and candid is the only way of avoiding awkwardness and bitterness. So please approach this aspect of the work with this in mind.
• If you sense a conflict, please bring it up with me. Side conversations will not accomplish much in terms of positive outcome.

Feedback

Research and collaborative work are both very feedback-centric. You'll have to learn how to give and receive feedback.
• Talk to your colleagues, both within and outside our team. Discussions (whether thrilling or dull) stimulate the mind and trigger healthy reflections, let alone facilitate the exchange of ideas. Make use of having so many other researchers around you!
• Creative work often comes with a super-sized side of negative feedback. A lot of it will come from me (you're welcome :), as that's part of my job. Not giving you feedback that allows you to work on improving different skills would be doing you an injustice.
• If you think I've not given you enough feedback, ask me for more.
• On paper rejection: I understand that this could at times feel quite hurtful and discouraging. Just remember that (1) this happens to everyone, (2) there is more randomness and bias in the process that what any sane person would like, and (3) this is an opportunity to learn from and improve. (I recommend reading Veronika Cheplygina's "How I Fail" series and Niklas Elmqvist's reflections.)
• Don't forget to give me feedback. I'm only human after all! :)