Hi,
About your concrete example: There are several questions to think of:
* Is your functionality a generic task? (in your case, this would be
something like "create a convex hull")
* Is that functionality required by a lot of users?
* Is your functionality approved by the community? Or will there be
objections? In your case, you should especially mind if your plugin
creates "correct" results and if it can be applied by a unexperienced
user without creating incorrect data.
* Does it integrate into JOSM in an intuitive way? We try not to add
more buttons to the main menu. A nice example is the reworked download
dialog last year: It added some overpass download features while at the
same time making the UI easier to understand.
So if there is a place where this feature could be included that does
not interfere with other functionality (e.g. in a preset, ...) and is
universally usable, it can/should be included in core. In your case, the
script is so special that it may be very useful for other people doing
exactly the task you do, but not for the general audience of JOSM. This
is why a plugin is best in this case.
There are several more reasons why we add a functionality to core. They
include:
* It is a function that allows basic access to the Openstreetmap data.
Like the notes layer: There are probably relatively few people using it
and it would be easy to extract to a plugin, but it is a traditional
feature of the OSM website.
* It is a function that many other plugins / workflows may depend on.
Like downloading Data using Overpass.
* It is a feature that is used by JOSM internally and where providing it
for the user just means an other button, but not maintaining more code.
Like the Join overlapping Areas tool.
* The author of that functionality had core commit access and just was
too lazy to write a plugin for it. One example I did are the color
filters on imagery layers (mainly because they required core
modifications any way and were much easier to integrate that way).
Michael
On 09.05.2018 07:25, Jiri Hubacek wrote:
Dear JOSM devs,
I would like to ask question about the JOSM enhancements. Where is the
line between functionality acceptable upstream and the feature that
should be in separate plugin?
The concrete example - I wrote some script for automatic creation of
residential area around the selected buildings. I rewrote it to Java to
be able to push it upstream but it looked too specific to be included in
"Tools" menu. So I created the plugin (mapathoner). Are there any
guidelines for these decisions?
Thanks,
jiri
