Participants: Helen Hou-Sandi (leader), Dave Martin, Sara Cannon, Drew Strojny, Tom Auger, Ronnie Burt, Andy Peatling, Amy Hendrix (note taker)

Notes:

General question for contributors : how did you get started, were there pain points, things they wish had been there; for non-contribs: what would help you get started?

• One person got derailed by figuring out the step after the dev chat — what’s already being worked on, make a commitment to an initiative but then what’s the communication channel?
• overlapping efforts can be discouraging
• we need to be better at keeping ALL discussions public (IRC or make/ui) instead of falling back to private conversations
• we aren’t always good at saying “this is what we’re currently working on”
• lone dev still happens
• suggestion for newer contribs: get comfortable with IRC, learn to use the bots (the .tell command is brilliant!), ask in public rather than one person’s email.
• Goal: get better at building small teams that play on individual strengths
• Dave: works for Automattic, wanted to contribute, but found it super-intimidating even as an experienced dev + Automattician.
• We can keep a list of who’s working on what projects (Make P2P2 P2 or O2 is the term people use to refer to the Make WordPress blog. It can be found at https://make.wordpress.org/. is important for this, not just IRC convos), what issues are being worked on, what needs help
• Helen: wants to improve weekly posts on make/ui – combine with meeting notes – what we did this week, what has new patches, what needs work, what to do this week

Discussed improving the wp.org site. Challenge: how to open-source portions of things (not just a UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. group challenge); we want better design and feedback for .org, but currently the workflow is that one person (Otto, Nacin, Scott) gets a request and might have time to implement it.

This is also a challenge for the team’s work in general – we have a huge range of things we touch (graphic design, UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. design, user testing, front-end engineering, accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility), QA), and people with a lot of different skillsets. How can we get better granularity, and get better at breaking things down?

• work iteratively! (this is a comfort level thing as well as a project management thing) — don’t work for a month getting something perfect, be comfortable submitting something that’s partway there but will still need more.
• question about dealing with ticket “ownership” – do you jump in on something that people are already working on and risk stepping on toes? or do you avoid it when it might need more people working on it?
• Make sure to give props/recognition for everyone (including non-coders)

We should have guidelines – but as general principles, almost like mission statements, rather than strict checklists. This is also useful as a decision-making tool for handling UI questions/requests.

Challenge: we don’t have a committer in our group, and have to get the attention of one that isn’t fully involved in what we’ve been discussing. We sometimes land things prematurely, back out, things get in that we didn’t intend… looks bad, breaks our processes.

Reaching out to new contribs and non-developers:

• can we use Make P2 to post specific patches for discussion requests?
• can we find one-hour tasks? matchmakers? people like to be asked.
• dedicate time to training contributors (maybe in office hours?) – how to use trunk, make/apply patches, etc.

A lot of non-developers have been interested in UI work but get scared off by technical aspects OR stick around for discussing mockups but then leave at feature freeze when there doesn’t seem to be as much place for designers etc. Those would be good times to work on improvements outside the specific release – ongoing tasks, wp.org improvements

Lightning round: One improvement wanted per participant:

• curated list of things to work on x2
• public posting of the scope of the group
• clarity about communication channels, who’s on what
• channels for non-devs. we have a lot of connection to (design, a11yAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility), …)
• testable patches
• manage TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. better – use keywords, use them consistently (needs-ui-testing)?
• ways to attract & keep non-developer contributors
• preplanning for future projects (even after feature freeze – discussion dies when the feature is done or the mockup discussion is wrapped up)

Action item:

• Review + publish a version of the contributing to UI doc in the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. contributor handbook (draft, can be abbreviated for now)