Re: [OSM-dev] Removing functionality and giving just No as answer

[Pierre Béland]

   On 08/03/17 Tom Hugues wrote:

> There is a cargo cult belief that you need to force dirty the tile at 
> the renderer but that is almost never the case - any changes to nodes 
> and ways will automatically dirty the relevant tiles. Only changes to 
> relations are not handled automatically.

> Now there was a bug for much of last week where that wasn't happening 
> properly - that was fixed on Friday morning and all the missed tile 
> expiries were processed over the next 24 hours.

> What is normally an issue is the squid caches that sit in front of the 
> renderers, but a simple shift-reload will bust those caches and in fact 
> a manual dirty will do nothing at all to help with those.

We still need to dirty for lower zoom levels. A few months ago, dirty did work 
to modify tiles under zoom 13. But no success actually.

I Updated the way for Parc Macaya a few days ago. Zoom 12 and under, the tiles 
are still not rendered even if I dirty or reload the page (ctrl-F5 with 
Mozilla). 
See http://www.openstreetmap.org/way/398987126#map=11/18.3793/-73.8789
 
Pierre 

   ___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Yves]

It's like the close door button in an elevator, you know it usually does not 
speed things up, but it feels good to press it anyway. 
Yves 

Le 8 mars 2017 13:03:32 GMT+01:00, Tom Hughes  a écrit :
>On 08/03/17 09:35, joost schouppe wrote:
>
>> While a lot of the comments are a bit misguided, I think it is clear
>> that quite a few mappers use this dirty trick to get the render to
>> refresh. As OSM.org is supposed to be a mapper's tool and not a
>general
>> public website, I think it is quite obvious that a
>forced-tile-refresh
>> function is within the scope of the website.
>
>There is a cargo cult belief that you need to force dirty the tile at 
>the renderer but that is almost never the case - any changes to nodes 
>and ways will automatically dirty the relevant tiles. Only changes to 
>relations are not handled automatically.
>
>Now there was a bug for much of last week where that wasn't happening 
>properly - that was fixed on Friday morning and all the missed tile 
>expiries were processed over the next 24 hours.
>
>What is normally an issue is the squid caches that sit in front of the 
>renderers, but a simple shift-reload will bust those caches and in fact
>
>a manual dirty will do nothing at all to help with those.
>
>Tom
>
>-- 
>Tom Hughes (t...@compton.nu)
>http://compton.nu/
>
>___
>dev mailing list
>dev@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/dev
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Tom Hughes]

On 08/03/17 09:35, joost schouppe wrote:


While a lot of the comments are a bit misguided, I think it is clear
that quite a few mappers use this dirty trick to get the render to
refresh. As OSM.org is supposed to be a mapper's tool and not a general
public website, I think it is quite obvious that a forced-tile-refresh
function is within the scope of the website.


There is a cargo cult belief that you need to force dirty the tile at 
the renderer but that is almost never the case - any changes to nodes 
and ways will automatically dirty the relevant tiles. Only changes to 
relations are not handled automatically.


Now there was a bug for much of last week where that wasn't happening 
properly - that was fixed on Friday morning and all the missed tile 
expiries were processed over the next 24 hours.


What is normally an issue is the squid caches that sit in front of the 
renderers, but a simple shift-reload will bust those caches and in fact 
a manual dirty will do nothing at all to help with those.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[joost schouppe]

Just to clarify, Tom, would the example given by mmd (
http://www.sammyshp.de/fsmap/#18/51.01486/13.63683) be something you would
deem acceptable in osm.org?


BTW, one of the places where people were "canvasing" was here:
https://www.reddit.com/r/openstreetmap/comments/5uvbby/the_openstreetmaporg_map_now_has_a_rightclick/

While a lot of the comments are a bit misguided, I think it is clear that
quite a few mappers use this dirty trick to get the render to refresh. As
OSM.org is supposed to be a mapper's tool and not a general public website,
I think it is quite obvious that a forced-tile-refresh function is within
the scope of the website.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[mmd]

Am 24.02.2017 um 12:19 schrieb Tom Hughes:

> 
> More specifically there were a number of people asserting that this
> feature was somehow to all mappers and I was trying to make the point
> that really that wasn't true at all and that the was majority of mappers
> would never have any use for it.
> 

Well, even the first ever book on OSM written by Frederik and Jochen
back in 2010 describes a manual procedure to append /status and /dirty
to tile URLs. Also, the approach has been described a number of times on
OSM Forum and Help and even been recommended to absolute newbies on
different occasions. I'm pretty sure that folks who have been around for
some time at least have some passive knowledge about it.

As a side note, 'fsmap' created by user SammysHP has a nice right-click
context menu to show the current tile, check its status and request
re-rendering. Maybe that could be something worth considering for
osm.org as well?

http://www.sammyshp.de/fsmap/#18/51.01486/13.63683

-- 



___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Wesley Duffee-Braun]

I'm new to OSM @dev but I see a couple of items that have come up on this
thread I wanted to try and note...

