Re: [OSM-dev] GSoC 2017

[Paul Norman]

On 2/1/2017 10:34 PM, Ronak Jain wrote:
After going through the list of possible idea's for this summer, I 
would like to consider

Full cgimap write support
Full cgimap read-only support
I have chosen these as I have good experience with the languages being 
used in the project also I have worked with Postgres earlier. I will 
choose the idea after speaking with the mentor and deciding what could 
be additionally added to the project.


I would like to know,
how can I get started with the project?


I would start by reading 
http://www.asklater.com/matt/blog/2015/11/18/the-road-to-api-07/. This 
places the GSoC work in the context of the problems and other work needed.


Then, as you've mentioned, map a bit. All the editors interact with the 
API. I would start with iD, the default web-based editor, but then try 
JOSM, which is a java-based desktop editor. It is much easier to 
investigate the API calls with JOSM.


After mapping normally a bit, look over 
https://wiki.openstreetmap.org/wiki/API_v0.6, in particular the Elements 
part (2.4) and Changesets (2.2). Then start JOSM from the command line 
so that there's a java console and map some more, looking at the API 
calls JOSM makes, and how they related to what you're doing.



are there any bite-sized project or bugs that could be fixed?


https://github.com/zerebubuth/openstreetmap-cgimap is the repository for 
cgimap, and it's issue tracker is on GitHub. #90 and #84 seem like easy 
ones where most of the work will be getting familiar with the project.


