Любые материалы, которые вы хотите опубликовать на сайте RSDN, следует направлять по адресу submit@rsdn.ru. При подготовке материалов следует придерживаться следующих правил оформления.
Обратите внимание на кнопку “Properties” (Свойства документа) панели Conversion. Не забудьте заполнить необходимые поля на закладках “Заголовок” и “Дополнительно”. |
Не присылайте рисунков в формате JPG. |
ПРИМЕЧАНИЕ Не присылайте файлы *.xml и *.html, появляющиеся при работе конвертора в xml, достаточно прислать только doc-файл и каталог с рисунками и архивными файлами. |
Если при оформлении документа вы не используете RSDN Authoring Pack, придерживайтесь следующих правил:
ПРЕДУПРЕЖДЕНИЕ Располагайте все файлы, идущие вместе с Вашей статьей (рисунки, архивы и т.д.), в подкаталоге, одноименном названию файла статьи. Название файла (и подкаталога) не должно содержать русских букв и пробелов. |
Если вы хотите сделать перевод полезной статьи, в первую очередь обратитесь за разрешением к её автору. Копию ответа автора с разрешением следует приложить к тексту перевода. Кроме того, в тексте следует указать автора оригинальной статьи и ссылку на первоисточник.
Перевод оформляйте в виде абзац оригинала – абзац перевода, абзац оригинала – абзац перевода и т. д.
Если вы хотите опубликовать на RSDN разработанный вами для повторного использования компонент (функцию, класс, библиотеку и т. п.), подготовьте к нему небольшой демонстрационный проект, а также небольшое описание. Без описания ваш компонент вряд ли будет полезен другим разработчикам. В описании укажите:
Сам компонент и сопровождающий его демонстрационный проект отправляйте в двух отдельных архивах в формате zip. Использование других архиваторов нежелательно, так как перед выкладыванием файлов на сайт нам придётся переупаковывать их с помощью zip.
Архив с демонстрационным проектом не должен содержать лишних файлов. Например, из проекта Visual C++ 6.0 следует удалить каталоги Debug, Release и им подобные, а также используемые средой разработки файлы *.aps, *.clw, *.ncb, *.opt и *.plg.
Если вы хотите опубликовать написанную вами программу на RSDN, помните, что она должна сопровождаться полным набором исходных текстов. Наш сайт создан для программистов, поэтому вряд ли кому-то будет интересен “черный ящик”. Если по каким-то причинам вы не можете опубликовать исходные тексты, необходимо, по крайней мере, описание общих принципов реализации и используемых технологий. К программе следует подготовить краткое текстовое описание. Саму программу (отдельный exe-файл или дистрибутив) и её исходные тексты отправляйте в двух отдельных zip-файлах. И, пожалуйста, перед отправкой проверьте программу последней версией хорошего антивируса.
При подготовке статей к публикации на RSDN они обрабатываются редакцией во взаимодействии с автором. Задача вычитки - повышение качества материала и контроль технической корректности информации, содержащейся в материале. Неверная информация или плохой стиль изложения материала недопустимы, поскольку ведут к снижению авторитета как автора, так и ресурса в целом.
В процессе совместной работы над статьей все изменения (как редакторами, так и авторами) в статью должны вноситься в режиме исправлений (revisions) MS Word.
Замечание редактора обязательно должно вызывать реакцию автора. Допустимые реакции:
Если автор не согласен с комментарием или исправлением редактора, он должен разъяснить вопрос в виде комментария в статье, в форуме "Обсуждение статьи" или по e-mail mag@rsdn.ru. Автору стоит помнить, что если редактор или кто-то из участвующих в обсуждении статьи неправильно понял его слова, лучше не убеждать отдельного редактора или члена группы, а исправить текст так, чтобы непонимания больше не возникало.
Если редактор согласен с тем, что ошибся, вопрос снимается. Если редактор не согласен, решает группа.
В случае технических вопросов приводить подтверждающие свое мнение ссылки и примеры - задача автора, так как редактор и группа - читатели, которых он пока не смог убедить. Но если кто-то может помочь автору или, наоборот, убедительно опровергнуть его точку зрения, это приветствуется. Если за неделю с мнением автора согласилось большинство компетентных членов группы, замечание снимается. Если за неделю большинства не набралось, автор должен соответственно исправить статью. Если мнение группы отличается от обоих мнений, принимается мнение группы.
Если к общему мнению придти не удается, публикуется мнение автора, которое может сопровождаться редакционным комментарием. Если спорный вопрос не относится напрямую к теме статьи, лучшим решением будет удалить его, или по возможности сгладить.
Русский язык и все вопросы, связанные с ним, находятся в полной компетенции редакции и не обсуждаются. Это не значит, что не надо искать опечатки и ошибки - редакторы тоже люди и могут ошибаться.
К форматированию кода предъявляются требования, аналогичные требованиям, определенным в "Соглашении по стилю кода" но с послаблениями, учитывающим специфику языков.
Во время вычитки автор должен ждать её окончания и не изменять статью, кроме исключительных случаев.
Бывает, что у автора "открываются глаза", и он понимает, что в статье упустил из виду что-то существенное, и что она ещё не готова к публикации. В такой ситуации автор должен немедленно оповестить редакцию о том, что работа продолжается, и о характере работ - например, это может быть добавление раздела(ов) (в этом случае существующую часть можно вычитывать) или полная переработка материала.
Наличие отличающихся друг от друга XML и DOC-вариантов материала недопустимо.
…материалы, оформленные в соответствии с приведёнными выше требованиями, имеют приоритет перед всеми другими материалами, так как их проще всего верстать и подготавливать к публикации на сайте.