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

Tom Hughes tom at compton.nu
Thu Feb 2 10:28:18 UTC 2017

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 Hughes (tom at compton.nu)

More information about the dev mailing list