When opening new ticket from JOSM, pre-fill component field (if known)

[floscher]

When a plugin throws an exception and JOSM asks you to report the issue as new ticket, at least the component field should be pre-filled with the right plugin.

This can be achieved by using the query string parameter component, additionally to pdata_stored. Then not so many issues have to be re-categorized, because not all JOSM users who create tickets are able to find out from the status report from which component the issue originated.

Maybe it would even be helpful to pre-fill other fields, like populating the summary field with the thrown exception and the class and line where it occured. E.g. UnknownHostException: wwww.example.org (thrown in SomeClass).

The URL that JOSM should open could then look something like this:
https://josm.openstreetmap.de/josmticket?component=Plugin%20wikipedia&summary=UnknownHostException%3A%20wwww.example.org%20%28thrown%20in%20SomeClass%29&pdata_stored=01234567890123456789abcd

[Klumbumbus]

While we are on bugreports, I suggest to change

==== What steps will reproduce the problem?
1. 
2. 
3. 

==== What is the expected result?

==== What happens instead?

==== Please provide any additional information below. Attach a screenshot if possible.

to

==== What steps will reproduce the problem? ====
1. 
2. 
3. 

==== What is the expected result? ====


==== What happens instead? ====


==== Please provide any additional information below. Attach a screenshot if possible. ====

About once every month we get a bug report where the users doesn't understand the meaning of ==== and writes his text directly behind the question "destroying" the layout. With this change this will be muss less likely happen.

[stoecker]

Hmm. It's not so easy to get the right component. There are many cases where the JOSM detector detects the wrong plugin or plugins are blamed whereas this is a core issue and so on. I don't find that manual re-categorization a big issue for these reports where stack traces and information are complete.

[floscher]

At least for plugins it should be relatively straightforward to determine the component. The dialog that asks the user to decide if a pugin should be disabled or kept seems to already know the source of the exception.

For other components this might be not as clear, then the component could still be Core.

[anonymous]

Replying to floscher:

At least for plugins it should be relatively straightforward to determine the component. The dialog that asks the user to decide if a pugin should be disabled or kept seems to already know the source of the exception.

That's a guess based on the stack trace. It takes the first stack line asignable to a plugin and assumes this was the faulty code. That's fine for an update request (from developers point updates are never wrong), but I'm not sure it is enough for ticket assignment.