Technical Writing and Research Advice

Updates can be found in this blog post and in this blog post.

The ARC project team found the following resources useful:

1. Writing for Busy People, a rambling by G. Hohpe lists some essentials and suggests books
2. Mastering Scientific and Medical Writing - A Self-Help Guide by S. Rogers, Springer-Verlag (you might be able to find a PDF version elsewhere)
3. Texten für die Technik, A. Baumert and A. Verhein-Jarren, Springer-Verlag (in German)
4. Corresponding project plans, updates, results online? Avoid some common e-mail anti patterns.
5. Last but not least in this list: a pointers to information about netiquette.

The patterns community also has a lot to offer when it comes to technical writing (and knowledge sharing): 

1. The  Hillside Group gives advice here (e.g. there is a pattern languages for pattern writing)
2. Ward Cunningham’s Wiki is rich in content (by the way, this is first wiki that has *ever* been built) 
3. Linda Rising’s Pattern Almanac lists and summarizes patterns published prior to 2000
4. Writer's Workshops are an intense way to improve technical writing (not just patterns) 

For more patterns history, read  Twenty Years of Patterns' Impact,  by G. Hohpe, R. Wirfs-Brock, J. Yoder, and O. Zimmermann, IEEE Software, Volume 30, Number 6 (2013).

For advice on research projects and thesis writing, start here:

1. Tips and links compiled by M. Jazayeri, USI Lugano
2. How to organize a thesis, J. W. Chinneck, Carleton
3. How to do research, S. Miksch, TU Vienna

When planning and executing validation activities, make sure to follow the guidelines in the Mini Tutorial by M. Shaw from ICSE 2003, Writing Good Software Engineering Research Papers and/or this presentation by I. Malavolta. The Design Science Methodology and supporting tutorial prsentations by R. Wieringa give even more advice.  This Technical Report from the SEI has information on how to conduct surveys. A former editor-in-chief of IEE Software writes about how to write high quality papers (for IEEE Software).

Remember these review dimensions (for research papers): a) relevance of paper content and research contribution, b) quality of content/contribution: technical soundness, depth, novelty, c) research approach/method incuding validation and d) editorial quality and maturity. If you want to make the reviewers' job as easy as possible (which is a good thing), help them answer these questions:

• Does the paper type get clear and match with the Call for Papers (CFP), e.g., full research paper vs. emerging/short vs. experience report?
• Is the context established (domain/area, previous work)?
• Is the research problem motivated and articulated well? Is it relevant w.r.t. CFP and in general, is it open or partially open (so not solved yet)?
• Is the research contribution convincing? Does it solve the problem, is it new, does it advance the state of the art sufficiently (over existing work from same authors and from others in community, both academia and industry)? Is the contribution comprehensive and mature enough for the publication type (workshop, conference, journal)? Does it work (in theory, in practice)? Does the paper contain enough information to reproduce the research results?
• Does the paper contain a validation section? Which validation method/form was used (e.g. implementation, case study, action research, survey), and is the chosen method adequate for the presented contribution type? How deep do the validation and its presentation in the paper go (e.g., application to fictitious example vs. real-world scenario/data)? Are the validation results convincing (or at least good enough to stimulate interesting discussions at the event)?
• Is related work discussed (so not just listed, but analyzed and compared with contribution? Are the references balanced and diverse enough  (in terms of age, communities, authors, publication types)?
• Is the editorial quality sufficient: mix of/balance between text and figures, use of notation(s), number of typos and language flaws (wording, grammar), flow? Are the figures readable (online, in print)?

If you want to switch your perspective and put on the reviewer's hat, have a look at these sources of information on how to peer review on conference level and journal level.