On Thu, Apr 11, 2013 at 1:51 AM, Joe Dreimann <[email protected] > wrote:
> No objection to that. > > Two questions: > 1) Was it the error report that got the user to think it is a Trac > problem? Do we need to amend this? > I suspect most users don't look very closely at the content of the error report. The Internal Error page has a link for opening an issue on trac.edgewall.org, which populates the ticket description with the user's Trac configuration. The user only has to click two buttons to create a ticket on trac.edgewall.org. I suspect that in most cases, the user doesn't carefully consider where the ticket should be reported, but just clicks the two buttons to create a ticket. However, we can change where that ticket is created with a small change to the Trac source. [image: Inline image 1] > 2) Should we encourage people using bloodhound to raise all issues to us > (incl likely Trac ones)? > There is some relevant discussion about that in [1]. It appears to be possible to change where the `Create` button direct to. I tried modifying the `default_tracker` variable [2], and it appears to work as advertized. In the case that the reporter has an account on issues.apache.org/bloodhoundand is already logged-in, the ticket would be easily created in the Bloodhound issue tracker. If the user is not logged-in to i.a.o/bloodhound, they land on the login page, however even after logging-in they are not redirected to the /newticket page with a populated form. That may just be a separate issue we need to address to make the error reporting process go more smoothly. After changing the `default_tracker` variable, there may still be some cases that the `Create` button causes issues to be reported to trac-hacks [3]. > I would say yes to the second one because so far we've always kept tickets > like that open as a reference and raised one upstream. For users that makes > our site a single point of contact, and we know what it is upstream that > affects them. > > Cheers, > Joe > That sounds good to me as well. The argument for single point of contact seems like a good one. [1] http://trac.edgewall.org/ticket/10898 [2] http://trac.edgewall.org/browser/tags/trac-1.0.1/trac/web/main.py?marks=55-58#L53 [3] http://trac.edgewall.org/browser/tags/trac-1.0.1/trac/web/main.py?marks=554#L546
