Шаблон разговора:Информационный ящик о происшествии с самолетом

Причина аварии

Есть ли указания или консенсус относительно того, следует ли включать официально установленную причину аварии в поле «Сводка» информационного окна «Происшествие с самолетом»? См. обсуждение по адресу: https://en.wikipedia.org/wiki/Template_talk:Infobox_aircraft_occurrence/Talk:Colgan_Air_Flight_3407#Infobox_summary DonFB ( обсуждение ) 23:41, 27 марта 2023 (UTC) [ ответ ]

Да, официальная документация для шаблона говорит Краткая фактическая сводка происшествия. Но, поскольку это только сводка информационного поля, акцент делается на «краткая». - Ahunt ( обсуждение ) 23:45, 27 марта 2023 (UTC) [ ответить ]

Я это видел, но это оставляет открытым мой конкретный вопрос о том, следует ли указывать причину. DonFB ( talk ) 23:51, 27 марта 2023 (UTC) [ ответить ]

Мое личное мнение: «конечно, если его можно кратко изложить». Так что хорошо было бы «управляемый полет, столкновение с землей», плохо было бы «недостаточная подготовка пилотов, нерешенные проблемы с обслуживанием, плохая корпоративная культура, недостаточный нормативный надзор в сочетании с давлением со стороны клиентов, что привело к столкновению с землей, потере корпуса, гибели экипажа и пассажиров и т. д.». Некоторые официальные отчеты о происшествиях легко изложить в нескольких словах, а другие — нет. Во многих отношениях создание достаточно краткого резюме информационного окна — это своего рода искусство. В случае рейса 3407 авиакомпании Colgan Air я думаю, что текущий текст Stalled during landing approach; cutting into house (Сваливание при заходе на посадку; врезался в дом) — это нормально, хотя я бы опустил часть с домом для краткости, так как неважно, во что они врезались. В случае этой аварии причины довольно сложны и их нелегко осмысленно изложить в нескольких словах, поэтому лучше не пытаться этого делать, а вместо этого просто изложить единственную непосредственную причину крушения — сваливание. - Ahunt ( обсуждение ) 01:01, 28 марта 2023 (UTC) [ ответить ]

Да, краткость — это добродетель. Я думаю, что различие заключается между простым описанием и указанием причины. Я думаю, что фраза «ошибка пилота» почти никогда не используется в официальных отчетах, но это может быть разумным выбором редактирования, если официальный отчет четко указывает на это как на причину (и если RS использует эту фразу). Отчет Колгана обвиняет пилотов, но также ссылается на другие проблемы, в соответствии с вашим (юмористически) многословным примером выше. Я не знаю, нужен ли RFC для статьи Колгана, но я бы пригласил вас и всех остальных прокомментировать обсуждение на ее странице обсуждения. DonFB ( обсуждение ) 01:30, 28 марта 2023 (UTC) [ ответ ]

Да, я согласен, в таком случае "ошибка пилота" не является ни точной, ни полезной. Хорошо, я добавлю туда несколько слов. - Ahunt ( talk ) 01:33, 28 марта 2023 (UTC) [ ответить ]

Я собирался поднять эту тему некоторое время назад (хорошо, DonFB). Я бы пошел еще дальше и прямо отговорил редакторов от добавления причин в сводки инфобоксов . Авиационные происшествия в большинстве случаев являются сложными событиями; отчеты о происшествиях почти всегда содержат множество причин и способствующих факторов, которые невозможно обобщить в нескольких словах, сохраняя при этом NPOV. «Ошибка пилота» — лучший пример: самая любимая причина среди редакторов, часто добавляемая сама по себе, даже если это явно не единственный фактор. На мой взгляд, сводка должна:
- Сначала указать, что произошло (например, что самолет разбился), что часто далеко не очевидно, учитывая такие названия статей, как «Рейс 123 авиакомпании XYZ».
- Затем кратко описать обстоятельства (при заходе на посадку, ночью, на взлете и т. д.).
- Наконец, оставить причины для текста статьи, вместо того чтобы выбирать некоторые из них и пытаться втиснуть их в одну строку.
Во многих случаях для сводки инфобокса достаточно «Столкновения управляемого полета с землей». Катастрофу в Колгане можно было бы описать словами «Заглох при заходе на посадку», «Врезался в дом » и т. д., сделав ее простой, лаконичной и нейтральной. -- Deeday-UK ( обсуждение ) 15:22, 28 марта 2023 (UTC) [ ответить ]

