Reviewing Article Submissions

Have you ever submitted an article to MSDN Magazine via mmsubmit@microsoft.com and then wondered what actually happens between sending in the submission and getting the response.  Well, in that I'm the primary individual who reviews your submissions, allow me to provide a little bit of insight - both into how I approach reviewing submissions and how often I review them.

First let's start with my reviewing schedule as that's pretty straightforward.  I have 2 hours blocked out on my calendar for reviewing submissions every Tuesday and Friday.  I sort the submissions by date received and review them from oldest to newest.  Sometimes I have a submission that requires additional research or another set of eyes looking at it.  In those cases, I will typically skip that submission and schedule additional focused time on it (this means that if it's been a couple weeks since you've heard back from me, it's a potentially good thing).  Because I time-box my reviewing time, the speed with which I will process a specific submission (e.g. - yours) depends on how many submissions are in the queue ahead of yours and whether your submission requires additional research on my part.  If you're curious as to how many submissions I have in the queue at a given moment, I have have 18 active submissions right now, and this is pretty typical.

So now you hopefully have an idea of when I process submissions - so now let's examine how I evaluate submissions.  I have 5 primary criteria that I use:

Compelling - This is where I do a Gladwell snap-judgement.  If I want to know more from reading your submission, I proceed.

Technically Deep/Relevant - For MSDN Magazine, technical depth is (I think) pretty well understood at this point.  If you were curious, though, we lean more towards depth vs. breadth.  This has something to do with history (we have a long one) and the expectations that we have established with our readers.  More importantly, though, shallow content falls much lower on the uniqueness scale (I'll talk about that more in a second) and as such doesn't have as much longitudinal value.  Therefore, I very rarely will accept an article that is "intro" or "overview" focused.  The one exception is for a "first look" kind of technology (for example, Ted Neward's piece on F#).

So - we look for deep content.  But not just any deep content.  It must be relevant to the type of development work our readers are doing.  So how do you evaluate whether your submission is relevant?  Well, generally, if it deals with a problem that you and your colleagues have run into several times, and there's a lot of conversation about it in forums and blogs, it's probably relevant.  Also, for some additional insight, here are the top 4 most requested topics per our latest reader survey.

• Software Design
• Web services development
• Database development
• Web client development

Now, in addition to relevance, sometimes I'll plan an article that just strikes me as cool.  Therefore, if you have this kind of article idea, please send it in - I love those kind of submissions.  Just know that if it's outside the bounds of relevancy to the general readership, you're more subject to the arbitrary nature of whatever interests me a given time <g>.

Uniqueness - One of the first things that I will do after deciding that I like a topic is to search the web to see what else has been published on that topic.  If I can find several articles that deal with the same topic, at the same level, I will generally write you back asking for clarification on how your submission is different than others.  If your article doesn't have any unique insights to offer compared to those other articles, blog posts, etc..., I will reject the submission.  The reason is simply that we strive for "evergreen" content.  We want to ensure that our articles function equally well as reference material down the road as they do in keeping you current.

Actionable - While I understand that different topics lend themselves better to this criteria than others, I think that there is a strong correlation between being able to accomplish something after having read an article and being compelled to read the article.  As such, I look for this characteristic - whether it's in the form of a scenario, sample code analysis, etc... - I look to see whether there is some kind of actionable/prescriptive quality to the article.

Editorial Calendar "Fit" - This one is a tough one for me and is just a reality of having a fixed number of pages that we can put into a magazine issue.  Keep in mind that if you've made it to this stage in my evaluation decision tree, I like your submission.  When you submit an article, you are more specifically submitting an idea for a feature article (as opposed to a column).  Feature articles are generally 5000-6000 words long and we run 5 features per issue.  As such, when I look at your submission, I have to see how it fits into my editorial calendar - and there are a ton of variables to consider here.  For example, I consider things like diversity of content, avoiding duplication with other features or columns, how well the article maps to issue theme, and how far out I'm already planned.  At the moment, I'm already planned out into October (something that I'm really uncomfortable doing, but have done because I'll be out for the month of May - more on that in a minute), so if you send me a submission that I really like, the reality may be that I ask you to hang onto it and resubmit in a couple of months.  At any rate, if I reject your submission at this stage, know that it is still a really difficult thing for me to do.

So this post turned out to be much bigger than I had expected, but I find myself answering these same questions over and over, so I wanted to make sure that I covered them here in one place - think of it as a mental "extract method" refactoring.  At any rate, I hope that it has been helpful for you in understanding a bit more about how things work at MSDN Magazine (and in my head).  I look forward to reading more really great article submissions from you!