On 6 January 2011 16:46, Steve Bennett <[email protected]> wrote: > In your thinking there seems to be the assumption that we run some process > *per tag*. I think it works better to run a process *per schema revision*.
Oh, a regular update schedule, that might be a good idea, however ... > Let's say we think that there will be a revision on January 1 next year. You > might have a process like this: > Jan-Mar: Suggestions for tag changes, stored in some structured location. > Apri-Jun: Discussion on tag changes. Unpopular proposals can be killed. > Popular ones need to be fleshed out > Jul: Voting on tag changes. Votes could be "yes", "no", "needs more work". > Aug-Sep: Writing up of spec for tag changes, explaining what's going to > happen. > Oct-Dec: Implementing new spec across all editors, renderers, documentation > etc. > Jan: go live with new schema, commence discussion for the next round... I'd suggest at most updating quarterly. This should be ample time to discuss simple changes that most people don't have a problem with, update the wiki and push editor makers to make necessary changes and finally have people update their style sheets to the new tags, they could run modified tags in parallel so they aren't surprised when things change. As for timetable, I'd suggest allowing tags to be discussed for as long as they like, and have a freeze period where accepted changes can no longer be changed and then a change over period where objects might be dual tagged where possible and finally the depreciated tag removed. _______________________________________________ Tagging mailing list [email protected] http://lists.openstreetmap.org/listinfo/tagging
