Как показано в примере ниже, это было бы полезно в данном случае:
3 лайка
Я не уверен, что это хорошая идея. В конечном итоге мы, как пользователи, не можем исправлять ошибки. Это можно сделать только путём изменения кода Discourse, что требует участия члена команды. Если это не требуется, то категория «Ошибка» вероятно не подходит.
Меня беспокоит, что пользователи будут отмечать обходные пути как решение. Но тогда ошибка так и не будет исправлена. Это вызовет больше путаницы, чем пользы. В вашем примере проблема тоже не решена, поскольку уже есть отчёт об ошибке. Я думаю, что в данном случае лучше объединить темы. Так все пользователи получат уведомление об исправлении, независимо от того, какую тему они изначально отслеживали. Иногда имеет смысл закрыть одну тему со ссылкой на другую, но тогда теряются лайки, поддержавшие закрытую тему, что печально, ведь затронутые пользователи определяются по лайкам и ответам.
3 лайка
В категории bug мы просто используем тег fixed. Сообщение о том, что тема дубликат, на самом деле ничего не решает, несмотря на свою полезность, поэтому я не думаю, что это было бы уместно и там.
Теперь, почему мы используем fixed в некоторых категориях, а solved-plugin в других, я думаю, это связано с тем, что уже сказал Мойн. Теги используются более строго, поэтому только команда может решать, когда что-то исправлено.
5 лайков
Спасибо за предложение! Всегда полезно проверить, как настроены категории, поэтому я ценю, что вы об этом подумали и создали эту тему.
Как отметили Мойн и Чарли, наша команда полагается на закрепленные (fixed) и закрытые темы (действия доступны только нам), чтобы сообщать сообществу, что ошибка, ну, исправлена! Это работает довольно хорошо и позволяет нам вести довольно очевидный список ошибок, требующих исправления.
Действительно, в категории «Ошибки» человек, способный предоставить решение, не получает признания так же, как в категориях, где включен плагин «Решено», что жаль. В категории «Ошибки» человек, сообщивший об ошибке, получает значок, если сообщение понравится члену команды Discourse. Но другие, кто помогал по пути, предоставляя шаги для воспроизведения, указывая на дубликаты, предлагая решения и так далее, не получат признания. Есть над чем подумать.
В данном случае было бы здорово, если бы вы могли отметить Мойна за то, что он указал на дубликат отчета, но сохранение темы создаёт дополнительный шум, что усложняет для команды анализ всех открытых отчётов об ошибках. Поэтому надеюсь, вы не против, но я установил таймер для её удаления.
1 лайк
@tobiaseigen, разве для этого не предназначена функция блокировки? Удаление темы приведёт к тому, что внешние URI, указывающие на неё, будут возвращать ошибку 404, что нежелательно.
Мы не храним всё! 
Не стоит слишком переживать из-за 404.
Однако мы не практикуем это последовательно, так как это требует дополнительной работы. Я считаю, что есть смысл автоматически добавлять тег fixed при закрытии, а для редких случаев, когда исправление не производится, можно вручную добавить специальный тег.
Для этого потребуется внедрить новую автоматизацию.
4 лайка
Мне не раз приходилось сталкиваться с ситуацией, когда я искал информацию, находил ссылку, которая казалась интересной, но при переходе по ней оказывалась ошибка 404, что было крайне неприятно.
В таком случае я бы пометил пост, после чего модератор отредактировал или удалил его.
Чтобы предотвратить это, перед удалением темы стоит проверить раздел со ссылками в первом посте:
А затем превентивно принять меры, удалив эти ссылки, — это было бы лучшим решением, хотя и потребовало бы больше усилий.
2 лайка
Я предложил @tobiaseigen обратное: при добавлении тега fixed автоматически закрывать тему, так же как это делается для тега «solved».
Возможно, ответ — «да, и»? Автоматизация, которая сразу добавляет тег fixed при закрытии и закрывает тему (или планирует её закрытие), если у неё есть тег fixed? Мы можем сделать то же самое в канале ux с тегами fixed и completed.
Бывают ли случаи, когда мы закрываем темы с тегом bug, не добавляя тег fixed? Я вижу много закрытых тем с багами, у которых нет этого тега. Сегодня я проведу немного времени, исследуя этот вопрос.
Мне нравится, как ведёт себя плагин solved: когда решение выбирается, тема автоматически планируется к закрытию через 30 дней после последнего ответа. Это удобно, так как процесс происходит резко, но при этом люди всё ещё могут ответить, если почувствуют в этом необходимость. Это также, вероятно, экономит нашу работу, поскольку пользователи не будут помечать тему с просьбой о её повторном открытии.
1 лайк
Причина, по которой мне не нравится автоматическое добавление тега при закрытии темы (=> add tag), заключается в том, что существуют случаи, когда проблема не была исправлена или она никогда не будет исправлена (wont-ever-fix). Мне кажется, что оптимальный способ — выполнить одно действие («добавить тег»), которое затем автоматически запустит таймер закрытия темы через 30 дней.
2 лайка
Я потратил некоторое время на это и вижу, что у @chapoi верная идея. Я думаю, что нам следует выработать привычку помечать тегом fixed темы, которые были исправлены, а затем создать автоматизацию, которая установит таймер для автоматического закрытия, как это делает плагин solved. Мы всё ещё можем закрывать тему немедленно, если это оправдано, но в некоторых случаях, я считаю, полезно оставить её открытой чуть дольше, чтобы у людей была возможность протестировать и сообщить, если проблема всё ещё сохраняется.
Есть темы, такие как Rendering 'TypeError' with theme components after update, которые, на мой взгляд, не должны получать тег fixed, потому что ошибка, о которой сообщалось в первом посте, не была исправлена. В этом примере инженер, пытавшийся исправить проблему, не смог воспроизвести её.
Также есть After deleting a topic, the delete button shows up instead of the restore button, которая была закрыта как дубликат. Я предполагаю, что когда будет исправлена тема Deleting a topic cannot be undone, обе можно будет пометить тегом fixed и закрыть? Но как нам убедиться, что это произойдёт?
В категории bug есть множество тем, которые закрыты, но не имеют тега fixed. Нам нужно будет ретроспективно просмотреть их и проанализировать.
3 лайка
Моя проблема здесь — в удобстве использования. Я хочу, чтобы у инженеров было решение в один клик.
- Нажмите «Исправлено» в действиях темы или в административных действиях темы.
- Произойдет магия:
- Будет создан таймер темы для закрытия через 1 рабочий день.
- Тема будет помечена тегом «исправлено».
Мне не нравится UX для простого «добавления тега к теме», так как это создает слишком много трения:
- Перейдите к началу темы.
- Нажмите на заголовок.
- Нажмите на поле тегов.
- Найдите «исправлено».
- Добавьте «исправлено».
- Поставьте галочку.
Это слишком много шагов.
Я не против добавить этот процесс, но нам понадобится компонент темы или какая-то автоматизация, внедряющая этот интерфейс (что также может быть полезно).
4 лайка
Я с вами! Я тоже думал об удобстве использования, когда предлагал «да, и» выше. Сейчас у нас выработана привычка просто закрывать темы bug, когда они исправлены. Это также соответствует тому, как мы обрабатываем задачи внутри компании.
Мне нравится идея кнопки «Исправлено» в один клик.
1 лайк
И сообщество справилось 
6 лайков
Круто! Я попробовал компонент темы Нейта на своём личном сайте, и он работает именно так, как заявлено. Отличная работа, да ещё и реализована очень быстро! 
Чтобы использовать его здесь, нам нужно было бы ограничить его одной категорией. Если мы решим, что этот подход работает хорошо, нам также понадобится возможность создавать более одной кнопки.
К сведению: Сэм также работает над экспериментальной реализацией, которая отличается и гораздо более гибкая, благодаря использованию автоматизации.
2 лайка
Я думаю, что это изменение существенно помогло бы нам здесь, на Meta. Я связался с внутренней командой, чтобы узнать, можно ли реализовать это либо с помощью экспериментальной автоматизации от Сэма, либо путём форка компонента темы от Нейта и его использования здесь.
Компонент Нейта фактически делает то же самое и выглядит очень неплохо, но нам пришлось бы его форкнуть, так как на Meta мы не устанавливаем сторонние компоненты или плагины. 
1 лайк
Если вы так поступите, то поступите честно, предложив Нейту финансовую благодарность — как это делается за выявленные уязвимости в области кибербезопасности через HackerOne.
2 лайка
Давайте сосредоточимся на том, принесет ли сообществу пользу использование компонента темы от Нейта. Если да, мы обсудим с Нейтом технические детали.
С радостью создам отдельную тему о том, как в целом вознаграждаются участники с открытым исходным кодом, если вы хотите.
2 лайка