Fields should define whole properties instead of just keys/tags.

[slhh]

Sometimes a property like the speed limit of an highway is potentially defined using muliply keys.

Where possible a field should define a whole property and not just one key/tag.

For example the speed limit can be directional, lane dependent, and/or conditional. In these cases the speed limit would be invisible in the all fields section. An unexperienced used can easily miss such an already tagged speed limit and just set maxspeed, which would make correct data wrong.

Of course it is too much to always show a field every potential key. A smarter solution is required instead.
For maxspeed the dropdown list/value field could have three additional items "directional", "lane-dependent", "conditional". Of course these values must not go directy to the tag. Instead they are indicating a more complicated setup. In case one of these values is selected, a button should appear next to it, which is opening a window to describe the property in full. Of course this window needs to include a field to specify the basic maxspeed tag, because the special value selected outside can't go to the tag.

In case the related tags of a property are set in such a way, that they can't be supported by iDs user interface, the display of the field should change to just displaying all related tags in an all tags section like style.
It is ok to require an user to use all tags section to modify something, but it is not ok to hide existing information by displaying it in the all tags section only.

[bhousel]

A few of our fields do manage multiple tags in a single interface (e.g. access, address, cycleway), but this requires custom programming. Building special fields like this takes time, so it's not something we would do unless there is a common and global case for it. We do welcome code contributions - for example the cycleway field was added by @ebrelsford (thanks! #2686).

The vast majority of OSM tags are one property per tag. When this is the case, we can add a simple field to support the property in as little as 5 minutes. But because OSM tags are completely made up by volunteers and can contain anything, iD will never be able to support every tag.

For what it's worth, you mentioned lane tagging above, which I agree is of global importance and usefulness, and so we are making improvements this summer so that lane tags will have their own special field in the sidebar.

[slhh]

@bhousel Of course my issues are not intended to be work orders for you. It is quite ok to wait for contributions, but closing the issues doesn't seem to be the right way to get contributions. In addition closing the issue is restricting discussion, because the issue becomes less visible. How to solve an issue needs to be discussed well, otherwise a code contribution will likely be a pure waste of time due to a huge chance to be rejected.
Instead of closing you might use a label like "Contributor?" indication a external contributor is wanted, in order separate the issue from your own to-do list.

Not eyery property will need a special field. For most properties the current standard fields are sufficient, some groups of properties seem to need some new more advanced standard fields, and only a few properties will likely need their own special field.

@kepta Do you already have a concept how the lane editor should work? Is #387 the right place for discussion?

[bhousel]

Instead of closing you might use a label like "Contributor?" indication a external contributor is wanted, in order separate the issue from your own to-do list.

I closed this issue because there doesn't seem to be anything specific and actionable for us to do.

If I understand correctly, you are asking for fields to support "collections of tags" not just "one tag per field". And my response was, "yes sometimes they do, but this approach requires extra programming, so it's only for really important tags".

You also said,

...it is not ok to hide existing information by displaying it in the all tags section only.

I disagree, and I think it is ok to hide tags in the all tags section, when the tags are of limited usefulness or not the kind of information that a casual mapper would be able to provide.

Is #387 the right place for discussion?

Yes, you can discuss lane tagging there.

[kepta]

I have shared a link to my proposal at #387. Please have a look.