Skippern has commented on the following diary entries

I am not sure if I like it or not, but a face lift was clearly needed. Moving the style in our own direction, not following any particular known rendering is also important, as we should not be the free version of OS or anything like that.

I understand that visibility and usability in densely mapped areas have been of importance, while I generally work in areas with less details. I don't know if there is any significant improvement for this, but will wait for the production server to adopt this before commenting further.

Excellent news! I was surprised to suddenly see sniffed signs in my area, and the amount of them, appears that all of them are from my Mapillary contributions. Hope this will help improve the map data and community contributions.

Just got my VIRB Elite a few days ago, and are trying to upload with the video upload on Mapillary, but either there is some form of size restrictions I cannot figure out, or my internet connection isn't good enough. I am therefor looking for a good way of transforming the videos to georeferenced photos I can upload with the upload_with_authentication.py

Also, even badly documented wiki-pages using the KeyDescription or ValueDescription templates already tell you a lot about the tag usage, from there it should not be too hard to evaluate how useful it is, in what combinations it have been used, etc.

People should not be afraid of making a useless wiki-page, those templates provide enough to say, in most cases, that the documentation is at worst thin, but never useless. Complex schemes need some more though.

@imagic: I agree that the process is not good, it is actually horrible. And in many cases I have seen the proposal being edited several times during "the voting period", which actually should render all previous votes invalid. I have also seen other documented tags being altered in order to affect the voting result (why should we approve this when that already mean the same (edited 3 days into the vote)).

The proposal page must be frozen before the vote

Documentation of affected tags must not be edited during vote

A significant portion of people should vote, principally those with knowledge of a specific field if one talks about deep-defining tags within special areas (such as electro-people to have much weight into what tags are useful, sensible, etc in tagging a generator)

At the moment the "status" of the documented tags take up too much space (too vivid colours, too large font type), and some people are throwing in templates for this tag have not been proposed or this tag have been rejected. The only template I find useful in this case is this tag have been deprecated by new tag

As a data consumer documentation about the usage of tags, and the availability of additional information that can hint me to how best parse the tags is good, I like TagInfo since I can compare the global usage with my specific area of interest, what combinations are common, etc. Should I bother to make rules parsing name to a feature existing millions but only two have been named? TagInfo can tell me something about that. And a good wiki-documentation can also give me some indications there.

There are unfortunately some diehard voting-nazis (yes I mean that negatively), that are quick to delete wiki-pages for tags they don't like etc. I once had an edit-war on wiki because I suggested an data enhancement of maxheight by adding maxheight:physical and maxheight:legal, where my page on maxheight:legal immediately was deleted because maxheight means maxheight:legal.

I still managed to create my page, IMO maxheight is generic while maxheight:physical and maxheight:legal is equally more specific. Is there a reason to separate these values? If not than body use maxheight, if there is a deeper reason to specify maxheight:physical, what makes that different from maxheight:legal? Is maxheight the same as maxheight:legal in every country or does some countries differ from that rule?

When working with maxheight I got the impression that (at least the guy who deleted my page) lived in a country where maxheight means maxheight:legal, while I live in a country where the two are equally different.

In my opinion it is more important to document on wiki the tags that are in use, albeit in a relatively small area or by a very limited interest. Or specially in those cases.

TagInfo speaks for itself, and as every wiki-page using the templates for Key and Tag-values implement a info-box about usage inherited from TagInfo, than I find that a wiki documented tag tells more than a vote.

A vote though might be useful indicator when changes to an existing tag are suggested. It can help refine the proposal, make people aware of the upcoming change (I know you still are at liberty to do it the old way), and most importantly a signal to data consumers that changes in the data they use might occur.

This triggered my curiosity, but I am disappointed that I would need another iPhone app, and that it will not consolidate datas from other sources. It would be a nice addition if it could analyse Mapillary data, and extract speed signs (and other road signs for that matter) from that source. I am already preparing to gather even more Mapillary data as I find that very useful addition to MapBox satellite or even Bing for getting correct information on the map. If I need to have 4 or 5 iPhones to gather all the information useful for the project, than it will result in few or little data being collected.

Skobbler should have the data capacity to scan Mapillary for roadsigns on a regular basis. Which will leave me in peace to gather Mapillary, and other similar projects derive from there.

The mayor only wants tourists that spends a lot of money so that he can fill up with money he can use to sniff cocaine or whatever he is doing, don't think he like the population much either, the only thing he have done in 2 years was to move a few bus-stops.