Просто в качестве примечания, в ноябре 2023 года Deeday-UK внесли изменения в текст справки шаблона, которые отражали их мнение, изложенное выше. В феврале они внесли некоторые изменения в информационные окна об авариях, которые удалили причину аварии из нескольких статей, включая US-Bangla Airlines Flight 211 , сославшись на консенсус проекта. Я заметил правку, потому что эта статья была в моем списке наблюдения, и связался с ними на их странице обсуждения по адресу User talk:Deeday-UK#Your edit to US-Bangla Airlines Flight 211 , спросив, о каком консенсусе проекта они говорят. Они указали на это обсуждение. Я не думаю, что это упоминание одним редактором об удалении причины аварий из информационных окон в конце обсуждения о том, как сводки информационных окон должны быть краткими и лаконичными, отражает истинный консенсус проекта, особенно с учетом аналогичного сопротивления от Btphelps на странице Uruguayan Air Force Flight 571 . Недавно Aviationwikiflight вносил похожие правки в статьи, ссылаясь на изменения в тексте справки, внесенные Deeday-UK. Я хотел бы, чтобы все пользователи, которые считают, что сводки инфобоксов могут не содержать никаких упоминаний о причинах, стремились к более широкому консенсусу проекта для такого изменения в более широко просматриваемом месте, чем это. На данный момент я отменил это ноябрьское изменение. RecycledPixels ( обсуждение ) 15:57, 9 мая 2024 (UTC) [ ответ ]

Соответствующее обсуждение проекта происходит в Википедии talk:WikiProject Aviation#Template:Infobox aircraft encounter: Should the summary option include causes? . Лорд Сьонс23 ( talk - makings ) 10:04, 23 мая 2024 (UTC) [ ответить ]

Обновление: Эта ветка проекта WikiProject была заархивирована в: обсуждение в Википедии:WikiProject Aviation/Архив 24#Шаблон:Infobox инцидент с самолетом: должен ли параметр сводки включать причины?  —  SMcCandlish ☏ ¢  😼  12:40, 16 октября 2024 (UTC) [ ответить ]

Запрос предложений по причинам в поле резюме

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

Существует консенсус, что они могут быть, при условии, что они будут достаточно краткими и будет соблюдена должная весомость. ( неадминистративное закрытие ) — Compassionate727  ^{( T · C )} 19:52, 17 ноября 2024 (UTC) [ ответить ]

---

Можно ли включить официально установленные причины в поле «Сводка» этого информационного окна? Лорд Sjones23 ( обсуждение - вклады ) 09:23, 16 октября 2024 (UTC) [ ответить ]

* Уведомление об этом обсуждении было размещено в разделе Wikipedia talk:WikiProject Aviation и Wikipedia talk:WikiProject Aviation/Aviation accident task force 16 октября 2024 г.

• Обычно, но очень кратко. Я прочитал обсуждение в верхней части этой страницы и связанное с ним обсуждение, на которое она ссылается (на wikiproject). Различные опасения редакторов, что причины могут быть сложными или RS-спорными, обоснованы. Но чаще всего ни то, ни другое не имеет места (или, по крайней мере, они не настолько сложны, чтобы их нельзя было легко обобщить, и нет столько сомнений или разногласий, чтобы не возникла позиция реального консенсуса WP:DUE ). Я думаю, что причины, когда они известны (в диапазоне WP:DUE-против- WP:FRINGE ) и когда их можно кратко обобщить в одну строку, должны быть включены, поскольку это информация, которую, очевидно, будет искать среднестатистический читатель. /doc следует обновить, чтобы поощрять обычное включение такой информации в очень краткой форме, но явно указывать, что ее следует исключить, когда она сложна или вызывает значительные сомнения.  —  SMcCandlish ☏ ¢  😼  12:47, 16 октября 2024 (UTC) [ ответить ]
• Да , и они должны быть краткими. Согласно моим комментариям в предыдущем обсуждении . RecycledPixels ( обсуждение ) 16:22, 16 октября 2024 (UTC) [ ответить ]

