2018/2019

[Tomasz-W]

It's time to make some summary of the past year in this repository.

Guys... we did a really good job this year :)

Let's look at a few stats:
At the beginning of 2018 there were ~390 open issues and now we have ~350 of them. Semblance suggests that we fixed only 40 issues, but it's of course not true.

In 2018:

• 354 issues were opened - 116 of them are still open and 238 were closed (67%)
• 390 issues were closed (fun fact: if there would be no coders, there would be ~780 open issues at the moment)
• 259 PRs were opened - 27 of them are still open and 232 were merged or closed (90%)
• 257 PRs were merged or closed

That's the numbers, but the biggest achievement of this year here for me is rather that we have 3-5 active coders + some 'from time to time' coders at the moment. It made work a lot faster than in previous years.

The most important things for me in 2019 are:

• extend landcover rendering to z0 (Showing natural areas on z5+ #3458)
• change borders colour to more greyish ([WIP] Borders and country name rework #3553)
• coordinate different railway types rendering (Unify railway rendering #2872)
• clean up z8-10 (Make railways lighter, minor highways less prominent at z8-10 #3538)
• add outlines for 'cultural-like' areas (Outline coordination (meta issue) #3045)
• add special rendering for underground/ roof buildings (Render underground buildings different #552 and Render building=roof differently to expose underlying features #2475)
• consider making roads more bright

I also have some suggestions to make our work easier and more productive: (if you see yourself in some of these remarks, please don't feel offended, they are just my goodwill suggestions ;) )

• please follow discussions and provided test renderings, and if you don't like effect of proposed change
  comment about it then, otherwise we have to do some things second time after merging
• please be carefull with proposing alternative icons, colours, etc. in already opened issues/ PRs - too much of propositions can really mess up discussion
• please don't upload too many test renderings - it often causes long page loading and problems with discussion reading

I'm very interested in your opinions and suggestions about past year here, so feel free to comment and share your thoughts.

PS. I'll close this topic after a week from today as it's more forum-like one.

[Adamant36]

I agree with the last point. Its something I need to work on myself. Its hard to tell how many test renderings are to much, but to many definitely make issues load slower and harder to read through. So I'll work on that.

One suggestion for people is to be more clear about the specific zoom levels they want things tested at. I think I over did it on a few issues just because I wasn't sure which zoom levels were best to test. Its hard to know what exactly to test if your not the person who wants the tests being done. So more details are always better. It also helps cut down on testing redundancy.

Also, another suggestion would be to test a request someone makes in one message. Then wait a while for them to look at it before doing your own tests and make sure your own tests are in a new message. That way the person wont have to sift through your un-requested tests to get to theirs or get confused as to which is which. Plus, they won't have to address both in a response. Which just makes it easier all around.

In my opinion, as a coder a clear distinction between "this is something I'm doing because I want it" versus "this is something I'm doing because the community (or another individual) requests it" is a good thing. It helps people follow along better and doesn't put me as the coder above none coders or the average lay person (which can lead to problems otherwise) as much. At least that's how I see it.

(Also, good post. Its nice to know we have been pretty productive the last year. Even if it doesn't seem like it by the amount of still open issues. Its amazing how deceiving that can be.)

[kocio-pl]

I'm also the most happy with an active team (:heart:) and the most worried about weak governing model :disappointed: (which is actually discussed, fortunately... :relieved:).

We have no direct competitor for comparison, but looking at last month we had 29 commits to master while at the same time iD had 131, JOSM had 152 - to mirror in this case - and HOT style has no commits since March 2018. So it's just for illustrative purposes.

[kocio-pl]

390 issues were closed (fun fact: if there would be no coders, there would be ~780 open issues at the moment)

I think it does not work this way. I think that people look how active the project is before open the ticket to not waste their time (at least this is what I always check when reporting anything), so if there would be no coders, there would be much less of them reported.

[jragusa]

Be careful with counting of PR, the count does not consider the quality of the PRs. It's like scientific publications, you can make a great amount of short papers or write a single and very long and detailed review. The results will be the same but with different amount of publications.

[Adamant36]

@jragusa, good call. Its kind of like the difference between being productive versus just busy. I'll still take the PR count as an indicator that we got a lot of good things done though. Even if some of it was just busy work. :)

[Tomasz-W]

I've just provided "clear" numbers without making some bigger philosophy around them, and I'm lefting theirs interpretation for every each one of you by yourself. But I personally agree with both @kocio-pl and @jragusa thoughts.

[kocio-pl]

Right, still counting quality is much harder and very subjective task, so this is usually better to describe than count.

And another reason why there would be less tickets if there were no coders: any new behavior sometimes leads to new problems.

[kocio-pl]

Another positive change in the last year is that OSM Carto tickets are no longer considered to be taboo on Tagging list. Now it works as a feedback for tagging scheme to be reviewed in many cases.

[kocio-pl]

@Tomasz-W What do you think about setting and maintaining project wiki for such things, would it be useful for you?

[Tomasz-W]

@kocio-pl I'm not sure if I understood you properly. Can you describe more what do you mean?

[kocio-pl]

GitHub offers wiki module for projects, I wonder if that would be useful for you instead of abusing tickets for tracking things.

[Tomasz-W]

Can you provide some links to repositiories with actual ones? I would like to see how it works to rate this function.

[kocio-pl]

https://github.com/openstreetmap/iD/wiki
https://github.com/mapnik/mapnik/wiki

[Adamant36]

I like the idea of a Wiki. There needs to be more information on how to set stuff up and what common errors a person can run into. Along with a bunch of other little valuable tidbits of information in various places that it would help to collect in one place.

@kocio-pl, would only admins be able to edit it or can normal contributors be allowed to add stuff to it also (It looks like Mapnik lets anyone edit theirs)? Because id be willing to write some stuff for it if I can. I could always email things to @Tomasz-W for review first if need be. Since he'd be maintaining it.

[kocio-pl]

I have checked that it's possible to allow everyone from the GitHub to edit it, which would be sufficient:

https://help.github.com/articles/changing-access-permissions-for-wikis/

[Tomasz-W]

I'm ready to manage certain sections to make whole thing readable and simple, but I need text provided by somebody else as I don't have any knowledge about docker etc.

[Adamant36]

@Tomasz-W if you want to start the wiki with basic stuff you do know, like the rules for icons etc that would be good. Then we can go from there. It seems like the way Mapnik has theirs setup would be a good basic frame work to go off of.

You could also include a section with the information from your first post about how the project did last year.

[kocio-pl]

It would be up to you what will be included there. Why you mentioned Docker, what did you wanted to do with it on the wiki?

[Tomasz-W]

@kocio-pl OK, open Wiki module then, I'll add some etiquette and icon designing instructions for a start. If somebody would like to add more sections, we'll add them later.

With docker I meant that I don't have tech knowledge at that level so I'm not able to write tech instructions/ remarks for things related to docker, code writing, PRs etc.