First, what is actually the request in Issue 1446? Yes, the word-by-word
request is to add the entry back to the right-click menu, but it seems a
little more than that. Useful (at least to some) functionality was removed
without replacement. While there is a browser workaround, that is
apparently not useable for everyone. I personally feel like Tom is correct
in saying that the entry doesn't need to be in the right-click menu for
everyone. But the functionality was removed from one location (the menu)
without it being provided elsewhere - that changes the discussion from
being one of UX and shifts it to dictating what users should and shouldn't
be doing with the tool.

The feeling I got from the Issue thread wasn't "the maintainer doesn't see
this functionality as being appropriate for the right-click menu" but
rather "the maintainer doesn't want to provide that functionality to the
user at all". That's likely not what the maintainer meant, but I feel like
that's what came out. And the more there was push back on adding that
functionality *in the menu*, the more the requestors pushed to add it
because they missed the functionality.

I honestly don't think that anyone cares if it is in the right-click menu
for everyone, just that it is available to those users who want it. Perhaps
long-term there could be an "advanced" or "developer" or "kitchen sink"
mode which can be set in the users profile, which enables these kinds of
menu entries while keeping the base UI cleaner? In the mean time since
there is a PR already, why not add it back into the menu?

The second issue is something I've seen arise up a few times on the dev@
list...who sets the agenda. I agree with Dmitry: "the community have no way
to affect pull requests or roadmap items." Of course open source isn't
purely a popularity contest, but if the push back from maintainers is (as
in this instance) "you aren't the norm" then naturally the person making
the request will gather people to +1 their request. That's not getting devs
getting railroaded, that's users advocating for themselves and their
priorities.

Tom, when you say "Can you give me any example of an major open source
project that accepts changes on the basis of self appointed voting - ie
that says that so long as you can get N people to say they want it then it
should go in no matter what?" that's an oversimplification of the way open
source decisions are made and disingenuous. It comes back to organization
and transparency, and expectations of how many engineering resources are
available and what needs to be done by particular milestones. When the time
comes to prioritize however, if everyone assigns their vote to an issue and
nothing else is blocked...then...well, unless it is something clearly out
of line with the project's goals, then that's what is going to get done.

Right now it seems like there isn't a way to get code merged unless -
frankly - you want it to be there. There have been a number of complaints
(on all sides) about the lack of core contributors, but when a PR is made
for a relatively simple issue and then n'acked (as in this case) based on
one person's UX visionthen what message is that sending to potential
core contributors?

best
wesley

On Fri, Feb 24, 2017 at 11:38 AM, Дмитрий Киселев <
dmitry.v.kise...@gmail.com> wrote:

> Ok, lets continue with our current
> "I'm the boss, that's why" approach.
>
> 2017-02-24 13:25 GMT-04:00 Yves :
>
>> I have personally three use cases:
>> a) trigger a faster? rerender in a mapping situation I'm not sure of
>> myself
>> b) compare a tile with another
>> c) get the tile scheme right zyx or zxy?
>> ___
>> dev mailing list
>> dev@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/dev
>>
>>
>
>
> --
> Thank you for your time. Best regards.
> Dmitry.
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>
>


-- 
http://www.wesleyduffeebraun.com
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Дмитрий Киселев]

I didn't want to be offencive,
sorry if my mail sounds like personall offence,
I didn't meant Tom or anybody personally.

Most of the open-source projects, as I think,
quite authoritarian about commits and pull requests
and ruled the way "I'm the boss, fork it if you are desagree"

I would be happy, if wider osm community have some kind of procedure,
for giving developers more broad and influent feedback about
accepted/rejected pull requests.


2017-02-24 14:25 GMT-04:00 Ian Dees :

> Hi folks,
>
> Please consider this a reminder that we should maintain a civil discourse,
> stay on topic, and not make any personal attacks.
>
> The governance of critical pieces of our software ecosystem are important
> to talk about, but please don't attack or ridicule individuals.
>
> Your friendly mailing list moderator,
> Ian
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>
>


-- 
Thank you for your time. Best regards.
Dmitry.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Ian Dees]

Hi folks,

Please consider this a reminder that we should maintain a civil discourse,
stay on topic, and not make any personal attacks.

The governance of critical pieces of our software ecosystem are important
to talk about, but please don't attack or ridicule individuals.

Your friendly mailing list moderator,
Ian
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Дмитрий Киселев]

Ok, lets continue with our current
"I'm the boss, that's why" approach.

2017-02-24 13:25 GMT-04:00 Yves :

> I have personally three use cases:
> a) trigger a faster? rerender in a mapping situation I'm not sure of
> myself
> b) compare a tile with another
> c) get the tile scheme right zyx or zxy?
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>
>


-- 
Thank you for your time. Best regards.
Dmitry.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Yves]

I have personally three use cases:
a) trigger a faster?  rerender in a mapping situation I'm not sure of myself 
b)  compare a tile with another 
c)  get the tile scheme right zyx or zxy? ___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Tom Hughes]

On 24/02/17 17:15, Дмитрий Киселев wrote:


The key thing is that you need some mechanism for appointing people
to that circle of maintainers who get to vote on which things should
be included and which shouldn't. On most projects that is done by
promoting from those making useful contributions, so it's hard to
move in that direction until we can get more people involved.


