Making WordPress.org

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#287 closed defect (bug) (fixed)

Core Trac "focuses"

Reported by: nacin's profile nacin Owned by:
Milestone: Priority: normal
Component: Trac Keywords:
Cc:

Description

The current "ui-focus" keyword actually comes from an idea to add a new "focuses" field. It'd be like a cross between a component and keywords. Keywords correspond to workflow, components correspond to areas of core, while focuses are more general groupings of tickets designed around contributor skills and/or big picture areas of core.

For example, here's all of the focuses that at one point have been proposed (not suggesting all of these would be added): ui (or ui/design), javascript, accessibility, administration, template, rtl, performance (or performance/caching), multisite, unit tests, docs, text changes.

  • Does a bug with (or desire to add) caching in a comments-related function belong in the Cache component or the Comments component? Well, it'd be ideal for people following/maintaining the Comments component to see it as it is relevant to them, but it could also benefit from the developers with expertise in caching. However, the Cache component is really for the Cache *API* (something we'll make clear with component renames). Thus, the ticket could go in the "Comments" component but also be added to the "perf/caching" focus.
  • Does a wp-admin/widgets.php issue belong in "Administration" or "Appearance" or "Widgets"? (It belongs in "Widgets" with a focus of "admin").
  • Does a themes.php issue belong in "Administration" or "Appearance" or "Themes"? (It belongs in "Themes" with a focus of "admin").
  • Does a bug with users that affects multisite belong in Multisite, or Users? It belongs in Users, with the multisite focus. There *are* however some tickets that are inherently best described as "Multisite."
  • Does an issue with a comments template tag go under "Comments" or "Template"? Or a "Template" sub-component within "Comments"? Ideally, it goes into "Comments" and a "template" focus, that way we don't have "Template" subcomponents all over the place. (Someone heavily interested in providing tools to themes are going to want to follow along *all* template tickets.)
  • Does a new set of unit tests for shortcodes go under "Unit Tests" (no, that's for the framework now) or "Shortcodes"? How does someone looking to review JS unit tests know where to find them?
  • Does an accessibility-related ticket for themes.php go under "Accessibility" or "Themes"? It should be added to the Themes component, with administration and accessibility focuses.

Ideally, this eliminates or severely pares back a number of components, including Appearance, Administration, Template, Multisite, UI (already gone), etc.

I think this plan will start to take more shape in the coming weeks as we re-do the components tree. I've cleaned up Formatting and General but still have another few big components to look through in order to get a better idea of where the ambiguities are.

Comments welcome!

Attachments (2)

Screen Shot 2014-01-20 at 7.29.33 PM.png (32.0 KB) - added by nacin 11 years ago.
This is the UI it creates.
meta.287.diff (1.5 KB) - added by nacin 11 years ago.

Download all attachments as: .zip

Change History (16)

@nacin
11 years ago

This is the UI it creates.

#1 @nacin
11 years ago

In 301:

Trac: Add initial support for 'focuses'. These are a cross between a component and a keyword. Disabled for now - see #287.

@nacin
11 years ago

#2 @jeremyfelt
11 years ago

I like this.

As somewhat summed up at the end of the ticket description, there are a bunch of components on the current list that often or always coexist with other comments. This makes it tougher to choose when creating a ticket and tougher to see related things in one place.

With a primary component and multiple 'focuses', a large effort—merging featured plugin, etc...—would have an easier time getting eyes from many people that are interested (focused?) on a 'focus' when necessary.

I can't think of anything offhand that would require the Multisite component to remain in place. Once we think of it as a 'focus', all the pieces may be able to spread out. I think Network Admin could probably be removed completely.

#3 @nacin
11 years ago

I looked through everything in the performance component and had no issue immediately identifying the component each ticket should be moved to.

I had more trouble with multisite. What do you have in mind? While the new Bootstrap/Load component can handle so much of ms-settings et al, many of these tickets have to do with inherently multisite concepts. The network admin is a good example of something that sould probably keep its component. A new Login/Registration component would cover a lot of others. What about tickets citing My Sites or get_blog_details() or switch_to_blog() etc? So My Sites could be snuck into Network Admin, but would we need a new "Networks/Sites" component to handle the rest?

FWIW, I'm happy to just work with you to convert everything over. If we end up needing to roll it back, that's easy.

#4 @jeremyfelt
11 years ago

Hmm, good points. I think my brain was filing Network Admin into Administration, but that's a 'focus'.

Bootstrap/Load and Login/Registration make sense. A Networks/Sites component could work for those things that are specific. I like the idea of a new name for the component rather than leaving it at Multisite for both.

I'll take a closer look at the current tickets and look for some holes.

#5 @jeremyfelt
11 years ago

I did a quick read of the summary for each of the 112 Multisite tickets and assigned 113[1] of them to components on paper with as I went.

20 Network/Sites
19 Login/Registration
18 URLs
14 Users
12 Bootstrap/Load
07 Options and Meta
04 Upload
04 Filesystem
03 Themes
03 Taxonomy
03 Plugins
02 Upgrade/Install
02 Database
01 Query
01 Mail

In that list, URLs is not a component. That includes tickets for SSL or functions like network_admin_url(), etc. It's possible that this could belong to permalinks (?). Or maybe URLs/Permalinks. Or maybe I've missed something completely.

I grouped things under Network/Sites that I might also consider assigning to Network Admin. After reading through the summaries under the current Network Admin component, I still think Network/Sites fits better. Quite a few of those tickets would be assigned to Users or Login/Registration or ...

Of course, we won't know until we do it. :)

As soon as 'focus' is added, I'll be happy to cruise through and assign components. I think the resulting reports from that step will help us correct as we go.

[1] Yeah, oops.

#6 @nacin
11 years ago

In 306:

Trac: More focuses updates. see #287.

#7 @nacin
11 years ago

In 309:

Trac: Explicitly sort fields on the ticket screen.

This positioning is necessary for rendering the focus field. But this also results in some good pairings. Milestone and priority are on the same row (and both are disabled for non-gardeners). Priority and severity are adjacent. So are focuses and components, and focuses and keywords.

see #287.

#8 @nacin
11 years ago

In 310:

Trac: Add focuses.ini. see #287.

#9 @nacin
11 years ago

In 311:

Trac: Add focuses to core.trac. see #287.

#10 @nacin
11 years ago

In 315:

Trac: Suppress special Trac report filters when variables are in use. see #287.

#11 @nacin
11 years ago

In 351:

Trac: Add new 'administration' and 'template' focuses. see #287.

#12 @nacin
11 years ago

  • Resolution set to fixed
  • Status changed from new to closed

#13 @nacin
11 years ago

In 371:

Update Trac patch to handle focus-based subscribers and new ticket subscribers. see #127, #287, #300.

#14 @nacin
11 years ago

In 373:

Trac Notifications: Updates to the preferences form for focuses, new tickets, and subcomponents. see #127, #287, #300.

Note: See TracTickets for help on using tickets.