[Tagging] remove “rendering” from proposal template

[stevea]

On Apr 22, 2021, at 10:52 PM, Peter Elderson <pelderson at gmail.com> wrote:
> "Rendering Suggestions" sounds to me that I am supposed to provide examples. That's not the idea, is it? My idea is that the proposer should reflect on the impact of the proposed tagging on rendering (and other data use). This could be very simple e.g. when proposing tagging a new amenity node and suggesting an icon and an overpass query, but it could also be complicated when proposing a change to a long used problematic tagging scheme where all data users have implemented their own interpretation and preferences, and now get yet another tagging scheme on top of that. 
> It should answer the question: how is a renderer / data user supposed to make sense of this tagging, given the state of the database.

This is thoughtful and helpful, Peter.  Yes, perhaps “suggestions” does lean too heavily in the direction of “supposed to provide examples.”  One solution might be to say in that section “the empty set can be an answer here.”  In other words, you may suggest, but you are not required to suggest.  “Leaving this blank is allowed.”

I believe we want to encourage as rich a possible solution set as is a thoughtful result from the imagination of the author.  That leaves open a very wide latitude from simple to quite complex and something in the middle, too.  And again, these are to be suggestions, not requirements.

However, we should sharpen focus on how much we leave open to interpretation.  I believe that while proposal authors should feel free to make suggestions for rendering, it is renderer authors (implementors) who do the interpretation of what the tag (or tagging scheme) “means,” where the sign or symbol is open to a visual representation, or “semiotics” (to use a more precise word) of not the proposal author, but the renderer author.  Renderer authors might appreciate a suggestion — it could fill in a blank if there is one in their mind — sensibly nudging towards a particular graphic direction by the proposal author.  But ultimately, rendering is up to renderer authors, not (tag, syntax) proposal authors.

> I see no harm in the proposer just providing rendering examples; then it's up to the RFC participants to ask for further reflection on the impact of the proposal on rendering/data use. E.g. by asking "How is a renderer/data user supposed to interpret this tagging, given that the database now contains.... Could you add that to the section Whateveritscalled?"

“Suggestions” vs. “examples” do have differences, though they are subtle.  Examples tend towards “characteristic of their kind.”  Suggestions are open-ended, far more free-form and malleable.  I think we want suggestions, not examples, in proposals as they attempt to “imagine” rendering.  Proposals do not (should not) SPECIFY rendering, but offering examples or better, suggestions, yes, I believe it is helpful to encourage thoughtful and well-imagined such things.

Where we appear to (slightly, here) disagree is “should answer the question, how is a renderer / data user supposed to make sense of this tag.”  First of all, renderers and data users are two different “ranges” of solution set (“range” in the sense of “domain and range”).  Secondly, I don’t think we do want to ask proposal authors to “make sense” of the tag for a renderer.  Renderer (authors) do that.

This is actually quite a deep and complex topic.  I appreciate others both following it and participating in it, as it does shape how people write proposals (an important part of why we’re here on the tagging list) and how proposals are wise to steer clear of saying “and this new tagging MUST render like this.”  I’m pretty sure we don’t want to do that last part.