Going that way, maintainer will fall into approval buble, people who
shares maintainers vision have higher chance to become a "good" committer,Â
so feedback from users who doesn't share yours vison become smaller and
smaller.


Can you give me any example of an major open source project that accepts 
changes on the basis of self appointed voting - ie that says that so 
long as you can get N people to say they want it then it should go in no 
matter what?



I agree that comments on gh isn't the message board, and not all commits
should be applyed and authours/maintainers vision should be respected,Â
but now we are in quite a weird state:Â


Well that completely contradicts your previous paragraph.

You can't say that there should be a person or persons in charge of 
looking after the overall vision and deciding what fits and what doesn't 
and then say that somehow feedback from "enough" users can somehow 
override that.



We have discussion and voting procedure for tags even for the very
specific tags, like electrical power scemes.


Which works because the real mappers then just ignore the vote and carry 
on as before ;-)


Seriously, the wiki tag voting is not a good example for, well, anything 
really.



But for software, the community have no way to affect pull requests or
roadmap items.


Anybody can effect the "roadmap" because we don't have one. Like most 
open source projects we don't have people we can instruct to follow some 
roadmap so we rely on people writing code and offering it so that is how 
you affect the roadmap.


Yes if you're not a programmer then that doesn't help you but I'm not 
sure what else would - you can propose things on github until you're 
blue in the face but if there's nobody interested in implementing them 
then it's not going to happen.


As to "affecting pull requests" what I'd really love is a concrete 
proposal of how you think this would work - are you really suggesting 
that if enough people say "+1" then it should go in no matter what the 
maintainer(s) think of it? I think if you do that you will have trouble 
keeping maintainers involved.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Дмитрий Киселев]

>
> Actually carto has had multiple maintainers for some time. Indeed the
> original maintainer, who I assume you are referring to, is not actually
> doing very much these days.
> While osm.org has only one maintainer we have been getting some more
> contributors recently.

Andy has been refactoring the tests to use factories instead of fixtures (a
> big job) and Herve has been updating the emails we send out to start with.


I didn't mean the exact number of contributors, my thought was mainly about
the way how the decisions are made.

The key thing is that you need some mechanism for appointing people to that
> circle of maintainers who get to vote on which things should be included
> and which shouldn't. On most projects that is done by promoting from those
> making useful contributions, so it's hard to move in that direction until
> we can get more people involved.


Going that way, maintainer will fall into approval buble, people who shares
maintainers vision have higher chance to become a "good" committer,
so feedback from users who doesn't share yours vison become smaller and
smaller.

I agree that comments on gh isn't the message board, and not all commits
should be applyed and authours/maintainers vision should be respected,
but now we are in quite a weird state:

We have discussion and voting procedure for tags even for the very specific
tags, like electrical power scemes.
Yes there are many problems with tag voting too, but at least tag author
could get some feedback from broad auditory not only from same minded guys.
But for software, the community have no way to affect pull requests or
roadmap items.



2017-02-24 12:34 GMT-04:00 Tom Hughes :

> On 24/02/17 16:24, Дмитрий Киселев wrote:
>
> > at this moment, we have some widely used resources such as osm.org
> > and osm carto, started and threated as single persons gh repository.
>
> Actually carto has had multiple maintainers for some time. Indeed the
> original maintainer, who I assume you are referring to, is not actually
> doing very much these days.
>
> While osm.org has only one maintainer we have been getting some more
> contributors recently. Andy has been refactoring the tests to use factories
> instead of fixtures (a big job) and Herve has been updating the emails we
> send out to start with.
>
> And we (osm community) don't have a way to discuss and evaluate changes
>> in collaborative way.
>>
>
> That can certainly work, and I've discussed it with people in the past
> although not everybody has always agreed with the idea.
>
> The key thing is that you need some mechanism for appointing people to
> that circle of maintainers who get to vote on which things should be
> included and which shouldn't. On most projects that is done by promoting
> from those making useful contributions, so it's hard to move in that
> direction until we can get more people involved.
>
> Note that when I say vote here I don't necessarily mean literally as there
> are different models - some projects have a formal vote of some sort for
> each feature (often requiring at least one +1 and no -1 for example) while
> others allow maintainers to decide on their own but with a reversion
> mechanism if somebody objects.
>
> Note that you do need to preselect the voting group, otherwise anybody
> that can drum up enough +1's can get anything in.
>
>
> Tom
>
> --
> Tom Hughes (t...@compton.nu)
> http://compton.nu/
>



-- 
Thank you for your time. Best regards.
Dmitry.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Daniel Koć]

W dniu 24.02.2017 16:59, Darafei "Komяpa" Praliaskouski napisał(a):


If you look at it, it's not "community developed this", or "OSMF
developed this", or even "a private club developed this" which you
paint as a dark scenario.

It's being mostly written and deployed by the same person.
This is Bus Factor 1 scenario.


Well, for me it looks like this is not as bad as you say:
https://blog.gravitystorm.co.uk/2017/02/21/steady-progress-osm-website/

But it's not that good either:
https://blog.gravitystorm.co.uk/2016/07/28/getting-involved-in-owg/