https://github.com/openstreetmap/openstreetmap-website is the other 
project to be familiar with (It's called "The Rails Port"). It powers 
the website, and for various reasons, all the API calls cgimap does are 
also implemented in it. cgimap-ruby aims to end this duplication.



what are the steps I could take to increase my acceptance rate?


Asking in advance is good, as many students don't ;)

Working on a plan would be good. I recommend giving some consideration to

- Which API calls you will work on
- How you will test the cgimap part
- How you will test that cgimap and the rails port have the same behavior

None of these need to be complete, but having given some thought to what 
to do puts you well ahead of most potential students.


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

Re: [OSM-dev] [OSM-talk] Make Nominatim more dev friendly

[Dave F]

Wouldn't it be better to make it more user friendly?[1]

I'd have thought popular projects where there's a clear benefit & a 
sustainable future would attract more developers.


[1] Does the viewbox option work? With it ticked, it still found a 
street miles away from the city in the window. (Yes, the city does have 
the street)


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

[OSM-dev] GSoC 2017

[Ronak Jain]

Hello,

My name is Ronak Jain, studying final year Computer Science & Engineering
from Visvesvaraya technological university, India. This summer I would like
to GSoC with OpenStreetMap, as I am really keen on working with an
interesting and challenging project which matches my skills and provides a
room for learning.

About my experience:
I have contributed to plenty of open source projects in the past which
include Google/Flatbuffers, Grpc, and other smaller projects. I am the
author of "Grpc-go interface generator with flatbuffers" which is one of my
greatest contribution which I am proud of. I have extensively worked with
C, C++ and Go, comfortable with java, ruby, python, and javascript. I have
worked on projects such as Bittorrent client, Online Judge etc. which are
available in my profile on GitHub. I have also published apps on Google
play store.
References: Play store
 Github


I am aware of the fact that selected GSOC organizations will be released by
the last week of Feb, but I believe in preparing early and would like to
get used to the development environment of OSM by learning the technologies
which could be used in the project and communicate with the potential
mentor to understand the project really well to be able to write a good
proposal.

After going through the list of possible idea's for this summer, I would
like to consider
Full cgimap write support
Full cgimap read-only support
I have chosen these as I have good experience with the languages being used
in the project also I have worked with Postgres earlier. I will choose the
idea after speaking with the mentor and deciding what could be additionally
added to the project.

I would like to know,
how can I get started with the project?
are there any bite-sized project or bugs that could be fixed?
what are the steps I could take to increase my acceptance rate?

I have created an account with OSM and will contribute to the map based on
my local area, also I have read the GSoC students guide. I would like to
know if mentors have any suggestions regarding the project and best
practices.

Thank you,
Ronak Jain
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Odp: Re: Make Nominatim more dev friendly

[Tom Hughes]

On 02/02/17 09:53, Mariusz Rogowski wrote:


By obvious steps I mean:
1. Make current maintainers stop working on existing issues (if they don't have 
time). The biggest issue right now is the project is not attractive to new 
developers. Fix that first. What I mean in details e.g. is:
 - Close pending (for years) pull requests.
 - Prepare nice project readme which mentions contributors are needed and 
welcomed.
 - Prepare documentation of existing code base. Things like architecture, 
languages used, test approach etc.
 - Prepare some contribution guidelines.
 - Prepare some big picture. Project is quite old, I guess technologies and 
architecture chosen might be quite obsolete. Maybe someone should review the 
current approach and decide on some bigger targets than fixing single small 
issues. E.g. sometimes I feel that that putting address data to some search 
engine could get rid of lots of logic in Nominatim code.

Anyway, make the project as attractive as possible for new people. There are 
people who want to contribute to open source projects. You could get 
contributors from Google Summer of Code, Hacktoberfest, Hackathons and Code 
Retreats. But you need to make project look like it's worth ones time.


Firstly nobody can "make current maintainers" do anything - that's not 
how open source software works. People work on the things they're 
interested in and maintainers do their best to make some sense of the 
results and construct a coherent result.


More constructively, if you think those things are important then why 
not work on some of them?


It seems like some of them at least are things that would actually be a 
good way for somebody who wanted to get involved could get started - as 
you explore the code and learn about it you can document what you find 
and submit that as a pull request to add new documentation where things 
are lacking?


Likewise anybody could write a nice README encouraging people to get 
involved and I'm sure the maintainers would be happy to merge it.


Or you could draft some contribution guidelines - those might need to go 
round a few cycles of review to fit with the maintainers preferences but 
much of the work of writing them could be done by somebody else and 
offering something (however minimal) is a constructive way of suggesting 
that some guidelines be added that will likely work better than 
complaining that they are missing.


Tom

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

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

[OSM-dev] Odp: Re: Make Nominatim more dev friendly

[Mariusz Rogowski]

Dnia Czwartek, 2 Lutego 2017 00:14 Frederik Ramm  
napisał(a)

>I'm not a Nominatim developer but I've followed Nominatim development
> and issues for a while. One thing that contributes to the impression
> that "pull requests/issues are ignored" is that Nominatim aims to be a
> good, or at least a functioning, geocoder for the whole planet.
> Contributors (understandably - that's how Open Source works) often
> scratch their own itch, they find a problem with Spanish addresses and
> submit a fix - but they don't notice (or care) that it breaks geocoding
> elsewhere (for example https://trac.openstreetmap.org/ticket/4895 where
> someone adds stop words).
>  

That's why it is important to prepare extensive test suite (also enabling some 
locale parameter for searches would be nice to have). Than just don't allow 
pull requests which don't pass existing tests. Easy ;)

>  
> You said you're a developer, have you actually tried to participate in
> the Nominatim devlopment?

Not yet. Lack of guide, architere descriptions, mentioned pull requests and 
lack of knowledge of some kind of big picture is not encouraging.

>  
> > [4] - https://github.com/twain47/Nominatim/issues/467
>  
> Are you the user "sanitas2" from this issue? I've read through it and I
> must say that I find the reaction of the developers absolutely
> understandable. I don't think you have been helpful, respectful, or
> polite in that issue.
>  

I think both sides could have behave better.

> > Anyway, I think the solutions to the problems are quite obvious. How can I 
> > convince someone to make the project open and friendly to new collaborators?
>  
> I think this public claim that the current developers ignore "obvious
> solutions" won't do much good to improve their enthusiasm. What is your
> suggestion? Chuck out the "unfriendly" developers and replace them with
> whom? Or force the developers to spend more of their spare time trying
> to understand your issue?
>  

By obvious steps I mean:
1. Make current maintainers stop working on existing issues (if they don't have 
time). The biggest issue right now is the project is not attractive to new 
developers. Fix that first. What I mean in details e.g. is: 
 - Close pending (for years) pull requests.
 - Prepare nice project readme which mentions contributors are needed and 
welcomed.
 - Prepare documentation of existing code base. Things like architecture, 
languages used, test approach etc.
 - Prepare some contribution guidelines.
 - Prepare some big picture. Project is quite old, I guess technologies and 
architecture chosen might be quite obsolete. Maybe someone should review the 
current approach and decide on some bigger targets than fixing single small 
issues. E.g. sometimes I feel that that putting address data to some search 
engine could get rid of lots of logic in Nominatim code.

Anyway, make the project as attractive as possible for new people. There are 
people who want to contribute to open source projects. You could get 
contributors from Google Summer of Code, Hacktoberfest, Hackathons and Code 
Retreats. But you need to make project look like it's worth ones time.

2. Ask for help/feedback OSM partners or universities. E.g. mapquest provides 
Nominatim service. Maybe they won't be able to do any coding, but maybe they 
might have some thoughts about direction project should go. As of universities, 
every year hundreds of people are looking for project for master thesis, making 
them know there is interesting topic available may attract them to Nominatim.

3. Announce the project needs contributors on OSM blog/website.

4. Maybe OSM fundations should consider hiring people to work on OSM projects?

Those are ideas from top of my mind. Maybe not the best ones, but still those 
are better things to do than complain about being understaffed ;)




 




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

