On 11 December 2014 at 15:16, Andy Allan <[email protected]> wrote: > If anyone has any advice, I'm all ears.
I'm happy Christoph started this discussion. I agree with most things that have already been said. I think the main problem is that the time from design to deployment of changes is currently too long, especially for changes that correct bugs introduced earlier. Andy mentions that he thinks that the pull requests he has merged are not the most important ones. Of course, everyone considers different things important. Some of the things we did I think were quite important, such as shop rendering, mid-zoom path rendering, and the landcover labels. But I think the main result so far is that the code is much more consistent (although not perhaps not always easier to understand), in particular related to roads and labels. Also, the issues Andy referred to as important are mainly graphical design issues, which I'm not very good at. It might be an idea to attract some people who are good at design. Furthermore, we cannot expect large changes from new developers, so I think it is entirely reasonable for new developers to make pull requests that seem trivial and might not be the most important. Still I think merging them quickly is important - new developers now often wait months before their trivial changes get merged, which likely discourages them from contributing more. I think it's important to have someone to guide development effort, and keeps the larger picture in mind. I don't think Andy has even indicated before which issues are the most important to him. I think it'd be more useful for Andy to give high-level comments, and take parts in discussions like this one, than to worry about individual colors or zoom levels or syntax errors in pull requests. Perhaps he also could document some of his vision in the CONTRIBUTING.md file I do think it's good that commits are being reviewed. We quite often catch issues in pull requests, so allowing everyone to commit might not be the best idea. Also, we have people with different areas of expertise: cartography, software development, database design, etc. So the discussions are in my opinion usually a good thing - not only do they improve the map, but I also have learned a lot from them. My suggestion would be to allow collaborators to merge PRs of others (but not their own). Perhaps we could also require a week for feedback before they are being merged. Many PRs have received useful feedback. I also don't mind extending the list of 'collaboratos' (currently Paul Norman, Mateusz, Andy and me) if others are interested. Perhaps we could try this policy for two months, and then evaluate whether we need a stricter or even more lenient policy? Of course, Andy can still do a quick high-level review when deploying a new version. I don't think deploying automatically, as in the Osmarender case, is a good idea. Deploying quickly is in my opinion not as important as merging quickly. Deploying once per month, or even less frequently provided we have a worldwide testing server, would be fine with me. If we let more people commit, we can also consider creating an acceptance branch, or use one-week feature stops (like JOSM does) before deploying, so that we don't introduce too much bugs into the main website. Finally, I also agree that we do need a testing server with worldwide data. Testing worldwide is impossible on a consumer grade pc, so we cannot expect contributors to arrange this themselves. Especially for the low zoom levels, being able to test worldwide is important. I'm not sure who we should contact to discuss this? Kind regards, Matthijs _______________________________________________ dev mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev
