Re: JOSM enhancements vs. separate plugin

[Jiri Hubacek]

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

Re: JOSM enhancements vs. separate plugin

[Martin Koppenhoefer]

sent from a phone

> On 9. May 2018, at 11:29, Dirk Stöcker  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 

Re: translating the strings of plugins

[Florian Schäfer]

The three plugins already translated at Transifex differ from the other plugins 
also in a few other points:* they use another CI provider additionally to or 
instead of the JOSM Jenkins instance (in this case Travis CI)* they use a 
Gradle build additionally to or instead of the Ant build
These are not really prerequisites to use Transifex, but for the plugins built 
with Gradle there's already kind of a procedure to migrate. For plugins using 
Ant you'd need to adapt the Ant build first.
For plugins with a Gradle build (using the `gradle-josm-plugin`) the procedure 
looks something like this:* add a `.tx/config` file to your plugin similar to 
this one: 
https://github.com/JOSM/Mapillary/blob/738be5f6f0f32b19d71dae3ffd15e6822ee3c1b4/.tx/config*
 ask one of the maintainers of the JOSM group at Transifex (e.g. me) to add you 
as a maintainer* get a Transifex API token from 
https://www.transifex.com/user/settings/api/* configure your CI to run 
`./gradlew generatePot` each time a new commit is added to the repository, 
which extracts the translatable strings to a *.pot file* let the CI run the 
Transifex client to upload the *.pot file, e.g.: 
https://github.com/JOSM/Mapillary/blob/3c4ec6ffdb9481df566fe6ff8cbdbd3282b6cb9b/.travis.yml#L61-L66*
 now when you want to update the translations of your plugin, run `./gradlew 
transifexDownload` and the current translations are downloaded from Transifex.
As said above, this is not the only possible way to achieve this, just the one 
that the plugins `geojson`, `Mapillary` and `scripting` chose. We could discuss 
the different variants with their pros and cons and what would be the best way 
to go for the pt_assistant plugin in the (video) conference for GSoC, that 
we'll soon have anyway.
Cheers,floscher
P.S.: Please note that all this is probably heavily biased, since I started 
this switch of some JOSM plugins to Gradle, git and Transifex.

Am Mittwoch, den 09.05.2018, 14:47 +0200 schrieb Jo:
> Oh, I think it would be nice to add PT_Assistant to Transifex. What would be 
> the procedure for that?
> Jo
> 2018-05-09 14:37 GMT+02:00 Florian Schäfer :
> > Hi Polyglot,
> > 
> > 
> > 
> > it's at https://translations.launchpad.net/josm/ .
> > 
> > A few plugins are translated at 
> > https://www.transifex.com/josm/josm/content/ instead.
> > 
> > 
> > 
> > Cheers,
> > 
> > floscher
> > 
> > 
> > 
> > Am Mittwoch, den 09.05.2018, 14:00 +0200 schrieb Jo:
> > 
> > > Hi,
> > 
> > > 
> > 
> > > Do we have a web interface where the strings of JOSM and its plugins can 
> > > be
> > 
> > > translated in a way that is accessible to the general public?
> > 
> > > 
> > 
> > > I can't seem to find it.
> > 
> > > 
> > 
> > > Polyglot
> > 

Re: JOSM enhancements vs. separate plugin

[Michael Zangl]

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

Re: translating the strings of plugins

[Jo]

Oh, I think it would be nice to add PT_Assistant to Transifex. What would
be the procedure for that?

Jo

2018-05-09 14:37 GMT+02:00 Florian Schäfer :

> Hi Polyglot,
>
> it's at https://translations.launchpad.net/josm/ .
> A few plugins are translated at https://www.transifex.com/
> josm/josm/content/ instead.
>
> Cheers,
> floscher
>
> Am Mittwoch, den 09.05.2018, 14:00 +0200 schrieb Jo:
> > Hi,
> >
> > Do we have a web interface where the strings of JOSM and its plugins can
> be
> > translated in a way that is accessible to the general public?
> >
> > I can't seem to find it.
> >
> > Polyglot
>

Re: translating the strings of plugins

[Florian Schäfer]

Hi Polyglot,

it's at https://translations.launchpad.net/josm/ .
A few plugins are translated at https://www.transifex.com/josm/josm/content/ 
instead.

Cheers,
floscher

Am Mittwoch, den 09.05.2018, 14:00 +0200 schrieb Jo:
> Hi,
> 
> Do we have a web interface where the strings of JOSM and its plugins can be
> translated in a way that is accessible to the general public?
> 
> I can't seem to find it.
> 
> Polyglot

translating the strings of plugins

[Jo]

Hi,

Do we have a web interface where the strings of JOSM and its plugins can be
translated in a way that is accessible to the general public?

I can't seem to find it.

Polyglot

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 :


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)

Re: JOSM enhancements vs. separate plugin

[Jo]

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 :

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