Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2018/2019 #3618

Closed
Tomasz-W opened this issue Jan 1, 2019 · 19 comments
Closed

2018/2019 #3618

Tomasz-W opened this issue Jan 1, 2019 · 19 comments
Labels

Comments

@Tomasz-W
Copy link

Tomasz-W commented Jan 1, 2019

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:

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
Copy link
Contributor

Adamant36 commented Jan 2, 2019

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
Copy link
Collaborator

kocio-pl commented Jan 2, 2019

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
Copy link
Collaborator

kocio-pl commented Jan 4, 2019

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
Copy link
Contributor

jragusa commented Jan 4, 2019

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
Copy link
Contributor

@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
Copy link
Author

Tomasz-W commented Jan 4, 2019

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
Copy link
Collaborator

kocio-pl commented Jan 4, 2019

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
Copy link
Collaborator

kocio-pl commented Jan 5, 2019

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
Copy link
Collaborator

kocio-pl commented Jan 7, 2019

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

@Tomasz-W
Copy link
Author

Tomasz-W commented Jan 7, 2019

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

@kocio-pl
Copy link
Collaborator

kocio-pl commented Jan 7, 2019

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

@Tomasz-W
Copy link
Author

Tomasz-W commented Jan 7, 2019

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

@kocio-pl
Copy link
Collaborator

kocio-pl commented Jan 7, 2019

@Adamant36
Copy link
Contributor

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
Copy link
Collaborator

kocio-pl commented Jan 8, 2019

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 Tomasz-W closed this as completed Jan 8, 2019
@Tomasz-W
Copy link
Author

Tomasz-W commented Jan 8, 2019

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
Copy link
Contributor

Adamant36 commented Jan 8, 2019

@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
Copy link
Collaborator

kocio-pl commented Jan 8, 2019

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
Copy link
Author

Tomasz-W commented Jan 8, 2019

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants