Каков порог публикации программного документа?

Меня попросили рецензировать статью о программном инструменте. Я борюсь с тем, достаточно ли этой конкретной работы для публикации. Журнал, для которого я рецензирую, не имеет критерия «известность/новизна», но они требуют, чтобы работа была «единицей публикации».

Назовем то, что я рецензирую, "Функция". Функция является частью более крупного пакета, назовем его «Пакет». Feature — это инструмент с графическим интерфейсом, который берет данные, уже рассчитанные Package, и отображает их с помощью широко используемого бэкэнда для построения графиков. В нем есть несколько приятных вещей, отображающих параметры в бэкэнде построения графика в виде элементов графического интерфейса, и несколько параметров, связанных с характером создаваемого графика (в основном, точечная диаграмма и тепловая карта, а также некоторые переключатели, основанные на доменных метках в данных) .

Вот несколько фактов, формирующих мою точку зрения:

  1. В Feature по сути нет научной логики. Он должен иметь возможность читать файлы, при необходимости умножать на вес, а затем иметь несколько сохраненных переключателей в данных для изменения того, какие данные представлены. Но в основном это очень простой графический интерфейс для анализа и визуализации данных из пакета.
  2. Весь Feature составляет менее 1400 строк кода, почти половина из которых относится к графическому интерфейсу.
  3. Глядя на код (особенно без графического интерфейса), я подозреваю, что мог бы сократить около 300-400 строк кода - разработчики не используют доступные научные программные инструменты, включая повторную реализацию функции, которая находится в библиотеке, которую они включают.
  4. В настоящее время статья о пакете версии X.0 находится на рецензировании (X>1); цитируется в рукописи, которую я рецензирую. Все авторы статьи о Feature также являются авторами статьи о Package.
  5. Весь список авторов Package — это, по сути, одна исследовательская группа — это не гигантская работа всего сообщества. И статья о пакете версии X-1 была опубликована всего 2 года назад, поэтому я удивлен, что они уже пытаются выпустить еще две статьи по программному обеспечению.

Последние два особенно раздражают меня, потому что я чувствую, что цель научных статей по программному обеспечению состоит в том, чтобы сделать разработку научного программного обеспечения цитируемой, а не увеличивать количество ваших статей. Авторы уже будут получать цитаты на основе другой статьи.

С другой стороны, я пришел к этому с некоторым предубеждением, что у одного из авторов есть склонность больше заботиться о количестве, чем о качестве публикаций. Так что я не уверен, что моя склонность к отказу частично основана на этом или на реальных фактах. (Отсюда стремление к другим мнениям.)

РЕДАКТИРОВАТЬ: я забыл сказать, что функция еще не объединена с основной веткой пакета, но в настоящее время находится в отдельной ветке в том же репозитории git.

Можно ли использовать Feature для данных, не сгенерированных пакетом?
@AzorAhai В теории. Если для данных используется то же форматирование вывода, что и для пакета (текстовые файлы, расположенные в файловой системе определенным образом). Package — это современная переработанная версия OldFortranCode, поэтому выходные данные из OldFortranCode также будут работать. Но он не будет совместим с основным конкурентом Package (если только кто-то не напишет программу для перевода). РЕДАКТИРОВАТЬ: Уточнить: OldFortranCode использовался только внутри группы; поэтому у него нет пользовательской базы.
Тогда вы ожидаете, что люди из других групп когда-либо будут использовать Feature для построения своих данных?
Функция в первую очередь предназначена для пользователей Package. Другие группы будут использовать пакет и, следовательно, функцию (функция будет распространяться как часть пакета). В принципе, кто-то может добавить Конкурент -> Транслятор пакетов. Но Competitor — это библиотека Python, и поэтому она имеет немедленный доступ к построению графиков с помощью matplotlib, поэтому я не уверен, что ее пользовательская база (членом которой я являюсь) потребует этого.
Думаю, мне действительно нечего добавить, кроме ответа Баффи. Похоже, вы довольно хорошо знаете проблему, и это может быть подсчет количества публикаций.
Кое-что, что я сделал: вы можете просмотреть недавно опубликованные статьи в журнале (скажем, за последние 5 или 6 лет) и посмотреть, в какой степени ваши опасения по поводу этой статьи проявляются в любой из этих других статей. Но, возможно, для вашей области и темы (о которой я ничего не знаю) это может быть трудно определить, быстро просмотрев статью. Тем не менее, моя внутренняя реакция после прочтения ваших опасений (например, № 3 кажется мне особенно проблематичной) состоит в том, что в этой статье есть несколько очевидных недостатков, которые могут не быть недостатками, но разумно ожидать, что авторы защитят их.
@DaveLRenfro: Хорошая идея, и я сделал кое-что из этого. Конкретный поджурнал является новым членом «семьи» журналов, но я просмотрел недавние статьи по программному обеспечению в родственных/родительских журналах, а также в других журналах, издающих программное обеспечение в этой области. Несколько статей, на мой вкус, были немного малы, но обычно это оправдывалось тем, что они были очень общего пользования или первым объявлением о новом кодексе. Я не видел ни одной новой функции существующего кода. Тем не менее, я заметил, насколько слаб этот был только тогда, когда я начал его рассматривать.
Re: #3: По моему опыту, это очень распространено. Люди не знают своих инструментов, и в результате нажимаются клавиши впустую и код трудно поддерживать. Я перечисляю его здесь, потому что он подходит для использования строк кода в качестве оценки статуса «модуля». Я бы не отказался от статьи, основанной только на плохо написанном коде. Я называю это в обзоре и указываю на лучшие инструменты/образовательные ресурсы. Проблема носит институциональный, а не индивидуальный характер: ученые-программисты были обучены как ученые и не знают программной стороны.

