JOSM enhancements vs. separate plugin

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

JOSM enhancements vs. separate plugin

Jiri Vlasak
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

Reply | Threaded
Open this post in threaded view
|

Re: JOSM enhancements vs. separate plugin

Jo-2
I guess it all depends on availability of time of the core team. What
surprises me is that plugins that everybody probably have installed like
buidings-tools and utilsplugin2 are not 'adopted' into core. That probably
tells you something about how likely it is that others would be.

Polyglot

2018-05-09 7:25 GMT+02:00 Jiri Hubacek <[hidden email]>:

> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: JOSM enhancements vs. separate plugin

Dirk Stöcker
On Wed, 9 May 2018, Jo wrote:

> I guess it all depends on availability of time of the core team. What
> surprises me is that plugins that everybody probably have installed like
> buidings-tools and utilsplugin2 are not 'adopted' into core.

No single plugin has more than 50% user base. Even not the ones
automatically installed with windows installer.

> That probably tells you something about how likely it is that others
would be.

No. It tells you nothing.

As utilsplugin2 is specifically our "not ready or wanted for core"
test plugin your comment is even less useful.

> 2018-05-09 7:25 GMT+02:00 Jiri Hubacek <[hidden email]>:
>>
>> 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?

There are guidelines, but they are not easy to explain. It is a personal
decision based on a few major questions:

- is the function interesting for a large part of the user base
- does it fit into the overall concept of the editor
- is it mature enough to be in the core
- do we want to be responsible for it in the future
- does the LICENSE match the core requirements
- is there already a similar functionality

So chances for generic important mature functions with no similar feature
existing are good. For others not.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Reply | Threaded
Open this post in threaded view
|

Re: JOSM enhancements vs. separate plugin

Michael Zangl-3
In reply to this post by Jiri Vlasak
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
>


Reply | Threaded
Open this post in threaded view
|

Re: JOSM enhancements vs. separate plugin

dieterdreist
In reply to this post by Dirk Stöcker


sent from a phone

> On 9. May 2018, at 11:29, Dirk Stöcker <[hidden email]> wrote:
>
> No single plugin has more than 50% user base. Even not the ones automatically installed with windows installer.


interesting, do you also have numbers for the operating systems used by Josm users in general (win, linux, osx, other unixes, etc.)?


cheers,
Martin
Reply | Threaded
Open this post in threaded view
|

Re: JOSM enhancements vs. separate plugin

Jiri Vlasak
In reply to this post by Michael Zangl-3
Guys,

thanks a lot, I do have the answer. The script is not generic.

Have a nice day,
jiri

On 05/09/2018 02:50 PM, Michael Zangl wrote:

> 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
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: JOSM enhancements vs. separate plugin

Dirk Stöcker
In reply to this post by dieterdreist
Hello,

> interesting, do you also have numbers for the operating systems used by Josm users in general (win, linux, osx, other unixes, etc.)?

Yes.

BSD     ~  0%
Mac     ~  8%
Linux   ~ 27%
Windows ~ 65%

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

Reply | Threaded
Open this post in threaded view
|

Re: JOSM enhancements vs. separate plugin

dieterdreist
2018-05-10 23:38 GMT+02:00 Dirk Stöcker <[hidden email]>:

> Hello,
>
> interesting, do you also have numbers for the operating systems used by
>> Josm users in general (win, linux, osx, other unixes, etc.)?
>>
>
> Yes.
>
> BSD     ~  0%
> Mac     ~  8%
> Linux   ~ 27%
> Windows ~ 65%
>



Thank you. For comparison, these are numbers for market share and the
difference to JOSM (April 2018) [1]:

BSD 0%  (the same, either they are very niche or they are in the 2,45%
unknown and use an OS that effectively protects them from revealing their
OS)
OSX 13,2% JOSM has 40% less OSX users compared to their supposed market
share
Linux 1,7% JOSM has 1588% of Linux users ...
Win 81,7% JOSM has 20% less Win users

these are alternative numbers [2]

BSD 0.01 %
OSX 8,7%  -> -8%
Linux 2,3 % -> 1174%
Windows 88,6 % -> -27%


__
[1] http://gs.statcounter.com/os-market-share/desktop/worldwide
[2]
https://netmarketshare.com/operating-system-market-share.aspx?options=%7B%22filter%22%3A%7B%22%24and%22%3A%5B%7B%22deviceType%22%3A%7B%22%24in%22%3A%5B%22Desktop%2Flaptop%22%5D%7D%7D%5D%7D%2C%22dateLabel%22%3A%22Trend%22%2C%22attributes%22%3A%22share%22%2C%22group%22%3A%22platform%22%2C%22sort%22%3A%7B%22share%22%3A-1%7D%2C%22id%22%3A%22platformsDesktop%22%2C%22dateInterval%22%3A%22Monthly%22%2C%22dateStart%22%3A%222017-05%22%2C%22dateEnd%22%3A%222018-04%22%2C%22segments%22%3A%22-1000%22%7D
Reply | Threaded
Open this post in threaded view
|

Re: JOSM enhancements vs. separate plugin

Dirk Stöcker
On Fri, 11 May 2018, Martin Koppenhoefer wrote:

>> BSD     ~  0%
>> Mac     ~  8%
>> Linux   ~ 27%
>> Windows ~ 65%
>
> Thank you. For comparison, these are numbers for market share and the
> difference to JOSM (April 2018) [1]:
>
> BSD 0%  (the same, either they are very niche or they are in the 2,45%
> unknown and use an OS that effectively protects them from revealing their OS)
> OSX 13,2% JOSM has 40% less OSX users compared to their supposed market
> share Linux 1,7% JOSM has 1588% of Linux users ...
> Win 81,7% JOSM has 20% less Win users
>
> these are alternative numbers [2]
>
> BSD 0.01 %
> OSX 8,7%  -> -8%
> Linux 2,3 % -> 1174%
> Windows 88,6 % -> -27%

These numbers had always a systematic bias towards Windows. They are a
sales marketshare and not a realistic representation of OS usage. E.g. all
my private and nearly all the company computers I bought are counted as
Windows systems, but they all operate under Linux. Only for embedded or
industrial systems and servers it actually makes sense to buy a system
without preinstalled Windows. But even these are probably not counted as
Linux systems.

So probably JOSM's numbers are simply more realistic. That MacOS numbers
are similar is a good indicator for that assumption.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)