I just noticed Media Types was in Structure in Drupal Gardens, this is the wrong section. Media types is something you configure once, and after that touch only on ocassion. Structure is D6 it's sitebuilding, with that in mind not all field configurations neccairly have to be in Structure - especially if used only rarely.

Yes, I think the main difference is that it will be used far less frequently. We do not have a navigational pattern for entities and field UI parts - see for example terms and users. Its placed all over the place. I think it makes more sense to place this near other Media configurations, rather than place it far from it (in terms of finding it) and not place in Structure (because of bloating a page, with an infrequently used item)

atm, i'm neutral either way. though i admit that i was originally caught off guard by the move, especially considering that from what i recall the #media section was made specifically with the media module in mind, though i'd have to dig up the original issue...

Since this module has been in production for 30k people and there are thousands of postings on the drupalgardens.com forums and not one person has mentioned this in the past 6 months, I don't see this as "unable to use the module because they can't find this settings page."

Anyway, we take UX really seriously, and I would absolutely consider UX bugs critical if an important (80%) feature of the module was difficult to use / discover for a majority (51%) of the people using it. I bet 5% of the user base even goes to this page, and I imagine most of them can discover it, so I while I agree that moving it makes sense, I couldn't consider it critical.

Critical
Critical bugs either render a system unusable (not being able to create content or upgrade between versions, blocks not displaying, and the like), or expose security vulnerabilities. These bugs are to be fixed immediately.

In Drupal 7 this also applies to test failures: we have a policy of a 100% pass rate for tests, so failing tests block all other development.

Major versions of Drupal core (like 6.0 or 7.0) won’t be released until all critical bugs are fixed. For point releases (like 6.1 or 6.2), critical bugs won't hold back a core release if a security update is needed.

In contributed projects, it is up to each maintainer how they handle the critical status.

Probably best not to discuss this over in a already fixed issue. I do wish to explain though there are several reasons why I would mark this critical :

1) Finding functionality is critical (that there has been no reported issues about this, to me says little. For example, the most critical findings of usability tests on D7 showed inability to find "create content" as a big issue - though this is hardly ever reported in issues/forum posts).
2) It breaks with convention where you would go to find "Media" configuration (keeping concepts like this in tact is important when more contrib modules start adding their functionality)

I am sure people will find this, after all its in Structure which only has some 7-12 links most of the time - but it might take them longer than needed, this we way prevent that.

I only marked this critical because of 1) and 2) and because of the value we put to it in Drupal 7. Obviously any contrib maintainer can take his own judge on that. The Priority page sadly is incorrect, it says little to nothing about how to handle UX issues (for example, by its definition of critical nothing hard to use would be considered critical as long as you can use it - in reality we have escalated quite a large number to critical)

Last week I have been playing with Media module, finding out what it does and how to use it. Having experience with D5 and D6, the knowledge that there are many similarities between file entities and nodes helped me to understand what I needed to do. However, new users will also quickly find out that there are similarities between nodes and media. Looking at the content section, Media follows the navigation structure of the Node module (/admin/content/node, /admin/content/media). That's why I also expected Media to follow the Node module in other parts of the administration menu.

Basically, the argument to move Media types to configuration is that it's used less often than Node types. I haven't seen proof for this statement. After a site is published, I don't visit the node type configuration pages often either. I don't see why I the Media type pages would be any different in that respect.

More importantly, the IA is not structured around the frequency of use to begin with. The IA is structured around meaningful topics such as 'content', 'structure' and 'people'; they are not called 'daily tasks' and 'initial setup'. The fact that some sections will be visited more often is a logical result of structuring by topic, but it should not be a goal in itself.

hm .... I have to agree with marcvangend. I remember the 2 days on IRC where I made a fool of myself wondering where these media files will be set up now, but it was already there. I think the most counting argument here is the "manage fields" and "display fields" feature which is 100% expected near to the pendants for content types. Even if it doesn't work yet fully, the admin structure shows where media and file_entity plans to go (hopefully) and this is definitely site structure and for the D6 users site building in mind, but not configuration settings, what is more about general settings of the site and some configurable modules.

