Summary: Core UI team discussion
Participants: Helen Hou-Sandi (leader), Dave Martin, Sara Cannon, Drew Strojny, Tom Auger, Ronnie Burt, Andy Peatling, Amy Hendrix (note taker)
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 P2 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 UI 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, UX design, user testing, front-end engineering, 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, a11y, …)
- testable patches
- manage Trac 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)
- Review + publish a version of the contributing to UI doc in the core contributor handbook (draft, can be abbreviated for now)