Trac Edgewall Org New Ticket Screen misses to inform users about spam rejection

[ilias@…]

​http://trac.edgewall.org/newticket

This location should inform users about the current status of spam-protection mechanisms.

e.g.: please use ​http://trac.edgewall.org/settings to provide an email/name if you have problems with spam rejection.

[Emmanuel Blot]

e.g.: please use ​http://trac.edgewall.org/settings to provide an email/name if you have problems with spam rejection.

Would not this be a great hint for spammers?

[ilias@…]

Replying to eblot:

e.g.: please use ​http://trac.edgewall.org/settings to provide an email/name if you have problems with spam rejection.

Would not this be a great hint for spammers?

possibly.

but fighting spam should not have priority over usability.

this user has asked ​within the devel mailinglist. Others just go away.

[Emmanuel Blot]

but fighting spam should not have priority over usability.

I'm not sure whether you realize what actually happens when trac.edgewall.org gets really spammed: all tickets may be polluted, so usability is in concern here as well.

The current situation is far from being optimum, but giving all the hints to spam trac.edgewall.org is not an option, IMHO.

[cboos ''not logged in'']

I begin to take the habit of not logging in anymore, so that I can feel how things are going for non-authenticated users. So far, so good ;)

[ilias@…]

Replying to eblot:

but fighting spam should not have priority over usability.

I'm not sure whether you realize what actually happens when trac.edgewall.org gets really spammed: all tickets may be polluted, so usability is in concern here as well.

I understand fully.

But this is a matter of defining goals and requirements. Just review this message for a clarification:

You should simply look at this prioritized requirements list for the
trac.edgewall.org:

a) Allow contributors to interact with the trac development team
b) Allow users to interact with the trac development team
c) Allow anonymous access on trac.edgewall.org

Focusing on requirement "C" needs 'science & art' (spam-filter), and
should not block requirement "A" (fulfilled with simple registration on
request) and "B" (fulfilled with e.g. automated registration). 

​http://groups.google.com/group/trac-dev/msg/3a808d7c072ee749

[Emmanuel Blot]

A & B are still possible through the mailing list, until a better solution is implemented.

You don't need to quote yourself ;-)

To rephrase the original request for this ticket, the message to add to an Askimet-triggered error page could be something like "please use the ML if your incident submission is rejected". Plus, that would allow to prefilter incidents that are already solved, already known, as well as installation-related tickets. Subversion team is using this two-phase incident submission (ML, then ticket if incident is confirmed).

[ilias@…]

Replying to eblot:

A & B are still possible through the mailing list, until a better solution is implemented.

ok

You don't need to quote yourself ;-)

??? just pointed to a relevant discussion and quoted excerpt for readers convenience.

To rephrase the original request for this ticket, the message to add to an Askimet-triggered error page could be something like "please use the ML if your incident submission is rejected".

sounds ok.

except that this should be stated on "New Ticket System Screen" (to avoid the frustration of writing an essay first).

Plus, that would allow to prefilter incidents that are already solved, already known, as well as installation-related tickets. Subversion team is using this two-phase incident submission (ML, then ticket if incident is confirmed).

sounds fine, too.

[cmlenz (not logged in)]

I hope this won't even be necessary with the recent improvements to SpamFilter. Things are looking good. Knock on wood.

[ilias@…]

Replying to cmlenz (not logged in):

I hope this won't even be necessary with the recent improvements to SpamFilter. Things are looking good. Knock on wood.

As it look, things work fine, closing