[OSM-dev] Odp: Re: [OSM-talk] Make Nominatim more dev friendly

[Mariusz Rogowski]

Hi,You kind of proving my point. In my opinion the project should provide all those information on its github pages. I think conclusion that someone cares and actively maintains the project should be visible without asking any questions.As for pull requests, I would say after waiting reasonable time, they should be closed. I don't think you are seriously awaiting for someone to respond to a comment after 5 years. Closing inactive ones after some time would not send message 
that the project is not maintained. Anyway, thanks for giving me some starting points. I'll look into that.
 
Dnia Środa, 1 Lutego 2017 21:53 Sarah Hoffmann  napisał(a)

Hi Mariusz,
 
(cross-posting to talk removed, as this is essentially a dev mail)
 
I'm glad to hear that you are concerned about Nominatim development.
That makes two of us. As a software developer, the most effective
way to change things is to start contributing code. So here are a few
pointers for that.
 
The outstanding pull requests you mention are a very good place to start.
There are quite a few which have not been merged because there are
outstanding comments from me which the original authors never addressed.
In particular, I'd like to point to:
 
https://github.com/twain47/Nominatim/pull/552
https://github.com/twain47/Nominatim/pull/439
https://github.com/twain47/Nominatim/pull/429
 
They are pretty far along. They would need to be updated to the current
master version and have the remaining issues fixed.
 
If that's not to your liking you can also look through the issues.
Anything marked 'enhancement' is particularly suited for external
contributions. I haven't marked the difficulty level but here are
a few examples, I'd consider good starting points for first time
code contributors:
 
https://github.com/twain47/Nominatim/issues/562
https://github.com/twain47/Nominatim/issues/135
https://github.com/twain47/Nominatim/issues/171
https://github.com/twain47/Nominatim/issues/255
https://github.com/twain47/Nominatim/issues/344
https://github.com/twain47/Nominatim/issues/311
 
The comments on the issues can be sparse at times, so feel free to ask
for clarifications. As a general rule, it is also a good idea to quickly
outline your implementation idea first, in particular where the solution
is not obvious or where larger changes are required. That helps avoid
disappointment during PR review.
 
If you have general questions about the source code, the geocoding@
mailing list is the right place to ask.
 
Sarah
(Nominatim lead developer)
 
 
On Wed, Feb 01, 2017 at 07:34:53PM +0100, Mariusz Rogowski wrote:
> blockquote {padding-left: 1ex; margin: 0px 0px 0px 0.8ex; border-left: #cc 1px solid;} p {margin: 0px;padding: 0px;} 
> Hi,I am not sure if this is right pleace to rise my concerns or if they are welcomed here. But I will give it a try.I am not an active member of community, I am software developer who sporadically has to geocode some addresses. For some regions of the world OSM is the best source of data and it is a shame tools for searching the data fall behind. In my opinion Nominatim could have been very useful service which would promote OSM usage. 
Seriously, for many applications
> searching addresses is very important feature. Nominatim should be like second most important service given to the world by OSM. Unfortunately it seems to be far away from the spotlight and people might not be aware of its problems. What I mean is:1. There are pull requests (i.e. probably finished features ready to integrate with project) starting from year 2012. Yes - somebody contributed to the project and is wating 5 years to have his contribution accepted. [1]2. There are over
> 100 issues opened starting from 2013. [2]3. Project is understaffed (which I guess can happen). But its maintainers are aware of it and do not do anything to change it. [3]Anyway, I work in software development and I could be contributing to the project. But fact the contributions are ignored, maintainers are frustrated (and it shows) make me thing it is a waste of time. Even providing real life examples of wrong geocoding (so the test cases could be 
extended) ends with some
> unfriendliness and ignorance. [4] I understand there are probably valid reasons for current state and atitude. But discussing it does not really interests me. I wish to change things ;) Unfortunately there's not much I can do about it apart from pointing the problems to wider audience. Anyway, I think the solutions to the problems are quite obvious. How can I convince someone to make the project 
open and friendly to new collaborators?
> />Mariusz[1] - https://github.com/twain47/Nominatim/pulls[2] - https://github.com/twain47/Nominatim/issues[3] - https://github.com/twain47/Nominatim/issues/316#issuecomment-147111016[4] - https://github.com/twain47/Nominatim/issues/467
>
>
>
 
> ___
> talk mailing list
> t...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk