In our initial meeting on Wednesday (IRC log), we outlined some steps and a fairly aggressive timeline to get ourselves in a place where changes to wp_dropdown_users() (#19867) and wp_dropdown_pages() (#9864) are suitable for patch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. review.
In 3.9, I started taking a look at solving some long-standing scaling issues with dropdowns, notably those for users (#19867) and pages (#9864). I arrived at a conclusion about our mixed usage of autocomplete and autosuggest far too late to make it for 3.9, and did not add it to my plate for 4.0, but would like to tackle it again for 4.1.
We can solve these issues smartly by using a combination of Ajax-powered autocomplete/suggest and smart defaults, e.g. users with the most content pre-loaded for quick access without having to run a search. As a brief overview of where I see us going with this – a roadmap, if you will: user dropdown, page dropdown, current instances of jQuery UI User interface autocomplete (multisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site users and new site), tags/nonhierarchical taxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. UI, more built-in taxonomy UIs (#14877), and possibly more as we discover appropriate places. Not all of this will happen in 4.1 – think of this as not only a solution to long-standing, painful problems, but also a step in a series of many.