Feature removal policy

[imagico]

When adding new features in this style our obvious and natural policy is that someone being willing to develop a concrete PR for adding the feature is prerequisite for it actually being added. When removing features however the actual code change to remove them is usually fairly simple and the hurdle that in most cases prevents the removal is opposition to the change.

This opposition sometimes is fairly non-productive because no concrete suggestions are made how to resolve the issues that suggest the removal of said feature but instead just call for keeping the status quo without resolving the issues or call non-specifically for resolving the problems without removing the feature. #3714/#3969 is a good example for that.

My idea to address this problem and to allow us better to manage the complexity in this style and to keep both code and design manageable is to move to a policy that opposition to feature removal PRs should be accompanied by commitment to develop the feature in question in a way that achieves consensus within the project.

This in my eyes could help us developing and maintaining consensus on design questions and it would also encourage developers to adopt certain features and take up the responsibility to maintain them, fix problems and to keep their rendering compatible with the rest of the style and the goals of the project.

Note my idea is not for this rule to supersede the consensus principle but for us (the maintainers) to agree that we will not oppose a feature removal PRs against a majority of the other maintainers if neither we nor anyone else is willing to address the problems because of which the feature removal is suggested by other means.

Related to #3951.

[kocio-pl]

Removing features is already far easier than adding them or updating. I see no reason to further increase this (unfortunately, quite natural) huge lack of balance. IMO each change deserves the same amount of scrutiny, so the opposite direction is needed (to make the amount of work more similar), not the shortcuts for one special category of changes. However thanks for the clear description of what you see as the problem in one place.

Consensus rules as discussed in #3951 have their own load of problems and we are rather on the beginning of the road, as more fundamental things are not even addressed, so at this moment this proposition goes too far in this respect.

[imagico]

Removing features is already far easier than adding them or updating.

The opposite is the case - and it has been this way throughout the history of this style. See for example #1630 (comment).

Feature removals are extremely rare - usually only something like three or four per year and that are often just removal of deprecated synonyms. This year we had AFAIK so far only #3718, #3931 and #3829. Removals of features because of cartographic prioritization or for quality issues with the chosen rendering are almost non-existent.

[kocio-pl]

I think you are just referring to a different aspect of it - I have written about technical problem and you talk about the current practice. While the first is not going to change in itself, the second one can change at any time.

But since the technical problem with adding/changing rendering is in a substantial part made hard by not technical things, but discussing them (there are many cases when the code was made quite fast), I find it fair to keep the same amount of discussing removing things.

