[OSM-dev] Fwd: Submitting proposal for GSoC 2017
Hello Sarah, Thank you for the suggestions. http://localhost:8080/nominatim/search.php seems to be working now. Could you please let me know the next steps necessary to prepare for the Postcode project? The password is needed to download or upload files from the Vagrant server using either SSH or an FTP client. I have tried using ‘ubuntu’ and ‘vagrant’ as probable default passwords but get the “permission denied” message. I would appreciate any suggestions. Thank you. Regards, Hriday. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Removing functionality and giving just No as answer
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
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
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
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
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
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
On 24 February 2017 at 16:14, Tom Hugheswrote: > 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
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
On 24/02/17 14:43, Blake Girardot HOT/OSM wrote: On Fri, Feb 24, 2017 at 12:33 PM, Dave Fwrote: 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
On Fri, Feb 24, 2017 at 12:33 PM, Dave Fwrote: > > 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
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
пт, 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
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
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
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
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
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
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
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
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
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
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
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
[OSM-dev-fr] Serveur de tuiles 3D pour le projet Open Earth View.
Salut à tous. Le projet OpenEarthView a besoin d'un serveur de tuiles 3D. Démo du projet: https://www.openearthview.net Actuellement, le client web s'appuie sur des données extraites de requètes sur serveur overpass. Exemple de requète http pour la tuile { z: 18, x: 77197, y: 98526 }: http://overpass-api.de/api/interpreter?data=[out:json];((relation["type"="building"](40.748297354767956,-73.98605346679688,40.749337730454805,-73.98468017578125);>;);(way["building"](40.748297354767956,-73.98605346679688,40.749337730454805,-73.98468017578125);>;););out center; J'obtiens les données OSM qui me permettent de représenter des batiments sommairement en webgl (three.js). Le problème est que le serveur overpass que j'utilise n'est pas adapté pour mon cas d'usage, car il rejette aléatoirement mes trop nombreuses requètes. Quelqu'un serait-il intéressé par le fait de rejoindre le projet, et monter un serveur de tuiles 3D dédié? NB 1: Plusieurs solutions plus ou moins abouties sont possibles (cache, proxy, limitation à une zone géographique, etc...). NB 2: D'après ce que j'ai vu, techniquement, un serveur SoYouStart à moins de 50 euros par mois devrait suffire. Bien à vous tous, Clément. ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr