[Tagging] remove “rendering” from proposal template

stevea steveaOSM at softworkers.com
Sat Apr 24 18:00:23 UTC 2021

On Apr 24, 2021, at 10:28 AM, Brian M. Sperlongano <zelonewolf at gmail.com> wrote:
> The information that I think we actually care about is:
> * Does this proposal change the meaning of or deprecate existing tagging which is currently supported by data consumers/renderers?
> * If yes, what will the impact be on those data consumers/renderers, and what is the proposed plan for transition, such dual-tagging, attrition, future mechanical edits, etc?
> What we are really assessing in these cases is whether the cost (impact to data consumers) is worth the gain in approving the tagging change.

Here, as Brian zooms out from the specific issue of "remove or include 'Rendering' from Proposals?, and/or put the word 'Suggested' in front of it," he ask us (correctly, imo) to weigh whether skewing the Proposal in a particular rendering direction "is worth the gain in approving (it)."  This would be worthy to do, IF the "Suggested Rendering" were REQUIRED to be "strongly associated" with the Proposal.  But it doesn't have to be:  as a "suggestion," it is "weakly associated," this section is optional, it could even be blank.  It does not have further dependencies on whether it cripples or dooms the entire Proposal simply because this particular Rendering Suggestion is (or is not) "worth the gain."  The entire reasoning for this, and why it even works in the first place, is because these ARE "suggestions."  These ARE "optional," and don't cripple or doom the proposal if the Rendering Suggestion is way off base or doesn't get adopted by a renderer author.  These are simply the (optional) ideas / suggestions for rendering by the proposal author, maybe they help someone voting "visually get it" (better), maybe they don't.  But they do this because we change the proposal template to say "Suggested" and "this is all optional, ultimately renderer authors make these decisions."

This really is related to why when we map with tags, we shouldn't tag for the renderer.  As we map with tags (use syntactically-correct sentences, like entering into OSM a well-tagged multipolygon), we allow the semantic interpretation of that syntax (tagging) to happen in the renderer.  Syntax has its realm:  that of mappers who "know and/or can see that something exists in the world to be mapped" and semantics has its realm:  that of renderer authors who interpret tags (well-uttered, syntactic "sentences") and then display them.  Recall that any of us are free to write our own renderers that emphasize and/or ignore certain syntax as we see fit for our particular desire to visually represent underlying data in the map.  A "Hiking / Camping Map" renderer author decides "I want to show what hikers / campers need to see" and so all sorts of data in the map not important to those use cases are (largely) ignored.  And if a suggestion for a syntax feature that deserves to be seen in this rendering doesn't "look right" in its wiki (perhaps derived from a Proposal that is Approved) s/he is free to modify or exclude it.  This is the renderer authors call, and rightly so.

> For truly brand new tags, if a proposal author wants to do an art project to show how they think it should render in Carto because they think it makes the proposal more compelling, I guess that's fine, but having it as an explicit section makes new proposers think it's expected.

All we need do is specify in the Proposal Template that "Rendering Suggestions" aren't expected to be followed exactly, these are merely suggestions to renderer authors, who really do have say in how this will or won't get rendered (including and especially in our Standard renderer, Carto).  And again, this section is optional, it can even be blank / empty (it should say so, if so).  When included as a Proposal, its specifications aren't required.  When included as a Proposal and is being considered by someone about to vote Approve or Oppose, this section must not be used as a "make or break" decision input.  We can clearly state all of this with good language in the template, and I think with "Proposal Suggestion" and "this is optional, not required" and "don't use this section as a determination in your vote..." we're mostly there.

> It also risks people voting against the proposal because they don't like the rendering suggestion, or don't think it should render in the default map at all, which is an independent question from how to tag things.  It also discourages people that are not artistically inclined from writing proposals if they feel that a sample rendering is expected.

Totally "fixable:"  say the section is optional, say it shouldn't be critical for voting.

> I would rather see proposals clearly and squarely focus on the modeling and data structures, with strong, compelling examples, versus back-door Carto rendering requests.

Now that you mention "back-door rendering requests," (I agree that sort of "hijacking" has been attempted before and should be heartily discouraged going forward), we might mention that this section (Suggested Rendering) is absolutely no place to be trying to force any particular rendering, as doing so is not the realm / domain of proposal authors.  It is squarely the realm of renderer authors.  (On rare occasion this might be the same person, but the roles, the "which hat is being worn?" are clearly one or the other).

We can do this.

More information about the Tagging mailing list