Ответы (2)

Для таких вещей не существует яркого порога, и ответ должен быть таким же, как и для любой научной статьи, основанной на вопросах новизны и расширения знаний. Если этого нет, то он, вероятно, не является хорошим кандидатом, хотя стандарты разных журналов сильно различаются.

Но вы, кажется, описываете небольшое продвижение вперед с небольшой новизной, и вы также, кажется, приняли решение. Мы не можем помочь вам с суждением, и вам просто нужно рискнуть и позвонить. Другие могут с вами не согласиться, но так всегда бывает при рецензировании.

Я не очень понимаю ваш пункт 5 и могу не согласиться с вашим акцентом на нем. Почему работа, выполняемая внутри группы, менее ценна, чем работа, выходящая за пределы институциональных границ? Многие работы выполняются одним или несколькими людьми в рамках исследовательской группы. Тем не менее, я мог бы согласиться больше, если вы имеете в виду, что все их цитируемые статьи исходят от одних и тех же людей. Это не обязательно красный флаг, но может быть.

Извините, чтобы уточнить пункт 5: я имею в виду это в том смысле, что если бы у Package было 100 авторов, то авторы Feature могли бы чувствовать, что их вклад теряется в смеси, и я мог бы понять, почему они чувствовали, что вторая статья необходима для подчеркнуть их вклад. С ~ 6 авторами их вклад не будет проигнорирован.
Кроме того, отредактировано, чтобы уточнить, что журнал явно запрещает рассматривать новизну. (Также влияние, узкий фокус и т.д.)
Кажется довольно широким. Приемлемо ли тогда что-либо правильное и не нарушающее нормы?
Ага. Журнал намерен поощрять публикацию попыток воспроизведения предыдущих экспериментов (при условии, что для повторения может быть дано обоснование) и допускает отрицательные / неубедительные результаты. Таким образом, они не хотят, чтобы влияние/новизна были мерой принятия. Я понимаю намерение экспериментировать, но мне сложно работать с документами по программному обеспечению. Поэтому я пытаюсь придумать лучший тест на «достаточно ли этого вклада для публикации», чем «моя интуиция говорит…».
И прежде чем вы спросите (потому что это будет мой следующий вопрос) — журнал является законным. Или не было давно. Я убедился, что один из нобелевских лауреатов, перечисленных в родительском журнале, по-прежнему указывает родительский журнал в качестве одного из своих редакционных заданий.

Я собираюсь принять ответ Баффи, потому что, даже если это не ответ «вот как облегчить вам жизнь», на который я надеялся, это, кажется, общепринятый правильный ответ.

Тем не менее, после долгих размышлений (и с учетом отзывов отсюда) я составил список, который в значительной степени меня удовлетворяет. Я предполагаю, что все, что следует за первыми двумя пунктами, больше нужно проверять: «Есть ли здесь новизна/известность, которые вы упускаете из виду, потому что ваша интуиция такова, что этой работы недостаточно, чтобы считать ее статьей?»

  • Реализует ли это какую-то нетривиальную науку? Если инструмент реализует значительную логику генерации или анализа данных, то его следует рассмотреть. «Значительный» по-прежнему является субъективным термином, но просто чтение выходного формата не будет иметь существенного значения.
  • Программный инструмент распространяется независимо? Одной из важных целей статей по программному обеспечению является информирование сообщества о плагинах, которые в противном случае не были бы замечены (затеряны в каком-нибудь темном уголке Интернета). Это могут быть относительно небольшие (но полезные) фрагменты кода, которые можно было бы не заметить без журнала, служащего форумом для объявлений. Этот критерий, вероятно, применим только к пограничным случаям.
  • Можно ли повторно использовать инструмент во многих контекстах? Даже очень простой инструмент может быть ценным вкладом, если он предназначен для облегчения взаимодействия. Например, простой «универсальный транслятор» для форматов, специфичных для предметной области, может быть очень маленьким, но его стоит опубликовать.
  • Является ли подход новым? Даже для журналов, не предъявляющих требования к новизне , наличие нового подхода может быть фактором при принятии статьи.
  • Требует ли внедрение инструмента значительных знаний в предметной области? Потенциальной целью научной публикации по программному обеспечению является упаковка значительных знаний в предметной области таким образом, чтобы сделать их доступными для неспециалистов.

Что касается пятого пункта, я представляю что-то вроде графического интерфейса, который не позволяет пользователям выбирать несовместимые параметры, где несовместимость может потребовать знаний в предметной области. Я знаю, что в моей области есть программы генерации данных на основе сценариев, где пользователи могут случайно выбрать несовместимые параметры и получить в результате ерунду.

Я не уверен, что это охватывает все случаи, но охватывает все, о чем я могу думать. И я чувствую себя лучше, используя рубрику, которую я мог бы применить к любому программному пакету.

Публикация с надеждой на отзывы сообщества, чтобы следующий человек в похожей ситуации мог увидеть, что я сделал!

Каков порог публикации программного документа?
СпросиСетьПолитика конфиденциальности1y, 0v