Openstreetmap-carto: Tone and Communication discussion

[talllguy]

I'm a little miffed by the closing of an issue (#2205) that I spent some time writing. This is a community project, is it not? While I agree with the reasoning behind the suggested tagging, the response felt cold and terse.

Had I been a first time contributor, I don't think I would come back to this repo.

How about something like:

The issue you've identified is regarding a tagging issue and not something wrong with the renderer. As such, I'm closing this issue. Here is some information and a note on how to fix the tagging.

[matthijsmelissen]

I agree we should try to pay attention to the tone we use, in particular towards new contributors. However, as there's nothing concrete we can do about this right now, I'm going to close this issue.

[polarbearing]

@talllguy - please consider the collaborators are volunteering their time here. This is a developer site populated with geeks, not the PR department where each word has to be weighed for legal consequences or consumer binding effects.
Also, the comments are forwarded to all subscribed contributors, and I'm getting plenty of them from different projects in my daily email stream. I need to decide within 500 milliseconds if I want to read on or skip a message, thus I am quite happy when they are brief and concise.

[SomeoneElseOSM]

I guess that one thing that might be possible would be to refer contributors to somewhere else where they may be able to get help. That might be (in this case) the tagging list, or the help site, or a forum.

The problem actually works both ways though - many of the new issues created here are of the form "please render my favourite feature" (sometimes without even the "please"). There are lots of technical and historical reasons why things are as they are; many decisions are trade-offs and "the best map everywhere" is always going to be a compromise. It's therefore understandable why some "obvious" questions get relatively terse answers. We still all have a responsibility though to recognise that all OSM contributors are both volunteers and human beings (even the newbies adding duplicate POIs in city centres!) - no-one is "special" and no-one should get a licence to be rude.

• Andy
  (not a contributor to this map style though I have commented on issues here, and I do see exactly this sort of problem on lists and on the help site, and also with a Data Working Group hat on).

[jojo4u]

I'd rather have one more of the 361 open issues worked on than working on more polite wording. This is regarded as developer environment. On the other hand the input from new contributors is important and they should not feel alienated.

[gravitystorm]

I'd rather have one more of the 361 open issues worked on than working on more polite wording.

No, this is the wrong way to look at it. If we're terse with new contributors, then there are fewer of them in future. What we aim for is to be polite and welcoming, that way there are more people working on the 361 open issues in future.

@talllguy I'm sorry that you didn't get the style of response that you were looking for. Thank you for raising the matter when you could have just disappeared off without mentioning it to us. You're right that we could explain things more clearly (and we need to remember that not everyone reads the other 1000 issues that we've dealt with so far).

However, I think the "collaborators are not polite" is a bit strong. We aren't rude, but we can do better.

However, as there's nothing concrete we can do about this right now

I'm reopening this because I think there _are_ concrete things we can do. For example, we can make a list of copy+paste responses along the lines of "please discuss on the tagging list not here" etc. Or we can make some documentation within the repo to explain where different things should get filed, so that we can point people towards that in issues.

Like I said above, it's critical for the long-term success of this project that we are friendly and welcoming (yet of course, firm too) when dealing with everyone who takes the time to report things here.

[imagico]

Another suggestion: When closing an issue right away and not referring it to another one (i.e. duplicates) it is a nice gesture to not close it immediately but give the reporter the opportunity to react (and possibly close the issue him/herself if there is agreement). Even if a reply is also possible after closing it is nicer if the door is left open for some time (a day or two).

[matkoniecz]

@talllguy Sorry for not explaining it better. It is good that you shared feedback - without that I would be completely unaware that somebody may dislike such reply. Thanks to that in future I will do more to make clear what are reasons for my actions.

For example, we can make a list of copy+paste responses along the lines of "please discuss on the tagging list not here" etc

Github has saved responses feature that would be useful here - https://github.com/blog/2135-saved-replies https://help.github.com/articles/working-with-saved-replies/

With that it may end not taking more time to reply and provide more info - that may be useful for people unaware about that their issue fits into one of typical classes.

Like I said above, it's critical for the long-term success of this project that we are friendly and welcoming (yet of course, firm too) when dealing with everyone who takes the time to report things here.

Yes, there is no good reason to scare people.

What are some typical issues resulting in fast closing? "OSM data is broken here - https://en.wikipedia.org/wiki/Garbage_in,_garbage_out", "please render also this tag". There is also "please do something that requires hstore". Is there anything else that commonly appears?

[talllguy]

@matkoniecz thank you for the apology. I mean that sincerely. Looking back at my words, especially in the titling of this issue, I was unnecessarily harsh as @gravitystorm pointed out. For that I apologize to you and the rest of the community.

Further, as a dedicated mapper, I'm very appreciative of all the hard work you and the rest of the collaborator team do, here, for this project. I enjoy contributing suggestions and analysis from time to time in my free time. It is also interesting to watch how the repository shapes the main map style.

Finally, and generally, I do value customer service and communication; it is something that can always be improved. If we want to think of some boilerplate type responses as a group, I'd be happy to help.

[matthijsmelissen]

We could have given some more explanation when closing #2275.

[pnorman]

We could have given some more explanation when closing #2275.

I saw https://github.com/gravitystorm/openstreetmap-carto/issues/2275#issuecomment-238483057 https://github.com/gravitystorm/openstreetmap-carto/issues/2275#issuecomment-238494808 and https://github.com/gravitystorm/openstreetmap-carto/issues/2275#issuecomment-238740395 documenting the reason why. Do you think the closing was not well tied to the explanations already given in the issue, or it needed additional text?

I had actually intended to close with my comment but hit the wrong button.

[matthijsmelissen]

Perhaps @clhenrick didn't make the connection between 'this is a data problem' and 'we will close this issue'? For him, the issue hasn't been resolved at all. To be honest, the thread got quite long and I didn't read all text after the closure of the issue.

[clhenrick]

@math1985 it's partially my fault for not fully understanding that OSM Carto's design purpose is to provide OSM contributors feed back on their edits and data editing work that needs to be done. My general mindset with cartographic design is wrangling data to make the design look good, so the design thought for this code base is a completely different approach for me, which is why I was confused / thrown off. Thanks.

[matthijsmelissen]

Thanks for the feedback!

[kocio-pl]

It's worth noting, that we have now CODE_OF_CONDUCT.md.

[pnorman]

Closing. We have a code of conduct and have had some productive discussions about the issue. This isn't a bug in the traditional sense, so it's never really "solved", but discussion has petered out here and I think we've made a reasonable improvement.

If there are individual actions (e.g. documentation-related improvements) that can be done, they should get their own actions.