• Перечитав заявление RFC, я бы предложил заменить «should» на «can», потому что я не думаю, что это должно быть требованием, но и запрещать это тоже не следует. RecycledPixels ( обсуждение ) 22:14, 23 октября 2024 (UTC) [ ответить ]

• Я реализовал это изменение. Lord Sjones23 ( обсуждение - вклад ) 15:33, 31 октября 2024 (UTC) [ ответить ]

• Комментарий – Пинг участников предыдущих обсуждений: @ DonFB , Ahunt , Deeday-UK , Nimbus227 , Dfadden , Cutlass и SportingFlyer . Aviationwikiflight ( обсуждение ) 11:36, 18 октября 2024 (UTC) [ ответить ]
• Да, но, как сказано выше, следует быть немного кратким, например, включение «из-за ошибки пилота и плохого управления ресурсами экипажа » следует считать уместным. Cutlass ^Ciera 12:01, 18 октября 2024 (UTC) [ ответить ]
• Да , но снова кратко — даже не полным предложением — и только если прямая причина четко обсуждается в окончательном отчете об аварии, чтобы избежать любых проблем с WP:SYNTH . SportingFlyer T · C 18:40, 18 октября 2024 (UTC) [ ответить ]
• Да . Кратко. Но я не поддерживаю предложение User:SMcCandlish о том, что документация должна «явно указывать, что ее следует исключить, когда она сложна или вызывает значительные сомнения». В редких случаях причину найти невозможно, и это можно указать в информационном поле. Но даже «сложную» причину можно кратко изложить, я считаю. Я не согласен с предложением лазейки, которая открывает путь для большего редакционного конфликта. DonFB ( обсуждение ) 22:34, 18 октября 2024 (UTC) [ ответ ]

  Ну, тогда какая-нибудь другая формулировка, например «Не пытайтесь указать значение для этого параметра, если оно будет длинным и сложным или будет предметом обширных споров в надежных источниках» или что-то в этом роде. Я хочу сказать, что документация шаблона должна препятствовать заполнению этого поля, когда его заполнение нецелесообразно. Или, другими словами, не создавайте лазейку в противоположном направлении, которая поощряет editwarring включать параметр любой ценой; не поощряйте попытки бороться с консенсусом против включения его в конкретную статью или даже попытки принудительного включения при отсутствии четкого консенсуса по этому вопросу. Именно из-за того, что это происходит, эта дискуссия вообще открыта.  —  SMcCandlish ☏ ¢  😼  03:46, 19 октября 2024 (UTC) [ ответить ]

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

  Я считаю, что конфликты в этом вопросе обычно вращались вокруг фразы «ошибка пилота». Я думаю, что это так по двум причинам: редакторы, которые специализируются на статьях об авиации, как правило, хотят избегать этой фразы; и официальные отчеты никогда (или почти никогда) не используют эту фразу. Но надежные независимые источники используют эту фразу. Это поднимает вопрос о политике в отношении использования первичных и вторичных источников. Мы должны использовать вторичные источники как можно чаще и использовать первичные источники экономно и осторожно и без интерпретации. Если надежные источники интерпретируют официальное заключение как «ошибку пилота», мы имеем право так говорить. Если RS не использует эту фразу, мы тоже не должны этого делать, независимо от нашей интерпретации официального заключения — в соответствии с политикой не интерпретировать первичный материал. Но мы по-прежнему можем использовать соответствующие дословные формулировки из официальных заключений в нашем кратком изложении причины. DonFB ( обсуждение ) 06:47, 19 октября 2024 (UTC) [ ответ ]

