<div dir="ltr"><div><div><span class="im"><div>> A test environment with worldwide data.<br><br></div></span><div>Is it feasible that OSMF or somebody else can fund it? Obviously it would <br>be also necessary to maintain it and change development schedule from<br></div><div>"merge round, than deploy map" to something like "merge round, deploy <br>new version on test server, if tested version is OK and nobody found new bugs<br>deploy tested version on production server".<br><br></div><div>(Maybe I am wrong in diagnosing what is the main blocker for it).<br></div><span class="im"><div><br>> But these are just implementation details. The bigger problem is that<br>
> after 2 years of work we're not making much progress on the most<br>> important things.<br><br></div></span>For me fixing big part of label mess (low zoom after this release is much better, <br>landuse label scaling and sorting was a giant improvements) and<br></div>fixing how footways are displayed on lower zoom levels were significant <br></div>improvements.<br><div><div class="gmail_extra"><br>> trunk roads in forests<br><br></div><div class="gmail_extra">In this case it would help to announce at some point that it is a good moment to<br></div><div class="gmail_extra">submit some PRs (current status is <br>"building and landuse colours should be looked at first"[1]). Also, it would be good<br></div><div class="gmail_extra">to know whatever proposals should attempt to resurrect UK map style with blue <br>and green roads - or is it maybe OK to propose a completely different style.<br></div><span class="im"><div class="gmail_extra"><br>> Should<br>
> I be delaying more PRs until I get time to tweak them? Or should I<br>
> stop reviewing the PRs entirely and just merge any of them that don't<br>
> cause syntax errors?<br><br></div></span><div class="gmail_extra">Obviously, both extremes would be bad. I have no idea how much time you spend <br></div><div class="gmail_extra">on reviewing PRs, but current model of PR handling seems good given limited <br></div><div class="gmail_extra">time (what makes impossible to merge/comment on/reject every single one waiting).<br><br>But maybe it would be a food idea to sometimes start from old ones, not new? <br>Because currently PRs that failed to be decided in the first merge session after <br>submitting are waiting a long time <br>- <a href="https://github.com/gravitystorm/openstreetmap-carto/pull/725" target="_blank">https://github.com/gravitystorm/openstreetmap-carto/pull/725</a> is an extreme<br>example of a really unfortunate one (waits since July, it was first attempt to <br>contribute by this person).<br><br>Also, there are some that were not good enough to assign for merge review or <br>bad enough to close. As result for example<br><a href="https://github.com/gravitystorm/openstreetmap-carto/pull/82" target="_blank">https://github.com/gravitystorm/openstreetmap-carto/pull/82</a><br></div><div class="gmail_extra">was submitted in 2013 and is still waiting.<span class="im"><br><br>> So I pose a question that's most pressing on my mind - should the<br>
> other maintainers be merging PRs without me reviewing them first? Will<br>
> this lead to a better result?<br><br></span></div><div class="gmail_extra">I am not sure. Minimum for these new additional method of merging for <br>minor changes may be for example: <br><br>(1) at least two maintainers reviewed PR and see  comment that <br>there are no problems with it. For example:<br>- one maintainer proposes and reviews PR and second reviews and merges it<br>- somebody else proposed a change, first maintainer reviews it, second <br></div><div class="gmail_extra">reviews and merges it.<br></div><div class="gmail_extra"><br>(2) PR waited at least week and nobody posted on github comment in PR <br>thread that there is something wrong with it (week since second maintainer <br></div><div class="gmail_extra">posted that it is OK).<br></div><br>Probably every PR should have also (3) some form of before/after comparison <br>(I am not sure is it OK have "can use Tilemill and git" as prerequisite for <br>commenting).<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">But I am not sure how much time would be really saved (fix text-dy change is<br></div><div class="gmail_extra">probably not time-consuming to review, and anyway it would be necessary yo<br>control what was changed). Also, what is limit of "minor change"? text-dy fix?<br></div><div class="gmail_extra">New icon? New feature? Small tweak for landuse colours?<br><br></div><div class="gmail_extra">Maybe my proposal is overly cautious and formalistic? Maybe it is a bad idea to<br></div><div class="gmail_extra">allow more people to commit as even now there are too often cases of bugs and<br>we should start from test server?<br></div><br>[1] <a href="https://github.com/gravitystorm/openstreetmap-carto/issues/102#issuecomment-61472004" target="_blank">https://github.com/gravitystorm/openstreetmap-carto/issues/102#issuecomment-61472004</a><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">2014-12-11 16:16 GMT+01:00 Andy Allan <span dir="ltr"><<a href="mailto:gravitystorm@gmail.com" target="_blank">gravitystorm@gmail.com</a>></span>:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11 December 2014 at 12:10, Christoph Hormann <<a href="mailto:chris_hormann@gmx.de">chris_hormann@gmx.de</a>> wrote:<br>
> I am somewhat reluctant to bring up this problem since i think the more<br>
> active development is a good thing in total and i don't want to<br>
> badmouth this.<br>
<br>
</span>I'm glad that you bring this up, please don't be reluctant! I know<br>
that the development process for openstreetmap-carto could do with<br>
some improvements.<br>
<br>
First subject: The merging of changes. My normal process it to go to<br>
the list of pull requests assigned to me, and then work down them from<br>
the top down, i.e. dealing with the newest things first.<br>
<br>
<a href="https://github.com/gravitystorm/openstreetmap-carto/pulls/assigned/gravitystorm" target="_blank">https://github.com/gravitystorm/openstreetmap-carto/pulls/assigned/gravitystorm</a><br>
<br>
I first try to merge anything that's complicated, like a refactoring.<br>
Small changes like changing zoom levels of an icon are easier to redo<br>
later on if there are merge conflicts.<br>
Secondly I merge any small 'no brainers' like fixing text-dy. There's<br>
no need for them to wait.<br>
Then I do other things, starting with stuff where I'm happy with the<br>
fix and they can be merged with no conflicts.<br>
Then I start working through any of the above that now needs manual<br>
conflict resolution.<br>
Then I revisit things that I've passed over - things that take more<br>
thought, or where I'm considering rejecting the pull requests or<br>
asking for modifications.<br>
<br>
It seems elaborate perhaps, but it's basically just me trying to get<br>
as many things merged in the limited time that I have available.<br>
<br>
>From that it would be a reasonable conclusion to think that I'm being<br>
a bottleneck on the development - well, perhaps I am. But what is<br>
frustrating me most is that I end up spending all my time working on<br>
pull requests that I simply don't think are the most important tasks,<br>
but there are so many of them (and so many calls for me to hurry up<br>
with the reviews) that I never actually work on anything else. The<br>
time I'm not spending reviewing and merging PRs I'm instead spending<br>
wading through all the comments on issues, which are still running at<br>
over 100 a week.<br>
<br>
But these are just implementation details. The bigger problem is that<br>
after 2 years of work we're not making much progress on the most<br>
important things.<br>
<br>
The style we have now is pretty much the same as it was two years ago.<br>
We've made hundreds of changes and I'm a fan of iterative development,<br>
but I'm not sure that we're iterating in any particular direction. I'd<br>
love to "sort out" the mishmash of colours, but I'm disheartened by<br>
how long it is taking us to sort out just the buildings, and solving<br>
the 'trunk roads in forests' and the hundred other problems like this<br>
seems a long way off. Even when we're changing small things we get<br>
bogged down in endless debates and scrutiny, and unfortunately all the<br>
debating doesn't actually lead to significantly better results.<br>
<br>
I don't like reviewing the pull requests. It's not fun. Almost every<br>
one I merge I think that I'd have done something slightly differently<br>
- an extra zoom here, a different colour there, a changed icon etc.<br>
I've deliberately tried not to bikeshed every single pull request and<br>
so ended up merging a lot of stuff that's not quite to my taste or<br>
changes that aren't entirely cohesive. Am I getting this wrong? Should<br>
I be delaying more PRs until I get time to tweak them? Or should I<br>
stop reviewing the PRs entirely and just merge any of them that don't<br>
cause syntax errors?<br>
<br>
One thing that I'm still sure of is that we need a *team* of<br>
cartographers. There are too many things in the map, and too many<br>
ideas and discussions for the style for it to be run by just one<br>
person. And the work that we're doing now is 10 times more than I<br>
could do without the help of everyone who is working on it. But I<br>
don't know how best to organize ourselves. And I'm still unsure if<br>
it's possible to have a consistent, coherent, nice and yet detailed<br>
map with dozens of people making iterative changes. I hope it is!<br>
<br>
So I pose a question that's most pressing on my mind - should the<br>
other maintainers be merging PRs without me reviewing them first? Will<br>
this lead to a better result?<br>
<br>
If anyone has any advice, I'm all ears.<br>
<br>
Thanks,<br>
Andy<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/dev" target="_blank">https://lists.openstreetmap.org/listinfo/dev</a><br>
</div></div></blockquote></div></div>