"The club" is rather tight now, but at least one person is aware that 
more people would be needed to allow smooth operations and development. 
The main issue seems to be how to attract them?


Sadly, this is not the only fragile element in OSM ecosystem.

We had this "Bus Factor 1 scenario" with forum lately. Fortunately no 
bus was involved and no admin was harmed, but Lambertus has effectively 
"stepped down" one day and was very hard to reach. It ended up with 
saner and more balanced forum management (server migration from 
independent location into OSMF controlled one and 3 new admins), so it's 
much better now than before admin became inactive.


OSM-carto development has also its own problems, although far from being 
that serious. While there's more people on the board with merging rights 
lately, it's still no more than few people active there and agreement is 
rather hard to reach.


I have no idea how to attract more people and at the same time not 
stress the active people even more than they're now. Yet, it's a 
dangerous situation and I hope it will be resolved before some bad 
things will strike us again.


--
"Like a halo in reverse" [M. Gore]

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Tom Hughes]

On 24/02/17 16:24, Дмитрий Киселев wrote:

> at this moment, we have some widely used resources such as osm.org
> and osm carto, started and threated as single persons gh repository.

Actually carto has had multiple maintainers for some time. Indeed the 
original maintainer, who I assume you are referring to, is not actually 
doing very much these days.


While osm.org has only one maintainer we have been getting some more 
contributors recently. Andy has been refactoring the tests to use 
factories instead of fixtures (a big job) and Herve has been updating 
the emails we send out to start with.



And we (osm community) don't have a way to discuss and evaluate changes
in collaborative way.


That can certainly work, and I've discussed it with people in the past 
although not everybody has always agreed with the idea.


The key thing is that you need some mechanism for appointing people to 
that circle of maintainers who get to vote on which things should be 
included and which shouldn't. On most projects that is done by promoting 
from those making useful contributions, so it's hard to move in that 
direction until we can get more people involved.


Note that when I say vote here I don't necessarily mean literally as 
there are different models - some projects have a formal vote of some 
sort for each feature (often requiring at least one +1 and no -1 for 
example) while others allow maintainers to decide on their own but with 
a reversion mechanism if somebody objects.


Note that you do need to preselect the voting group, otherwise anybody 
that can drum up enough +1's can get anything in.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Дмитрий Киселев]

My five cents:

at this moment, we have some widely used resources such as osm.org and osm
carto,
started and threated as single persons gh repository.

And we (osm community) don't have a way to discuss and evaluate changes in
collaborative way.
Usually maintainer just decides "Do I love this feature or not" and that's
a kind of a problem.

Yes "+ one" can say nothing about millions of other users, but neighter
main maintainer can.

I think we have to have key features as osm.org and main style maintained
in more open way.

Regards, Dmitry.

2017-02-24 12:04 GMT-04:00 William Temperley :

>
>
> On 24 February 2017 at 16:14, Tom Hughes  wrote:
>
>> On 24/02/17 14:43, Blake Girardot HOT/OSM wrote:
>>
>>> On Fri, Feb 24, 2017 at 12:33 PM, Dave F 
>>> wrote:
>>>
>>> On 24/02/2017 11:19, Tom Hughes wrote:

 Well it was a little odd that we suddenly got several people who are not
> regular commenters turning up in the space of a few minute to add "me
> too"
> style responses.
>

 What's wrong with that? There are numerous discussions in Dev that I
 have no
 interest in, but on occasion there's something relevant to my OSM usage
 & I
 will make a comment. This current topic appears to be relevant to a few
 other users.

 OSM Github is not a private club. You should be welcoming other
 contributors, not 'closing' on them.

>>>
>>> I second this 100%!
>>>
>>> If something is of interest to someone and they know other
>>> stakeholders who have similar use cases or the feature is important to
>>> them, getting them to actually contribute their input is really an
>>> invaluable opportunity for developers.
>>>
>>
>> An issue tracker is not a general discussion board though, and there has
>> to be some sort of limit to discussions there if we're not all going to be
>> driven insane.
>>
>> The people that were turning up in this case were not saying adding new
>> information by saying "I use that to do X" where X was something new that
>> nobody had mentioned before that might change the balance of whether it was
>> worth doing but rather they were just asserting that they used the feature
>> like the previous commenters - they were adding quantity to the discussion
>> not quality.
>>
>> I don't normally lock issues, so in the vast majority of cases people are
>> welcome to comment on closed issues if they have some new information to
>> add, and if that leads to a closed issue being reopened then that is fine.
>>
>> I lock issues when people are continuing to post in a way which is not
>> useful and doesn't add anything - restating a position over and over again
>> without adding new information is not meaningful discussion and when that
>> happens I may decide to lock the issue.
>>
>> The alternative (to preserve my sanity) is that I simply unsubscribe from
>> those issues and leave people to waffle on in an echo chamber but I'm not
>> really sure that's better for anybody is it?
>>
>>
>>
>
> I agree with Tom that an issue tracker is not a discussion board.
>
> The way it plays out is that the 0.1% with the (edge) use-case will come
> across the issue, because it affects them and they searched for it.
> Nobody else will know or care about its existence, because it hasn't
> affected them. The result is therefore a very one-sided debate, and the
> developer feels rail-roaded.
>
> I would suggest a new thread on this list (which is a discussion board)
> with a subject something like "Show tile image option removed from OSM
> website".
> This can then be linked to from the offending issue and Tom can get on
> with his good work.
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>
>