There are also other possibilities to keep the balance between the needed work. For example we can make it easier to do any changes (which would probably help more new people to engage in development - see #2291 (comment) ). On the other hand that would change the current development model in a big way - from an old school detailed reviews of everything to an agile practice of making stream of changes. The consequences are hard to be evaluated by me now, but this is the first thing that comes to my mind, having some experience with this new model. Yet there can be many other ideas.

[jeisenbe]

we can make it easier to do any changes

That would be better discussed at #3951 since that issue is mainly about decision-making rather than the technical process of reviewing changes.

The main way we could make it easier to make changes would be to agree on what constitutes reasons to block a proposed change. This is the heart of the discussion at #3951.

We could also abandon some of the current cartographical rules, or abandon consensus-based decision making. But I am not in favor of either of those ideas, since I can't see what would replace them.

[jeisenbe]

Feature removals are extremely rare - usually only something like three or four per year and that are often just removal of deprecated synonyms.

That's right, and in my experience (and also based on reviewing previous issues and PRs), any attempt to change the current rendering has been much harder than adding a new feature in the past 2 years, but removing rendering is the hardest. See for example when we removed railway=abandoned.

The problem is, every rendered tag in Openstreetmap has a constituency, even features that are only interesting to historical railway buffs, like abandoned and dismantled railways. So most people come to this project because they want to see their favorite feature rendered, and if a feature is removed people are very likely to complain.

But the silent majority of users, who benefit from having a clear, legible map and the majority of mappers who benefit from consistent feedback are not going to complain when we add features one at a time or when a few things get rendered in a confusing way. Occasionally an issue reaches here, but it's easy for the maintainers and active contributors to ignore an issue which they are not excited about fixing.

So the basic nature of this style is conservative (in the original sense), and the community appears to be reactionary when it comes to any attempts to remove features.

A similar thing happens in Public Transit: everyone is happy to have a bus stop added near their house, but each stop slows down the average speeds of buses and makes them less useful. When bus operators in the USA (where standard spacing between stops is often less than 200 meters, or every long block!) attempt to reduce the number of bus stops to improve reliability and frequency and bus speeds, the small number of people who are directly affected always complain, loudly. But the large majority of bus riders who would see a small but significant improvement in their freedom to travel are not likely to take time off work to comment at a public meeting, so their voices are not heard.

[kocio-pl]

the community appears to be reactionary when it comes to any attempts to remove features.

What's your idea on why that's happening? I think any solution depends on answering this question.

[jeisenbe]

move to a policy that opposition to feature removal PRs should be accompanied by commitment to develop the feature in question in a way that achieves consensus within the project.

This is an interesting idea.

Alternatively, I think we could look at it this way: the burden of proof should be on supporters of rendering a feature, whether it is not currently rendered or if it is currently rendered.

New features and old features should be treated fairly. When adding a feature it needs to be shown that the new rendered is clear, legible, good for mapper feedback and generally meets our cartographic goals.

So, if someone proposes to remove a certain feature due to a particular problem with the rendering which cannot be easily fixed, the burden of proof should be on the feature remaining.

Perhaps this description is too much based on the Anglo-American legal system. An alternative way of thinking about it, based more on Continental jurisprudence rather than Common Law, is that all features should be treated equally: precedent and the history of development of this style should not be considered binding.

The majority of features currently rendered by this style are widely-used, well-defined, important features. They do not need any specially treatment to remain supported by this style. I think only a tiny minority of currently rendered features need to be reconsidered, but I do not see any benefit to "grandfathering in" such features just because they were rendered at one point.

Considering that we at one point rendered a large number of values for "barrier" and "amenity" and some other tags with a "catch-all" rendering, but then purposefully chose to stop doing that, for better map legibility and mapper feedback, I think it is consistent with our goals and our past choices to be willing to remove features.

[jeisenbe]

What's your idea on why that's happening?

Like every bus stop, every little feature has some people who really like seeing it on Openstreetmap.org - power infrastructure mappers want us to render insulators and transformers and power portals, public transit nerds would like to see even more different types of railway distinguished (including the previously mentioned abandoned and disused ones), some database users want addresses rendered more prominently since they think they need to be added, others want to see POI icons and names instead.

Because of these competing special interests, it's easy to add a new feature: there is always someone to give a thumbs up for it, and removing a feature will always find someone to complain, unless it is completely deprecated - and even deprecated features often have a constituency: see #3305 (comment) (opposition to removing rendering of power=sub_station)

As maintainers of this style, we should work together to make sure that the voices of silent or less vocal users are still heard: that means thinking about how changes will affect people who don't speak English or don't know how to use github, as well as trying to represent the majority who will benefit from a change which is opposed by a small but energized group. See #542 for example.

[jeisenbe]

@kocio-pl - any comments in response to #3977 (comment) and #3977 (comment)?

[jeisenbe]

It's not clear if there is a lack of consensus on this issue or not. Comments by other contributors would be helpful to clarify the situation.

Is there agreement that "opposition to feature removal PRs should be accompanied by commitment to develop the feature in question in a way that achieves consensus within the project"?

[Adamant36]

Is there agreement that "opposition to feature removal PRs should be accompanied by commitment to develop the feature in question in a way that achieves consensus within the project"?

Wouldn't it really depend on the situation and the person opposing the feature removal, along with their ability to develop the feature? For instance, I know @kocio-pl doesn't have a dev environment right now. It should still be OK for him to oppose a feature being removed. His opposition alone just shouldn't be the deciding factor. I think the removal of barrier=kerb rendering is the best example of what should be done IMO. It didn't really hinge on him or his ability to develop an alternative to removal of the feature, but his concerns where still considered and factored into the final decision.

[kocio-pl]

The more I think about this proposition, the more problems reveal.

The argument about shortcuts for removing has been undermined by the last release of this style. Removing is not only much easier (which is obvious), but also already more popular than adding features. That's exactly what I have warned against. If the logic behind this is still supported ("something is hard to do, so it should be easier"), removing should be now made harder than adding. But I think this reasoning is flawed from the beginning, because we should change it every time something gets more popular.

What is important instead, is that removal means going clearly against the data richness and diversity, which is the direction the OSM is going (it's also mentioned as guidelines for this style).

Another problem with removal is that it's the most radical tool we can use. One can discuss size, color or zoom level, but in practice removal is treated as an all-or-nothing solution. As such, that is a bypass for a process of looking for a common ground, because there is no common ground between rendering a feature and not rendering it.

There's also related (but maybe even more important) problem - if we want to give voice to less heard parts of community, we should literally gave them the voice instead of guessing. This is a general problem to be resolved at the community level, not a map rendering issue. When somebody speaks, it is somebody who is active and we should promote this to make community stronger and more active. Another thing is that when we start guessing and ignoring what is being said, we start relying on subjective feelings rather than reality, which is bad, because we loose the touch with community. It's also good to notice that development team of OSM Carto is exactly a vocal minority, but with power on critical community resource, which is another serious issue.

I understand why removal could be seen as a good thing for making things clear. But this is just another shortcut - OSM already has multiple quality assurance tools, including the ones included in data editors. The difference is that as a QA tool we work in a strict mode. There are no hints nor leaving the decision for the user, just the lack of a feature - period. If we really want such behavior, it's the work that should be done at the level of real QA tools, not here.

That is not to say that removal should be not possible or evil in any way. It's just a tool and there are cases where it makes sense. For example removing rendering of shop=yes means promoting more precise tagging, which is good in the end. But that requires that alternatives should exist and be used before that. Also removing duplicate tag is possible at some moment, but that means the community should be not pushed into doing fast changes - mass automated edits should not be promoted. We can also set clear criteria when the period of migration should be over (for example if the feature count drops below 2-5k limit, as we usually do for adding new features).

The discussion on the Tagging list about dropping barrier=hedge + area=yes shows important problems which are triggered by removals. The community has been not consulted before that. It is not a rendering problem and it's easily observable feature. No alternative has been proposed before (it might emerge eventually, but currently it seems like stuck). Community gets the general message that the team that is meant to serve it, does not want to do it, because it has its own visions and that it's community responsibility to fix the problem, even if the tag documentation sticks to what mappers believe is OK. Another impression is that it had to be done exactly now (without giving a reason) and even temporal revert is not considered as a solution. There might be even more to this, but I wanted just to highlight the real problems with easy removals, not to focus on this specific case.

Overall, there can be some guidelines or good practices policy for features removal, but it should consider that it's a kind of ultimate tool, so it should be handled with care, not further amplified to displace other tools and community solutions.

[imagico]

Removing is not only much easier (which is obvious), but also already more popular than adding features.

No, we have discussed this already above in #3977 (comment) in #1630. The opposite is the case as evidenced by the history of this style. Stubbornly claiming things to be the other way round just because reality is inconvenient will not lead anywhere.

Another problem with removal is that it's the most radical tool we can use.

That is correct - and it is the main reason why being able to do feature removals is important. As explained we are pretty far away with this style currently from a consensus position among the maintainers so it requires radical changes to move us to consensus again. That evidently includes feature removals.

And #3844 was not a feature removal - all features that were previously rendered are also still rendered after this change. They are just rendered differently. So most of your arguments are pretty moot.

As for the idea of making map design a popularity contests - that is not going to be compatible to the current goals of this style and to the very idea of OSM to create a generic geo-database and not a specific purpose rendering database targeted at the fairly primitive type of maps style we produce here that is developed in a closed loop with the mapping community. This is what i termed the dilemma of community mapping a long time ago. It is our function to support mappers - but not by doing what the loudest of the mappers push us to do but by observing what mappers actually do and applying reason to make styling decisions in support of consistent and sustainable mapping practice in line with the overall goals of OpenStreetMap.

But i understand this consideration is fairly abstract and osmarender as a practical demonstration is too far back in history to be still present in the collective memory of the OSM community so the best way would probably be if there was a project trying to develop a radically populist map style and demonstrating to everyone how quickly that would fail to fulfill the functions of this style in a sustainable way.

[martijn-heil]

And #3844 was not a feature removal - all features that were previously rendered are also still rendered after this change. They are just rendered differently. So most of your arguments are pretty moot.

I'd argue that it is a removal, removing the very possibility of getting a hedge mapped as a polygon rendered. This is now impossible, while it wasn't before.

[imagico]

The categorization of changes i use is explained on #1630 (comment) and #1630 (comment) - the policy suggestion of this issue applies to category r1.

[kocio-pl]

Just a basic check - do you agree that this is effectively removal of some rendering?

[imagico]

I think i have already answered this question. For clarity again:

• category r1: Features (nodes, ways, relations in OSM) that were previously rendered (i.e. their presence in the OSM database had a visible effect on the rendering results) are not rendered any more after the change.
• category r2: Features that were previously rendered differently based on their tagging/geometry are rendered identically after the change.
• category rz: Features that were previously rendered or differentiated at a certain zoom level are after the change not rendered or not differentiated in rendering at that zoom level any more.

This issue is about rules w.r.t. changes of category r1.

Please don't turn this into a discussion of a specific change. This is an issue about policy and consensus building. If you want to form an opinion on policy based on the question if it supports or hinders specific changes you personally like or dislike that is your choice. However what is suggested here would have had no bearing on #3844 (which is a category r2 change).

[jeisenbe]

@kocio-pl I would be much happier about approving the addition of new features (e.g. #4512 (comment)) if we could have a consensus that we will remove features if 2 or more maintainers agree that the previously added feature is not longer working.

Based on what happened in #3855 / #3957 and #3969, most of us seem to agree that if all maintainers but 1 are in favor of removing a feature or rendering addition, we can consider that rough consensus. But that only happened after a very long discussion in those PRs

I would like us to agree as a team of maintainers that we will not try to block the removal of features on our own if there is majority support for the remova, especially if the previous change was not the result of full consensus at the time it was added.

If we make a smaller barrier to fixing past mistakes, it will make us all less reluctant to take risks with merging new PRs.

[jeisenbe]

An important open issue is about bays and straits - started in #3634 - recently mentioned in #4546 and previously in #3750

We could roll back parts of #3438 and #3144 which were merged with little discussion and now have been shown to have unintended consequences.

[kocio-pl]

We could do anything, but the problem is if that is what community wants. Up to this moment maintainers did not prove that this is anything but their subjective wish against the community will. Bypassing it even more than today (which is already bad) would have very bad consequences for OSM.

[jeisenbe]

the problem is if that is what community wants

This is our policy, as the people who have volunteered to maintain this map style. I am posting this publically so that anyone can comment about it, but in end it is the maintainers, including you and I, who decide to merge pull requests and make new releases. So we are the ones who have to agree on how to handle situations when we do not 100% agree.

[kocio-pl]

Sorry, but it sounds like "in the end it's about maintainers, not the community".

Of course, it does not have to be that bad - if maintainers are following community, and that is exactly what should be shown and is not, for a long time now.

[jeisenbe]

Since only maintainers can merge PRs and make releases in this repository, and there is no technically feasible way to change that limitation, we have to make a decision about our policy about how we do that.

We can try to invite more comments and thoughts from other parts of the Openstreetmap community, but most people are not going to have a clear opinion without having spent a lot of time thinking about these issues and the history of this project.

[jeisenbe]

Do you have any thoughts about my comment above? #3977 (comment)

I would like to roll back the way-area based early rendering of bays and straits - see #3750 - this will address #4546 recently opened by a community member who is concerned that this style is encouraging mappers to spend a lot of time making large, difficult to maintain polygons. It would also fix the rendering issue in #3634 which you opened yourself, as a member of the Openstreetmap community who recognized a problem.

[kocio-pl]

Did you provide a platform for the people you say you are representing, as I have proposed? I have not heard about it. Did you show that is substantial - and it really exists? No word about it. Is picking such target guided by something else than personal preference? I don't see how. It's still maintainer talking about its needs without community taking that, looks like very subjective then.

[kocio-pl]

Since only maintainers can merge PRs and make releases in this repository, and there is no technically feasible way to change that limitation, we have to make a decision about our policy about how we do that.

With great power comes great responsibility. It's easy to concentrate on decision part without first making sure about representation part - it's exactly where your proposition failed.

[Adamant36]

An important open issue is about bays and straits - started in #3634 - recently mentioned in #4546 and previously in #3750
. We could roll back parts of #3438 and #3144 which were merged with little discussion and now have been shown to have unintended consequences.

Not to take this off-topic, but as someone who was involved in a lot of the discussion around, and a supporter of ,rendering bays and straights it would probably be best to roll back both. As there's clearly been unintended consequences to rendering them. I don't think "the community" necessarily supported #3438 and #3144 at the time either. So that shouldn't be an issue.

Based on what happened in #3855 / #3957 and #3969, most of us seem to agree that if all maintainers but 1 are in favor of removing a feature or rendering addition, we can consider that rough consensus. But that only happened after a very long discussion in those PRs. I would like us to agree as a team of maintainers that we will not try to block the removal of features on our own if there is majority support for the remova, especially if the previous change was not the result of full consensus at the time it was added.

In the meantime I think this would be a good way forward. I don't think the community ultimately gives a crap if certain features are removed. If anything there's wide support for it. Just as long as removal of features doesn't turn into a thoughtless, robotic "1 added feature=2 removed features" type thing. But the more important thing is just that the project moves forward, whatever that entails.

It's not like you can't open an issue for requests of what should/shouldn't be removed and go from there. Bays/Straights is obviously a good starting point. Just going off about "the will of the community" in absence of anything else just comes off like bike shedding though. There doesn't need to be a long, protracted discussion over multiple forums for every damn thing you could do to improve things before you do them. No one expects that. This isn't a direct democracy. You represent the will of the community by nature of being maintainers, which is enough in a good percentage of cases.

[jeisenbe]

Did you provide a platform for the people you say you are representing, as I have proposed?

Sorry, I do not recall what you proposed.

[pnorman]

We could do anything, but the problem is if that is what community wants. Up to this moment maintainers did not prove that this is anything but their subjective wish against the community will. Bypassing it even more than today (which is already bad) would have very bad consequences for OSM.

I fundamentally disagree with this. Leaving aside the difficulty of establishing what the community is or knowing what they want, its our job to decide what changes meet with our conflicting purposes, not that of the community.