Meeting Summary, 7/3

What we talked about today:

  • Briefly touched on @lessbloat‘s post about an advisory group. We should discuss that more right there in the comments of that post, especially if you are linking to resources. Basic consensus is that it’s a great idea.
  • The things we’ve observed and learned from the three user tests that have been done so far. @lessbloat is also going to run some tests focusing on the CMS-type tasks. We discussed low hanging fruit as well as bigger things we can approach, whether for 3.5 or 3.6. More details on those will come in follow up two separate discussion posts. We need to be disciplined about being data-informed rather than data-driven (especially in these small sample numbers), the prioritization of tasks, and being realistic about effort levels and commitments.
  • Pre-flight checklists for things that should always have eyes on them before a release, or rather, before a cycle nears beta. This includes things like the about page and welcome panel as well as process lists for things like patch review/testing. Ideally we’d formalize a few of these. As @jane said, checklists save lives, really!
  • A very quick discussion about the process of UI in WordPress core, from design-y side things like graphics and mockups to turning them into Trac tickets and code/plugins/patches. We need to get back to the way things were/supposed to be and dig up an old post on the process. Briefly, this means that design iterations can happen right here on Make UI rather than Trac, as Trac can be intimidating for some folks and often does devolve into linear discussions about details and code. As a team rep, I (@helenyhou) will be happy to summarize for #wordpress-dev chats or on Trac as crucial points are hit. For those who aren’t as comfortable with code and/or SVN, we should buddy up in pairs or small teams and work together to get working code and then turn that into a patch. For example, a design and front-end type can work with a dev proficient with SVN to get their idea turned into a nice clean patch, or a design-type can work with a dev who’s still learning about contributing along with a seasoned contributor. Again, I’ll facilitate folks getting set up to work together as needed, but since we’re all very friendly, there’s a good chance it’ll happen naturally. There are also going to be clearer paths for discussion and review.

I would like to note here that we encourage plugins for proposals that involve UI changes because not all people (or realistically, the minority of people) know how to apply a patch or have an environment in which to do so. A plugin, whether or not it’s actually in the .org repo, is a better way to get non-coding types to have a go at testing. I think this is sometimes not well communicated or understood and can come across as a brush-off, so I thought I would write it out here again.

Things to do:

  • Discussion posts here on Make UI – coming shortly. These are going to function sort of as writing prompts.
  • Yet another survey post about contributors so we can have a reference point for teaming up.
  • We should write up some documents like “Getting Started with Contributing to the UI Group”, guidelines for things like QA/testing, RTL, and accessibility, and some of those checklists mentioned above. Remember that we strongly encourage iteration :)