Баги вида "хочу в команду" содержат email-адреса. Для уменьшения количества спама неплохо было бы эти баги по умолчанию заносить в группу, видимую только join-секретарю и (если таковые появятся) остальным участвующим в join-процессе.
Ээ, тоже хочу видеть эти баги.
Для этих целей в Bugzilla предназначен атрибут private, который можно выставлять как на комментарий, так и на описание. Для документирования и для чайников может помочь bookmarkable template. Пример сохраненного образца: https://landfill.bugzilla.org/bugzilla-3.2-branch/enter_bug.cgi?bug_status=NEW&comment=Hello%20spammers%2C%20my%20email%20is%20dummy%40example.com&commentprivacy=on&component=%D0%9A%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%201.1&form_name=enter_bug&product=%D0%9F%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%201&short_desc=I%20want%20to%20join%20a%20team
Как форсировать скрытие бага при занесении его в определённый компонент?
> Как форсировать скрытие бага при занесении его в определённый компонент? Если под скрытием понимать атрибут private -- только писать hook. Как определить в каком комментарии (или нулевом) содержится смерть кощея? Экспертная задача, также решаемая для security-sensitive ошибок. Если скрывать всю ошибку целиком -- ничего писать не надо, закрытая группа по аналогии с security и включать туда сразу при регистрации. НО все эти методы зависят от правильного выбора продукта+компонента при регистрации. Честнее (и эргономичнее) иметь шаблоны, документировать их существование, и выкладывать на передние страницы. Только цитировать их напрямую в документации не советую: трудно будет менять потом. Разве что через редиректор a la tinyurl.
см. также https://bugzilla.mozilla.org/show_bug.cgi?id=335434
По здравому размышлению: любая страница с багом содержит в себе кучу адресов. Ещё один ничего не изменит.