-- 
Thank you for your time. Best regards.
Dmitry.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[William Temperley]

On 24 February 2017 at 16:14, Tom Hughes  wrote:

> On 24/02/17 14:43, Blake Girardot HOT/OSM wrote:
>
>> On Fri, Feb 24, 2017 at 12:33 PM, Dave F 
>> wrote:
>>
>> On 24/02/2017 11:19, Tom Hughes wrote:
>>>
>>> Well it was a little odd that we suddenly got several people who are not
 regular commenters turning up in the space of a few minute to add "me
 too"
 style responses.

>>>
>>> What's wrong with that? There are numerous discussions in Dev that I
>>> have no
>>> interest in, but on occasion there's something relevant to my OSM usage
>>> & I
>>> will make a comment. This current topic appears to be relevant to a few
>>> other users.
>>>
>>> OSM Github is not a private club. You should be welcoming other
>>> contributors, not 'closing' on them.
>>>
>>
>> I second this 100%!
>>
>> If something is of interest to someone and they know other
>> stakeholders who have similar use cases or the feature is important to
>> them, getting them to actually contribute their input is really an
>> invaluable opportunity for developers.
>>
>
> An issue tracker is not a general discussion board though, and there has
> to be some sort of limit to discussions there if we're not all going to be
> driven insane.
>
> The people that were turning up in this case were not saying adding new
> information by saying "I use that to do X" where X was something new that
> nobody had mentioned before that might change the balance of whether it was
> worth doing but rather they were just asserting that they used the feature
> like the previous commenters - they were adding quantity to the discussion
> not quality.
>
> I don't normally lock issues, so in the vast majority of cases people are
> welcome to comment on closed issues if they have some new information to
> add, and if that leads to a closed issue being reopened then that is fine.
>
> I lock issues when people are continuing to post in a way which is not
> useful and doesn't add anything - restating a position over and over again
> without adding new information is not meaningful discussion and when that
> happens I may decide to lock the issue.
>
> The alternative (to preserve my sanity) is that I simply unsubscribe from
> those issues and leave people to waffle on in an echo chamber but I'm not
> really sure that's better for anybody is it?
>
>
>

I agree with Tom that an issue tracker is not a discussion board.

The way it plays out is that the 0.1% with the (edge) use-case will come
across the issue, because it affects them and they searched for it.
Nobody else will know or care about its existence, because it hasn't
affected them. The result is therefore a very one-sided debate, and the
developer feels rail-roaded.

I would suggest a new thread on this list (which is a discussion board)
with a subject something like "Show tile image option removed from OSM
website".
This can then be linked to from the offending issue and Tom can get on with
his good work.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Komяpa]

Hi!


> OSM Github is not a private club. You should be welcoming other
> contributors, not 'closing' on them.
>

Here lies a heartbreaking thing:

openstreetmap-website is actually a single person's project.
https://github.com/openstreetmap/openstreetmap-website/graphs/contributors

If you look at it, it's not "community developed this", or "OSMF developed
this", or even "a private club developed this" which you paint as a dark
scenario.

It's being mostly written and deployed by the same person.
This is Bus Factor 1 scenario.

Short term: we need to keep Tom Hughes sane and safe.
Long term: we either close OpenStreetMap as a whole, or make sure there's a
bigger stable development team behind openstreetmap-website.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Tom Hughes]

On 24/02/17 14:43, Blake Girardot HOT/OSM wrote:

On Fri, Feb 24, 2017 at 12:33 PM, Dave F  wrote:


On 24/02/2017 11:19, Tom Hughes wrote:


Well it was a little odd that we suddenly got several people who are not
regular commenters turning up in the space of a few minute to add "me too"
style responses.


What's wrong with that? There are numerous discussions in Dev that I have no
interest in, but on occasion there's something relevant to my OSM usage & I
will make a comment. This current topic appears to be relevant to a few
other users.

OSM Github is not a private club. You should be welcoming other
contributors, not 'closing' on them.


I second this 100%!

If something is of interest to someone and they know other
stakeholders who have similar use cases or the feature is important to
them, getting them to actually contribute their input is really an
invaluable opportunity for developers.


An issue tracker is not a general discussion board though, and there has 
to be some sort of limit to discussions there if we're not all going to 
be driven insane.


The people that were turning up in this case were not saying adding new 
information by saying "I use that to do X" where X was something new 
that nobody had mentioned before that might change the balance of 
whether it was worth doing but rather they were just asserting that they 
used the feature like the previous commenters - they were adding 
quantity to the discussion not quality.


I don't normally lock issues, so in the vast majority of cases people 
are welcome to comment on closed issues if they have some new 
information to add, and if that leads to a closed issue being reopened 
then that is fine.


I lock issues when people are continuing to post in a way which is not 
useful and doesn't add anything - restating a position over and over 
again without adding new information is not meaningful discussion and 
when that happens I may decide to lock the issue.