• Зависит от того, как сказал SMcCandlish, причина(ы) могут быть включены в сводку инфобокса, если результат будет кратким и нейтральным . Если причин слишком много или они слишком сложны, чтобы уместиться в двухстрочное резюме, их следует опустить. Что касается «ошибки пилота», проблема заключается не в использовании фразы как таковой; проблема заключается в отборе одной или двух причин, чтобы сделать сводку краткой (включая, почти всегда, ошибку пилота), когда надежные источники (главным образом официальный отчет об аварии) приводят целый каталог причинных и способствующих факторов. Это не нейтрально. -- Deeday-UK ( обсуждение ) 20:20, 19 октября 2024 (UTC) [ ответ ]

  Я продолжаю верить, что причины, будь то единичные или множественные, можно суммировать в приемлемо краткой форме. Сам NTSB будет ссылаться на «вероятную причину» в разумно экономической формулировке. Другие страны могут быть не столь лаконичны, но я думаю, что тщательное редактирование может сжать их выводы. «Влияющие» факторы не обязательно указывать в информационном поле; это для основной части статьи. DonFB ( talk ) 20:58, 19 октября 2024 (UTC) [ ответить ]

  DonFB, вы, кажется, думаете, что «вклад» означает неважность; это весьма сомнительно. Посмотрите на пример из учебника того, что я имею в виду, в American Airlines Flight 587 : резюме и так слишком длинное, и тем не менее, из всего заявления о вероятной причине NTSB , в нем упоминается только ошибка пилота, в то время как конструктивные характеристики самолета и недостатки в программе обучения авиакомпании опущены. То есть при другой конструкции руля или лучших программах обучения эта авария могла бы никогда не произойти, однако у прохожего сложится впечатление, что это была вина пилота. Как вы можете считать такие резюме приемлемыми? -- Deeday-UK ( talk ) 10:03, 20 октября 2024 (UTC) [ ответить ]

  Я полагаю, что следующий текст резюме решит поднятые вами вопросы краткости и точности:

  «Разрушение конструкции из-за ошибки пилота; способствующими факторами стали конструкция самолета и подготовка пилотов»

  Возможно, после слов «разрушение конструкции» следует добавить слова «и авария».

  Я не собираюсь этим ответом утверждать, что «способствующие факторы» всегда должны содержаться в Резюме. В этом случае, однако, они по сути являются частью вероятной причины NTSB, поэтому их включение уместно. Я не тратил время на просмотр вторичных источников, но это следует делать регулярно, чтобы гарантировать, что этот или любой текст Резюме не содержит редакционной интерпретации. DonFB ( talk ) 21:01, 20 октября 2024 (UTC) [ ответить ]

  Конечно, в резюме должно быть указано, что самолет разбился: это, по сути, причина, по которой существует статья American Airlines Flight 587. Читателю не нужно выводить этот факт из всех остальных фрагментов информации в информационном поле. Что приводит нас к пункту № 1, на котором все акцентируют внимание: краткость (или ее отсутствие, как в вашем примере). -- Deeday-UK ( talk ) 20:58, 22 октября 2024 (UTC) [ ответить ]

  Его можно легко сделать короче существующего текста (включив «и разбился»), убрав «способствовавшие факторы» и просто последовательно указав причину и два фактора. DonFB ( обсуждение ) 02:12, 23 октября 2024 (UTC) [ ответить ]

• Иногда это сложно. В этом случае спор должен быть указан или связан с этой частью текста статьи. В противном случае в бесспорных случаях, да. Senorangel ( talk ) 02:32, 26 октября 2024 (UTC) [ ответить ]
• В целом , да, официальные причины могут быть включены. Однако резюме должно быть кратким и лаконичным и не должно быть занято каждой отдельной причиной и способствующим фактором, как это было в случае с рейсом Pan Am 799 , см., например, эту предыдущую редакцию . Однако причины не должны быть выбраны выборочно, чтобы включить только «одну или две из десяти перечисленных причин». Должно ли резюме включать « Ошибку пилота » в качестве причины, зависит от источника. Если нет источников, использующих термин « ошибка пилота» , сжатие и суммирование причин и способствующих факторов в ошибку пилота было бы неуместным и не должно поощряться, поскольку все это, скорее всего, будет оригинальным исследованием и нарушит WP:NPOV . Aviationwikiflight ( обсуждение ) 17:33, 7 ноября 2024 (UTC) [ ответить ]

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

самолет1