And somebody who is using all the file types already provided will use this manage fields part for files very often.

A pattern has been established in core that node entity bundles are configured in structure. Configuring a file entity couldn't be more analogous as an operation. By storing it under structure you are working with the user's mental model of how entities are configured.

I don't feel that the rationale of 'it is not used much' is really the guiding principle for the IA - if it was our main menus would be structured along the lines of 'most popular' etc.

I don't have a strong opinion here given that both arguments are valid:

Why muddy a menu items that houses everyday features like Basic Pages, Menus, Taxonomy and Views with 'preference-like' features that configure your site?

Conversely, why separate 'like' features that provide context in order to prevent muddying a menu?

Honestly, I think the catalyst of the problem is the IA itself. Config vs Structure vs Content continuously confuses both end users and developers. End users don't understand why some things are content where as others are structure, and developers aren't sure where users should interact with their module. Until this problem is solved, no solution is going to be ideal.

That said, I side on a solution that best maps to a long term strategy. In my mind, that long term strategy is one where 'Structure' is a thing of the past, and 'preference-like' features are grouped together. For me, keeping the location under config is a better long term plan. I hope and pray "structure' goes away in D8, and as such, it seems foolish to place it there. Doing so means in D8, people will again have to ask this question "where did media types go?"

I'm not so sure on this either. To configure user fields and how those fields are displayed, it's located under config, not structure. That said, it does seem to make more logical sense to put it where everything else puts their bundle admin screens.

Rationale:
1. We know from many usability studies that new users have no idea that you can extend Drupal's content types because adding new ones is not in the proximity of existing ones. Although we haven't done so yet, I have a high confidence level that adding such a link will bridge a major gap for new users.
2. Placing Content types and Media types both under config solves the relationship issue outlined in #11
3. Placing Content types and Media types both under config solves the issue outlined in #19 where Structure is muddied by everyday items (pages, views, taxonomy) with non-everyday-preference-like features (content types, media types).

It would be really good to maybe get Bojhan's opinion on this. We have lots of reasons why this 'revertion' is beneficial:

People are used to configuring their entity's display and fields under 'Structure'. We've had more people get confused about where to go configure their file type displays now that it was under admin/config/media/file-types.

The file_entity module now actually has file/%file pages that are visible to end-users unlike before.

If we want to enable translation of file entities, we are unable to do so under admin/config/media/file-types because we will hit the 9 argument depth limit for menu router items. For example, admin/config/media/file-types/manage/image/fields/field_image_title/translate/fr is 10 segments.

I wasn't aware this was already in. In general the comments of marcvangend in #11 are still the valid reason for this living in config. The concerns express by jeff noyes are valid, but also out of scope for a contrib to solve.

In terms of the downsides you express;

1) We don't really have a pattern for entity configuration, as you might notice - the random placement of comment, taxonomy and user field configuration. What we have done instead is try to place everything close to each other, the same applies here. There will be confusion however, because you move something. We learned through D7UX, that moving items is not met with much love :)

2) I don't really know what this means, for where you place it.

3) This is a very stupid core limitation. Feel free to patch it, I have done so already from 8 to 9.

@Bojhan: The patch isn't in. Adding/Managing fileds/displays for media has always been in Configurations.

As I see it:
Content = For content editors
Structure = For site builders
Configuration = Site administrators

For me, adding and managing fields and displays for the media types is a site builder task similar to working on the structure/display of content types and taxonomies. So, the logical place for doing the same for media types is in the Structure section, which is where the patch in #26 is moving it to.

Sure, we can fix the Drupal 8 menu router to have more than 9 path segments (and WSCCI likely fixes that for us), but for D7 we're locked in at 9, so I have to pull this trigger now otherwise we're blocking support for File translation. We can re-review this IA when we attempt to merge the file_entity module into Drupal 8.