The alternative (to preserve my sanity) is that I simply unsubscribe 
from those issues and leave people to waffle on in an echo chamber but 
I'm not really sure that's better for anybody is it?


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Blake Girardot HOT/OSM]

On Fri, Feb 24, 2017 at 12:33 PM, Dave F  wrote:
>
> On 24/02/2017 11:19, Tom Hughes wrote:
>>
>>
>> Well it was a little odd that we suddenly got several people who are not
>> regular commenters turning up in the space of a few minute to add "me too"
>> style responses.
>>
>
> What's wrong with that? There are numerous discussions in Dev that I have no
> interest in, but on occasion there's something relevant to my OSM usage & I
> will make a comment. This current topic appears to be relevant to a few
> other users.
>
> OSM Github is not a private club. You should be welcoming other
> contributors, not 'closing' on them.
>
> DaveF

I second this 100%!

If something is of interest to someone and they know other
stakeholders who have similar use cases or the feature is important to
them, getting them to actually contribute their input is really an
invaluable opportunity for developers.

No one person is ever going to be able to imagine how the 1000's of
users of OSM might have needs. This was a great example (maybe) of
someone taking the time to find others who have similar needs and
getting them to share their user stories as well.

I actually doubt that is what happened, but instead that users who
take the time to follow the project just happened to have similar use
cases and joined the conversation. They probably represent many other
users.

I would also say that well added UI for power users, educates and
helps build skills and knowledge in all users.

All that said, the time and dedication people like TomH, Lonvia,
bhousel and the other contributors to the OSM ecosystem contribute is
incredible and we would be in a very different place without them. And
the feedback on this thread is very valuable to helping make the
community better so thank you all for speaking up and sharing your
perspective.

Cheers
Blake
-- 

Blake Girardot
Humanitarian OpenStreetMap Team, TM3 Project Manager
skype: jblakegirardot
HOT Core Team Contact: i...@hotosm.org

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Martin Koppenhoefer]

2017-02-24 13:11 GMT+01:00 Michael Zangl <
openstreet...@michael.fam-zangl.net>:

> This is a not a dev playground, this is a website that
> should be used by millions of normal users. It should provide an entry
> point for people that want to improve the OSM database. It should not be
> a maintenance tool.
>


which page do you suggest should those millions of users use after they
have become contributors and want to see tile urls?

It would be nice to have a custom right click menu, either completely
custom by user pref or for the start generalized in basic groups (like
logged in and not, where not logged in users get more "common map
right-click features", and logged in user get more mapper-interest right
click functionality). Current state could be used as default.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Komяpa]

пт, 24 февр. 2017 г. в 14:44, Tom Hughes :

> On 24/02/17 11:27, Dave F wrote:
>
> > On 24/02/2017 10:26, Jóhannes Birgir Jensson wrote:
> >>
> >> It was closed and rejected in a very abrupt and unconstructive manner.
> >
> > Yes. This seems to be Tom Hughes's default reaction. He's certainly
> > trigger happy with the close button.
>
> Tickets can always be reopened.
>

Unfortunately, discussion can't happen in tickets where discussion was
limited to collaborators:
https://github.com/openstreetmap/operations/issues/122

Discussion can happen outside, but from my experience tickets are being
closed at sight and aren't really being reopened. People just go away and
chat "oh how stupid we can do nothing about it" in chats.

It also doesn't create a friendly atmosphere at all when you get a response
like this minutes after creating a ticket:
https://pp.vk.me/c837224/v837224128/2859d/dX2cSI8qmY4.jpg (and it gets
reopened after IRC discussion and this comment gets magically disappeared).

Also an issue being closed makes it look like it already was addressed and
"there's nothing we can do", while there are still a lot of things that can
be done:
https://github.com/openstreetmap/operations/issues/135 (/map call is
extremely inefficient now, and that's architectural issue).

Closing tickets like this makes it look like there are no issues in the
project. So when Foundation Board has a meeting, how exactly can they get
the idea there's a set of internal issues to handle, and it may be worth at
the point hiring someone to resolve it, instead of hoping for volunteers to
handle the low-level architecture issues in their free time?

If I'm going to say no to something I might as well close it at the same
> time otherwise I have to remember to do so later. If there is a
> subsequent discussion that suggests there is a good reason to do it the
> ticket can and will be reopened.
>
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Michael Zangl]

Hi,

A few words of someone who is just "using" the OSM website:

I personally think the current Menu is full enough. We should focus on
making that menu better for normal visitors. I could not really think of
a use case where a normal user would want to see a specific map tile. In
my opinion, they should not even know that map tiles exist. If you want
to export a part of the map, use the image functionality in the export tab.

I like that the main site has some dev stuff on it and is sort of a
browser for the database. But for many people, it is the first point
where they get in touch with OSM. And they don't know what a attribute
list is, they don't know about relations and for them, most
functionality of the page is not usable (changesets, object queries,
...). Compared to other map pages, the page is really "technical" the
way it is now.

