本文章是由機器翻譯。

編輯寄語

發佈文章的快速指南

Keith Ward

要說起我在各種會議上最經常被問到的問題，當屬：“您好，我有一個很棒的主題想寫成 MSDN 雜誌 文章。該怎麼做呢？”

這個問題問得好。畢竟，為雜誌寫篇文章不像編寫代碼；忘記我剛放在“代碼”後面的分號的後果不像在 C# 中忘記分號的後果那麼嚴重。但是，在某個重要方面它們又非常相似：寫文章得從一個空白頁開始，而編寫代碼也要從一個空白 Visual Studio 專案視窗開始，兩者都是創造性的工作。兩者雖然都始于空白，卻都望寫出精彩。下麵是一些要點。

1. 賄賂一下我總是有説明的。切記最重要的一條原則：支票中的零越多，您的文章被選中的可能性越大。這些錢都會用來支援亟待説明的孩子，也就是我的孩子。

好了。以上純屬玩笑，到此為止。請別真給我匯錢。

首先，您必須 為文章想好主題。您可能兼具比爾·蓋茨的程式設計頭腦和海明威的寫作才能，但如果您的想法就像新一季的現實電視節目秀一般差勁，那您空有頭腦和才能也無濟於事。

因此，您可能會問，什麼算是“很棒”的主題？這很難定義，但我可以列出一些通用的指導原則。首先，正如任何編輯都會告訴您的，請閱讀過往期刊。如果您是 MSDN 雜誌 的忠實讀者，而且仔細讀過每一期內容，那您對我們發佈的文章類型可能會有比較直觀的瞭解。如果您不怎麼讀我們的雜誌，那就著手讀一下最近的幾期（記住，這些期刊的完整版本同時也線上發佈）並做一番研究。

研究後您將很快發現一些重要情況。情況1：這份雜誌的讀者主要是經驗豐富的開發人員，技術性非常強。介紹性和概述性的文章大都不會入選。要知道，這份雜誌可不登載 100 集的故事。有許多其他地方會發佈這些類型的文章，對某些讀者而言它們非常受歡迎。只是，這不是我們 所要面向的讀者。

情況2: 文章應避免泛泛而談。另一條重要原則：泛泛談 = 不好。具體談 = 好。如果您想“寫一篇關於 Windows Workflow Foundation 的文章”，可能不會獲得通過。但如果您想“寫一篇關於在 WF 4 中創建自訂控制流活動的文章”，那麼獲得通過的希望會大得多。事實上，Leon Welicki 就是這麼做的，他在最新一期雜誌上發表了該主題的文章。

請記住，我們的讀者通常都是資深專業人員，它們需要的是對具體開發問題或難題的具體回答。為此，請提供解決實際問題的可行建議。我不需要介紹 OData 協定或其用途的文章。我需要的是解決具體問題的文章，比如有關將 OData 與現有基於 Atom 和 AtomPub 的閱讀器和編寫器集成的文章，正如 Chris Sells 在 2010 年 8 月刊中發佈的文章一樣。

准作者們擔心的另一大問題是寫作經驗。如果他們沒有發表文章的經驗，只是在什麼地方寫過幾篇博文，就可能擔心自己是否有機會在這份雜誌上發表文章。如果您也有此擔憂，請放心：以前的寫作經驗不是必備條件。我更關心的是文章的主題以及執行方式，而不是您發表過多少文章。

您之前的寫作經驗固然有利無弊，但只要您在信件（最初的計畫信以及其他信件）中展示出基本的寫作能力，我們就會考慮錄用您的文章。

如果您對寫文章毫無經驗，那麼從一開始您就要清楚寫作是一件困難的 事情，撰寫這類文章本身也是一種藝術行為。知道如何開發軟體是一回事，而將開發軟體的過程寫出來完全是另外一回事。

這還不算完。寫作之後還有編輯過程，此時我們將和您一起對您的文章進行潤色、細微修改甚至會要求您做出較大的改動，這個過程可能讓人備感苦悶。

說這些並不是想嚇跑您，只是希望您對真實的情況有所瞭解。如果您真想在我們的雜誌上發表文章，我所說的這些一定不會令您望而卻步，而且您可能會拿出成功的文章，並在MSDN 雜誌 上看到您的大名。

請將文章主題通過 mmeditor@microsoft.com 發給我。