Contributions to this site are very welcome. Our aim is to strengthen ties between research and practice, so please write in the style of a popular science article rather than in dry academic prose. (This article from American Scientist is a good example.) Our focus is software engineering, with some ventures into software architecture and computing education. We prefer that people do not review their own work (though we welcome reviews of adjacent work), and the final decision on contributions will be made by the current editor; we would be happy to talk with you about specifics and give feedback on drafts.
- Would you express your opinion so strongly if the paper had come to the opposite conclusion? For example, if it had found that doing X actually did improve code quality, or that Y wasn't better than Z, would you write the same way?
- Are you criticizing the paper's actual claims? If it says that P holds for novices who are learning how to program, there is no point saying, "But no experienced programmer would do that!"
- Are your criticisms of the paper's statistics numerical? It's meaningless to say, "The paper's sample size is too small," without some quantification.
- Are you employing proof by rhetoric? The statement, "It's obvious that J," is verbal bullying, not proof. And many "obvious" things aren't actually true: that's why we do studies.
For Faculty and Students
We encourage faculty to have students write popular summaries of papers as graded work in courses and to submit them to this site. To avoid ethical concerns, we recommend that:
- Students be told that their work can be submitted, but that this is not a course requirement and that whether or not they do this will not affect their grade.
- Students do not indicate whether or not they're going to submit their work to this site until after it has been graded.
If your institution or your legal jurisdiction requires submissions to be handled in some other way, please get in touch: we'd be happy to try to accommodate you.
How to Contribute
- Fork this repository on GitHub.
Create a branch with a name like
wilson-2021-example-subject. Please use the surname of the paper's first author as the
authorfield and a four-digit year.
If your paper is already in
tex/todo.bib, move the entry to
tex/nwit.bib. If you have chosen another paper, please enter its DOI into https://doi2bib.org/ and copy that BibTeX into
tex/nwit.bib. (Please also consider donating to https://doi2bib.org/: it's a great service to the community and could use your support.) Don't worry about adding a
reviewedfield to the BibTeX entry—we'll take care of that—but please do copy the paper's abstract into the
YYYY-MM-DDis the date of your post (not the publication date of the paper) and
short-titlematches the short title of your branch (e.g.,
- Fill in the HTML file (see below).
- When you are done, create a pull request from your repository to this one and email us to let us know your post is ready for review. Please also let us know what URL to use for you in the acknowledgments.
When filling in the HTML template:
- Replace Your Name with the name you would like to appear in the review. Please note that we do will only accept anonymous or pseudonymous reviews by prior agreement: please get in touch if you want to do this.
- Replace Paper Title with the paper's title (in double quotes).
- Replace YYYY-MM-DD with the post's publication date (which should match the first part of your file's name).
- Replace the list of categories with ones appropriate to your paper. Please use existing categories if you can rather than adding new ones.
- Replace all three occurrences of BibliographyKey with the BibTeX key of the paper you are reviewing and fill in the bibliographic details inside the paragraph block. We will reformat this for you if necessary when we merge your pull request.
Copy the full abstract of the paper into the
blockquotebelow the citation. If the abstract is written as several paragraphs in the paper, please preserve that formatting.
Finally, write your review in the
divbelow the abstract.
But Wait, There's More
You (or your students) can also submit short explanations of the methods most commonly used in software engineering research, with examples that use software engineering data—something like Statology's explanation of the Mann-Whitney test but with SE data, or an explanation of similar length and depth of something like the card sorting used in many qualitative studies (again, using data from software engineering or computing education studies). Note that while we think the tidyverse is more approachable than Pandas for people new to programming, computer scientists and software engineers are more likely to already know Python, so we prefer it for code examples. We can translate for you if necessary.
Our entries have been written by:
- Jorge Aranda
- Neil Ernst
- Felienne Hermans
- Lorin Hochstein
- Fayola Peters
- Leif Singer
- Andreas Stefik
- Christoph Treude
- Greg Wilson