I support the decision to not include that link to the tile source on
the website: This is a not a dev playground, this is a website that
should be used by millions of normal users. It should provide an entry
point for people that want to improve the OSM database. It should not be
a maintenance tool.

Michael

Am 24.02.2017 um 12:41 schrieb Tom Hughes:
> On 24/02/17 11:33, Dave F wrote:
> 
>> On 24/02/2017 11:19, Tom Hughes wrote:
>>
>>> Well it was a little odd that we suddenly got several people who are
>>> not regular commenters turning up in the space of a few minute to add
>>> "me too" style responses.
>>
>> What's wrong with that? There are numerous discussions in Dev that I
>> have no interest in, but on occasion there's something relevant to my
>> OSM usage & I will make a comment. This current topic appears to be
>> relevant to a few other users.
> 
> The problem is that there is a subset of people that think tickets are a
> popularity contest and that if they can just get enough people to vote
> for a ticket it will be accepted/implemented/whatever.
> 
> That's not how it works however, in almost any open source project in
> fact, because things are done because people want to work on them and
> are accepted when they are the right thing, whether they are being asked
> for by one person or a hundred people.
> 
> Even if a hundred people turned up to say they would use this that tells
> us nothing about the other million mappers that have no idea what github
> even is so it's really not helpful to fill everybody's mail boxes up
> with "+1" messages that we're all just going to ignore anyway.
> 
> Tom
> 


___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Tom Hughes]

On 24/02/17 11:27, Dave F wrote:


On 24/02/2017 10:26, Jóhannes Birgir Jensson wrote:


It was closed and rejected in a very abrupt and unconstructive manner.


Yes. This seems to be Tom Hughes's default reaction. He's certainly
trigger happy with the close button.


Tickets can always be reopened.

If I'm going to say no to something I might as well close it at the same 
time otherwise I have to remember to do so later. If there is a 
subsequent discussion that suggests there is a good reason to do it the 
ticket can and will be reopened.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Tom Hughes]

On 24/02/17 11:33, Dave F wrote:


On 24/02/2017 11:19, Tom Hughes wrote:


Well it was a little odd that we suddenly got several people who are
not regular commenters turning up in the space of a few minute to add
"me too" style responses.


What's wrong with that? There are numerous discussions in Dev that I
have no interest in, but on occasion there's something relevant to my
OSM usage & I will make a comment. This current topic appears to be
relevant to a few other users.


The problem is that there is a subset of people that think tickets are a 
popularity contest and that if they can just get enough people to vote 
for a ticket it will be accepted/implemented/whatever.


That's not how it works however, in almost any open source project in 
fact, because things are done because people want to work on them and 
are accepted when they are the right thing, whether they are being asked 
for by one person or a hundred people.


Even if a hundred people turned up to say they would use this that tells 
us nothing about the other million mappers that have no idea what github 
even is so it's really not helpful to fill everybody's mail boxes up 
with "+1" messages that we're all just going to ignore anyway.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Tom Hughes]

On 24/02/17 11:11, Tom Hughes wrote:


Rather what happened is that at some point (most likely in the 1.0.0
release about six months ago) leaflet started marking tile images with a
CSS attribute that stops the browser offering image options for them in
the default context menu.


This is the actual commit to leaflet that caused it:

  https://github.com/Leaflet/Leaflet/commit/0cfe8589

in response to this issue, which unfortunately has no explanation:

  https://github.com/leaflet/leaflet/issues/2396

That then made it's way to OSM when leaflet 1.0.0 was release and we 
switched to it on 27th September last year.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Dave F]

On 24/02/2017 11:19, Tom Hughes wrote:


Well it was a little odd that we suddenly got several people who are 
not regular commenters turning up in the space of a few minute to add 
"me too" style responses.




What's wrong with that? There are numerous discussions in Dev that I 
have no interest in, but on occasion there's something relevant to my 
OSM usage & I will make a comment. This current topic appears to be 
relevant to a few other users.


OSM Github is not a private club. You should be welcoming other 
contributors, not 'closing' on them.


DaveF

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Dave F]

On 24/02/2017 10:26, Jóhannes Birgir Jensson wrote:


It was closed and rejected in a very abrupt and unconstructive manner.


Yes. This seems to be Tom Hughes's default reaction. He's certainly 
trigger happy with the close button.


DaveF


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Tom Hughes]

On 24/02/17 10:26, Jóhannes Birgir Jensson wrote:


As evident in the discussion on issue
https://github.com/openstreetmap/openstreetmap-website/issues/1446 there
are several people interested in maintaining functionality that existed
only a few days ago - being able to view single tiles just as easily as
before.

A patch was submitted which added the tile to the new context menu
(which in itself is a fine addition but eliminated the functionality
being discussed). See
https://github.com/openstreetmap/openstreetmap-website/pull/1450


That is not an accurate description of what happened as I explain in my 
previous message.



It was closed and rejected in a very abrupt and unconstructive manner.


I respectfully disagree that I have been unconstructive. I have made 
clear that there are a number of ways that the requested functionality 
could be made available including in a detailed response I posted this 
morning which you in fact quote from.



The issue itself was also closed with accusation of brigading.