Должны ли мы использовать plane1 в информационном поле в одной аварии, но в информационном поле использовать другую фотографию в качестве обломков аварии? Например, рейс 1549 US Airways , рейс 77 American Airlines или рейс 103 Pan Am . Или для фотографий самолетов, задействованных в инциденте, но находящихся в эксплуатации у предыдущего оператора (если у нас нет фотографии этого самолета с текущим оператором), таких как рейс 90 Air Florida и рейс 3054 TAM Airlines . Я думаю, что использовать его было бы изящнее, чем использовать [[Файл:_______|thumb|_________]]. Tô Ngọc Khang ( talk ) 13:53, 7 ноября 2024 (UTC) [ reply ]

@ Ivebeenhacked @ Aviationwikiflight @ Dual Freq @ Krd @ Maungapohatu @ RecycIedPixeIs Tô Ngọc Khang ( обсуждение ) 11:24, 8 ноября 2024 г. (UTC) [ ответ ]

@ Aviationwikiflight , @ Dual Freq и @ Maungapohatu Каковы ваши мнения? Tô Ngọc Khang ( обсуждение ) 05:07, 11 ноября 2024 (UTC) [ ответить ]

То Нгок Кханг, если я правильно понял, вы предлагаете использовать поля plane1_imageи plane1_captionрегулярно для любой аварии (где это уместно), а не только для аварий с участием двух или более самолетов. Результат будет примерно таким: в информационном поле будут размещены две фотографии: одна с местом аварии/крушения (если таковая имеется) вверху, а другая с самолетом, находившимся в эксплуатации до аварии, помещенная прямо под заголовком «Самолет», что, надо признать, выглядит довольно аккуратно. Предложение действительно имеет некоторые достоинства; что думают люди? -- Deeday-UK ( обсуждение ) 16:15, 8 ноября 2024 (UTC) [ ответить ]

Да, даже я думаю, что это выглядит организованным и аккуратным. Я согласен с тем, что говорит То Нгок Кханг. Взломано ( Обсуждение | Вклад ) 16:20, 8 ноября 2024 (UTC) [ ответить ]

Я немного поразмыслил, склоняясь против . Одной фотографии, иллюстрирующей аварию или вовлеченный самолет, кажется, достаточно для информационного поля, которое в мобильной версии отображается первым перед содержанием статьи и должно быть прокручено, чтобы добраться до самого содержания. Давайте не будем превращать информационные поля в фотогалереи, особенно кучу фотографий одного и того же самолета в других раскрасках, что, на мой взгляд, является одним из самых бессмысленных источников правок, воюющих за статьи об авиационных происшествиях. Конечно, другие фотографии все еще могут быть включены в текст статьи. Я не вижу, какую проблему решает это предложение. RecycledPixels ( обсуждение ) 16:44, 8 ноября 2024 (UTC) [ ответить ]

Чаще всего уже есть фотография самолета до аварии, размещенная сразу после инфобокса. Это предложение улучшает то, что оно помещает такое изображение в более аккуратное и логичное место, внутри инфобокса. Общее пространство, занимаемое (инфобоксом + фотография до аварии сразу после него), примерно такое же, как и у инфобокса, содержащего обе фотографии.

Чтобы было ясно, я тоже против размещения в информационном поле дополнительных изображений самолетов, находящихся в эксплуатации у предыдущих операторов . Я поддерживаю размещение в информационном поле фотографии самолета до аварии только в том случае, если первое место занимает фотография аварии или крушения. -- Deeday-UK ( обсуждение ) 17:13, 8 ноября 2024 (UTC) [ ответить ]

У меня меньше возражений против конкретного примера, который вы там привели: можно поместить вторую фотографию, состоящую из фотографии самолета до аварии (или визуально похожей), только если верхняя фотография сделана с фотографии аварии или обломков , ЕСЛИ фотография аварии или обломков существенно отличается от фотографии до аварии; фотография самолета с поврежденным капотом двигателя или помятым носовым обтекателем не нуждается во второй фотографии. Я отмечу, что статья American Airlines Flight 77 , упомянутая в исходном сообщении в этом разделе, использует карту в качестве верхнего изображения, что не соответствует текущим инструкциям шаблона для поля изображения и не должно иметь второго изображения. RecycledPixels ( talk ) 18:05, 8 ноября 2024 (UTC) [ ответить ]