Well it was a little odd that we suddenly got several people who are not 
regular commenters turning up in the space of a few minute to add "me 
too" style responses.



But removing functionality and then denying it to be re-added based on
very little but personal objective is unhelpful and detrimental.


Again that is not what happened. At no point was a decision made to 
remove this functionality. Rather it was removed essentially by accident 
when leaflet was upgraded and only six months later when we added our 
own context menu have people complained about it.



What should have been a great patch with addition of context menu is
turning into an issue because of one very simple change and resistance
to tweaking it.

Denigrating active mappers because they are "the 0.001%" of the user
base is hardly a solid reason - nor is "what makes good UX for the 99%
not what will make the 1% a little happier".


It's not intended to denigrate anybody, it's simply to explain that we 
can't simply add everything that is of use to some small subset of users 
because there is a cost to everything both directly in terms of 
maintenance and indirectly in terms of complicating the UI for all the 
other users that will never use a given option.


More specifically there were a number of people asserting that this 
feature was somehow to all mappers and I was trying to make the point 
that really that wasn't true at all and that the was majority of mappers 
would never have any use for it.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Komяpa]

Hi!

пт, 24 февр. 2017 г. в 13:30, Jóhannes Birgir Jensson :

> As evident in the discussion on issue
> https://github.com/openstreetmap/openstreetmap-website/issues/1446 there
> are several people interested in maintaining functionality that existed
> only a few days ago - being able to view single tiles just as easily as
> before.
>

Can you share your use case?
Why would you need to view single tiles?
What does this solve for you that can not be done by other means?
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Tom Hughes]

On 24/02/17 10:26, Jóhannes Birgir Jensson wrote:


But removing functionality and then denying it to be re-added based on
very little but personal objective is unhelpful and detrimental.


As far as I know no functionality has been removed, at least not 
recently. Rather a request to add functionality has been declined.


I assume you are referring to the fact that at one point it was possible 
to access this via the browser's context menu but the recent addition of 
our own context menu has not changed that in any way and you can still 
access that menu by holding down shift.


Rather what happened is that at some point (most likely in the 1.0.0 
release about six months ago) leaflet started marking tile images with a 
CSS attribute that stops the browser offering image options for them in 
the default context menu.


I would quite likely accept a patch to override that CSS setting and 
restore access to the image options in the browser menu but I still do 
not think we should add such an option to our context menu which is 
inherently targeted at a more average level of user.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Removing functionality and giving just No as answer

[Christoph Hormann]

On Friday 24 February 2017, Jóhannes Birgir Jensson wrote:
> As evident in the discussion on issue
> https://github.com/openstreetmap/openstreetmap-website/issues/1446
> there are several people interested in maintaining functionality that
> existed only a few days ago - being able to view single tiles just as
> easily as before.
>
> [...]

I think the key here is to have more diversity and not insist on every 
functionality that could be desirable to be present on 
openstreetmap.org.  Certainly this would seem convenient but it 
ultimately will never be possible and it would be extremely hard to 
maintain.

I for example really miss a coordinate display for the mouse position 
but there are plenty of other map interfaces that offer this so no big 
deal.

When closing the discussion Tom clearly stated what kind of solution he 
considers acceptable:

https://github.com/openstreetmap/openstreetmap-website/issues/1446#issuecomment-282233549

Everyone is entitled to disagree with that but you'd also have to ask 
yourself why the outlined solution is not acceptable for you.

-- 
Christoph Hormann
http://www.imagico.de/

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

[OSM-dev] Removing functionality and giving just No as answer

[Jóhannes Birgir Jensson]

As evident in the discussion on issue 
https://github.com/openstreetmap/openstreetmap-website/issues/1446 there 
are several people interested in maintaining functionality that existed 
only a few days ago - being able to view single tiles just as easily as 
before.


A patch was submitted which added the tile to the new context menu 
(which in itself is a fine addition but eliminated the functionality 
being discussed). See 
https://github.com/openstreetmap/openstreetmap-website/pull/1450


It was closed and rejected in a very abrupt and unconstructive manner.

The issue itself was also closed with accusation of brigading.

However what was most aberrant there was the assertion "If you want 
something to show tile status then fine. I might even agree to an option 
to get the tile URL or expire a tile (though the latter is perhaps 
unlikely) but it needs to be properly integrated, not just dumping the 
URL in another tab and letting the user fiddle with it."


As the issue is closed to non-collaborators I don't find any other place 
to bring this up than here. Every person who has put their name to the 
discussions, for and against, has done tremendous work for OpenStreetMap 
- that is never in doubt.


But removing functionality and then denying it to be re-added based on 
very little but personal objective is unhelpful and detrimental.


What should have been a great patch with addition of context menu is 
turning into an issue because of one very simple change and resistance 
to tweaking it.


Denigrating active mappers because they are "the 0.001%" of the user 
base is hardly a solid reason - nor is "what makes good UX for the 99% 
not what will make the 1% a little happier".


Did the default map suddenly become a commercial entity overnight which 
thinks of margins and market share? If so I'd like to see the result of 
the A/B testing that validated removing the functionality of viewing 
tiles directly.




--Jói / Stalfur

___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev