All right.
Um, thank you.
Um, so this talk is generally for projectmanagers, product leads, and non-developer
contributors, uh, who want to play ameaningful role, uh, in open source
projects, broadly speaking and in leadingWordPress releases more specifically.
So what does it take to lead aWordPress release or any other
major open source initiative withoutwriting a single line of code?
I can't see with those glasses up close.
Um, so in this talk, I'll walk throughhow I've helped shape and ship multiple
WordPress releases by leaning onproduct thinking, project management
skills, and what we'll call glue work.
Today you hear the story of a contributorwho moved from helper to release deputy
to AI team lead all without commit access.
Along the way, we'll exploreoften invisible roles that keep
the WordPress project movingalong, coordinating feedback.
Managing timelines, nudging consensusacross Slack and GitHub, and motivating
contributors across time zones.
I'll share some practical tools,patterns, and some gotchas leading to
leading distributed contributor teamswith Focus on how you can lead, even
if you're not an engineer, whetheryou're a project manager, designer, or
just someone who makes things happen.
This session will help yourecognize what leadership skills
look out like outside of the code.
Understand the real impactof glue work and open source.
Find your place in the WordPressproject and level up your contributions
and leave with clear ways to getinvolved in releases, roadmap
work, or contributor organizing.
So also, hi, as he mentioned,I'm Jeff Paul, VP of Open
Source at Fueled and 10 Up.
Uh, I've been contributing to WordPressreleases going back to, uh, 4.7 in.
August to December of 2016.
Um, sometimes as a release deputy, thensometimes as a release coordinator,
and sometimes just as a facilitatoror helper behind the scenes.
But here's the catch.
I've never had commit access yet.
I've helped shape and ship multiple,major versions of WordPress.
You don't need commitaccess to have an impact.
This talk is about how that'spossible, and more importantly
how, and you can do that too.
You don't need to be a corecommitter to have real impact.
What you need are product thinking,non-engineering skills like
project management or designingdocumentation, generally some
things that I call glue work.
And by the end of the session I want youto see some clear ways that you could
lead an open source, even if you'venever written a single line of code.
So that's a very small chart.
Um, but historically as historically,WordPress has been developer driven.
Right?
That makes sense.
After all, it's software, but thatimbalance means we often lack project
or product managers who can helpstep inside the roles of coordinator,
communicator, and facilitator.
I've highlighted the two releasecoordinators here in this picture
from WordPress six, eight.
It's tiny, and we're in pink.
So that's me.
That's Michelle Ette,who spoke earlier today.
The one Pink circles me theother, Michelle, Michelle, Chet.
There might be some others inthere that are PMs, product people,
designers, but conceptually speaking,that's mostly engineers that
are committing to the code base.
Right?
So you can kind of see visually thatthe disparity between, uh, those that
are non-engineers and those that are.
I would like to try and get moreof people like me in the project.
There are things that we can dowithout, again, uh, needing to have,
commit access or being an engineer.
Hopefully we'll get intoa bit more of that today.
Um, and so, yeah, I pointed outMichelle, myself, we both the release
coordinator for the release, um.
Again, I'm sure they're more there.
Um, but it's clearly dominatedby engineers on that chart, and
this is not a unique situation.
Uh, project and product managers,designers and writers often contribute
in ways that don't show up in the gethistory, but are successful to a release.
The WordPress release handbook evensays that the main focus of the
release team is to lead the releasefrom beginning through launch to
act as connectors and facilitators.
It doesn't say anything in thereabout writing code, reviewing code,
testing code, or committing right it.
Connecting and facilitating.
Those are things you don'tneed to be an engineer to do.
Uh, in practice though, most ofthat work does end up falling on
engineers who are already busy coding,reviewing patches, testing patches,
and that means that the net result.
And the output of engineering effortis lessened because they're focusing on
connecting, facilitating in the meeting,uh, when they otherwise could be focused
on, on coding or reviewing and testing.
Um, that result can also be bottlenecksand decision making, some inconsistent
communication and stress whenthose release cycles get crunched.
That's the gap I wanna try and fillwith y'all here and maybe any that
are watching this video later on.
So, like I said, my own pathstarted small back in WordPress 4.7.
I was a release deputy.
There were two deputies for that release,um, because Helen Ho, who was the release
lead, wanted some diversity in the, in theperspective of people leading the release.
Two engineers and myself, 1:00PM and a bit of redundancy in the
availability because all three ofus had some, uh, previously planned
time off during the release cycle.
Um, up until 4.7.
It was generally onesingular release lead.
These days we have release squadswith a bit more people involved.
Um, but back in four seven is whereit shifted to have a bit more, uh,
diversity in in people on the teams.
Uh, during that time, I really didn'tknow how the release cycle worked.
I didn't really know how the sausagewas made as it was in WordPress Corps.
And so I listened, learned while fillingin gaps that Helen and Aaron Jbe,
who was the other deputy at the time.
Either didn't have time to do, um, orreally in some cases they didn't want
to do because they're engineers anddidn't wanna do some of the things that,
uh, myself, as a PM at the time, feltmore capable and interested in doing
that release had 466 contributors.
237 of them were brand new.
So imagine onboarding 237 first timerswithout any project managers, right?
That, that lack of kind ofnative process thinking, uh.
Which to a pm might either be,uh, innate or at least learned.
Uh, those 237 people need some peoplethat can help guide them into the project.
Um, so that's when I realized thatfacilitation is just as important as code.
Um, not just in shipping releases,but in helping ensure that the
project continues to scale,onboarding more and new contributors.
From there, I continued fillingin the gaps and taking on tasks.
That related more to PMs than toengineers, and I stepped up on additional
releases 4.8 as a lead four, nine as adeputy, 4 8, 5, 8 as a contributor, six,
one as a tech lead, and most recentlyhelping lead six eight with Michelle
Chet, like I showed on the earlier slide.
Again, all those without commitaccess, without writing a line of code.
Uh, so the pattern to me was clearthat glue work, those pm sort of skills
really help scales the project, uh, andcreate space for contributors to succeed.
So, you know, what do I mean by glue work?
Um, it's the invisible leadership.
I think that, that holdsa release together.
It looks like things like triage, right?
Reviewing issues and pull requests tomake sure they're relevant and actionable.
It looks like aligning scope so that betasand rcs are manageable release candidates.
Rcs, it looks like keeping decisionlogs, so that's recapping discussions
and arguments from long running topics,um, usually as a comment and an issue,
uh, in GitHub or a ticket and track.
Um, so that those topics don't have tobe reeb debated or re litigated, um,
week after week, month after month.
That one is really particularly well tunedfor folks working asynchronously, right?
You can review thosethings on your own time.
Uh, help recap that and,and leave that decision.
Long comment, uh, in track or GitHub.
Uh, it can also be things like consensusbuilding, so nudging conversations
along and slack and GitHub thatotherwise may have stalled out.
Um, and it's also making sureto celebrate things, right?
Take thanking contributors inpublic, um, which is also what helps
keep some volunteers motivated.
Uh, and this is reallynot a WordPress thing.
It's not unique to our software project.
Uh, the Apache project, uh, calls it theproject management committee, and that
helps steward, uh, their community health,uh, Kubernetes, formalizes it with release
leads and shadows, uh, of those leads,uh, and whatever different teams call it.
Um, at Apache Kubernetes and WordPressGlue work is really, you know, I recognize
as a leadership skill that healthyopen source projects, uh, put in place.
So a bit more practicallyspeaking, what are some of these
things that I'm talking about?
So, GitHub projects and issuesthat have clear label labels
are really indispensable, right?
Those are things that a PM can stepin and, and help identify, help
track things across a project board.
Um.
Things that engineers might not feelare helpful, but when you're trying to
track the status of things, know what'smaybe becoming urgent as a beta RC or
final release timeline is coming up.
Um, labels like things like needsdecision or a punt candidate, um, help
inform weekly release lead meetings.
Make blogs, somake.wordpress.org/something, right?
Slash core slash ai slashdesign, uh, et cetera.
All those blogs and Slackhelp keep communication
public and searchable, right?
Trying to make sure that, that allthe discussions are transparent,
um, ideally not in, um, uh,dms or non-private channels.
And if you find yourself in a conversationthat's not in a public channel.
Um, or otherwise easilysearchable by others.
Then it helps to, to document thosediscussion points, any decisions that
were made, and publishing that back toa related track ticket, a related GitHub
issue, uh, or to a, to a make post canbe immensely helpful to, to, again, make
sure that that's public and searchable.
Things that, you know, maybe anengineer might gloss over, but really
for folks that are trying to managea project, manage a release, need
to make sure that that informationis, is documented and shared.
Uh, decision logs help reduce, um,having to repeat those discussions
like I was talking about, um,discussions or arguments sometimes
as as comment, uh, flame wars happen.
Uh, but summarizing those can ensure thatagain, we don't have to repeat those over
and over, and that there's, uh, a logof, of the current status of an issue.
Scope gates are really likea go no go checkpoint, right?
To find if a feature is ready for betarelease, uh, beta or release candidate.
So this past week, uh, or sorry,this coming Tuesday, WordPress
six nine has the beta one release.
Uh, the Gutenberg plugin, um, has tobasically ship a release ahead of that so
that there's a version of Gutenberg thatlands in WordPress six nine beta, uh,
that was supposed to happen this Tuesday.
It's gonna happen tomorrow.
Um, and so block commenting nowknown as notes that's coming in
WordPress six nine last week and thisweek, uh, we were basically having
daily go no go checkpoints, right?
Like, what is a blocker on this block?
Commenting also now known as notesfeature, um, and being able to run those,
identify what is truly critical, anddriving engineers, designers, testers,
whoever on those things, uh, aheadof that, um, you know, scope gate or
Go No go Checkpoint, uh, is helpful.
All right.
Things that PMs might be doing in,in projects, uh, for clients anyway.
Um, checklists for dev notes and docs,uh, can help ensure that nothing slips
there that we're, uh, getting, uh, devdeveloper notes out for major features,
uh, in a release documenting new things,whether that's user documentation
again, or developer documentation.
Uh, and the release lead dutieseven call that out explicitly.
Uh, in the core handbook, right?
Posting agendas, running weekly chatsand publishing dev notes, um, those
are all things that PMs, I think, areequipped to help contribute with, and it
doesn't need to be handled by engineers.
Um, if you see those orother sorts of opportunities,
then, then take those, right?
Find the small ways to helpcontribute, start small and help move.
The WordPress project forward or any otheropen source ones you may be, uh, familiar
with, um, but also burnout is real,like something that Nadia egg ball put.
Well, maintainers simply don'thave the energy to onboard every
person who shows passing interest.
That's why a shared load.
And some men, mentorshipof, of new people matters.
Non code work, unfortunatelycan be in, in invisible.
So, but don't be disheartened ifyour efforts aren't immediately
recognized or credited.
Do know that others who are contributing?
See that and see that you're helpingin time, just like an engineer
contributing to multiple track tickets.
You'll be noticed, you'll be credited,uh, and continue on your path towards
an experienced open source contributor.
Since we're a global project,time zones delay feedback.
A lack of synchronous overlapcan also make conversations and
get into a decision difficult.
Thus, a continued concerted effortwhen contributing will be necessary.
Acknowledging that things will likely goslow, will help ensure that you're not
setting the bar too high and expectationsfor others responding or contributing.
Um, but leaning into that and, and,uh, planning to work asynchronously,
you know, when it works best for you.
Maybe the best way to adaptto those difficulties of
contributing across time zones.
Um, one of my favoritetakeaways, um, from Carl Fogel's
producing open source software.
And while not a direct quote verbatim isstill a general sense, that's come up in
a WordPress book club that I've been inwith Aaron J, um, that he hosted recently.
But if it's not writtendown, it didn't happen.
Right?
That's why documentation and clarityare lifelines for distributed teams.
So.
How do you move from acontributor to a leader?
Step one, start small, right?
We're not, you know, it's that old,uh, adage, how do you eat an elephant?
One bite at a time, right?
Write meeting notes to helpsummarize, um, conversations.
Run a triage session or a bug scrub, helpcapture discussion topics or post agendas.
Um, those are visible, those are valuable,and they're low risk rate, low risk ways,
uh, to gain experience and build trust.
Step two own a lane.
So maybe you coordinate documentationefforts or manage the dev note spreadsheet
of what needs to be published during amajor release cycle or shepherd release
notes for Gutenberg or another canonicalplugin like the performance lab plugin.
The Docs team even has explicitdescriptions for release responsibilities
that provide good entry points fornewer non-engineering contributors.
Step three, and it's not exactly thatsimple, but logistically speaking
from that point on, you've shownthat you can facilitate, you can
help coordinate an entire release.
Kubernetes, like I mentioned earlier,has a formal lead and shadow model
that helps train the next generationof contributors and works nicely as
a repeatable pattern and process.
WordPress has done this, uh, occasionallyin the past with having, uh, cohorts
in release squads or having actualpeople shadow release leads, but we
could probably use a bit more structurein doing that on a more regular basis.
But that all happens and that allstarts by somebody stepping up.
Uh, and there's no reason that couldn't besomebody in this room or watching online.
So here's a condensed playbook.
A little bit more words for me than onthe screen, but seven habits you can
take away and start using immediately.
And notice how practical these are.
Agendas, decision logs,labels, crediting people.
None of those again, require code.
I sound like a broken record, but Iwant to drive the point home that it's
really not imperative to be an engineer.
PMs, designers, you know, uh, techwriters, all of us can contribute.
Um, and all of those things helpscale to release related processes.
So you can reach out to the core team tohelp write an agenda post for when there's
a core dev chat that happens every week.
Uh, you can leverage theprior weeks as an example.
Uh, you can learn on the lean on thecore team reps, um, who can help point
you where to capture agenda items andreview the post before publishing.
You know, a very simple thing to do.
Something that you cando on a repeated level.
It helps the core team reps, ithelps those that are leading the
release and it's a good entry pointto, uh, at least the core team.
Uh, you could find an interesting,an enhancement or bug ticket with.
A lot of comments on it.
Review those, synthesize it and publisha comment that summarizes that at the
end of the current state, uh, thathelps people that are trying to work
on a patch or a PR for a ticket ora GitHub issue that they don't have
to go through and do that, right?
You taking the time, alleviates itfor them or others that are coming
onto that, that ticket or issue later.
Um, reviewing issues in a releasemilestone, whether that's Gutenberg
or WordPress core, to make sure thatthings that keywords like has patch or
needs patch, meaning, uh, an engineerhas contributed something, or we still
need something to be contributed.
Uh, something like needs testing, right?
That the, the patch has been submitted,but it has, we don't have proof that
it solves the problem or achievesthe goal of the issue, um, to make
sure that those things are accurateto the current state of the ticket.
Um.
You can review issues that havethe closed keyword on it, um, which
generally means things that, for onereason or another isn't something that
the project's gonna take action on.
Maybe it's actually invalid.
It's not an issue, not a bug,uh, or it's a feature that just
does not belong in the project.
Um, you can review those tickets to, tovalidate that it does seem best to close
it out and leave a comment and approval,or perhaps otherwise leaving a comment.
Uh, as an alternative, there arepeople in the triage team that when
they see, uh, people commenting on aclosed ticket that they concur that
it could be closed, generally ends up,uh, getting those closed and helping
to whittle down the number of, uh,tickets and track or issues in GitHub.
Uh, we'll be very thanked by thosethat are, are working in those queues.
Um, and while you may need to reachout to folks via Slack dms or outside
of public channels, track and GitHub,again, try to ensure that the you
work towards contributing in theopen where necessary, at least work.
Again, to document those discussions,document the problems in any decisions
in a public location afterwards.
Uh, and again, ensure that folkscontributing to efforts you work
on, receive credit for their work.
You'd want this highlighted for yourself.
So do the same for others.
If somebody, uh, opened a ticketwith a lot of good information,
if somebody helped test it, ifsomebody helped validate that, uh,
a PR worked or didn't work, right?
All those should be folks thatin the end get credit for that.
Um, and as you work across the project,leave good notes as you go, right?
Continually update documentation toensure that others that come behind you
have a slightly easier path than you did.
So my challenge to those heretoday or again watching online,
is to pick one of these habits.
Try it next week.
Maybe not on WordPress core,not with the Gutenberg team, but
try it within your team, right?
If WordPress core, if Gutenberg isn'tpart of your day job, there are other
places we can try these things out.
Uh, that's how you can start to kindof build that muscle memory and, and
confidence that you can do these thenwithin WordPress core or Gutenberg.
And so to, to wrap things up againhere, leadership and open source
is not just about committing code.
It's also about that glue workthat I've been talking about that
makes those commits possible.
And releases depend on people who cancoordinate, communicate, and can unblock,
uh, others working on the project.
And if you're a project manager, ifyou're a product thinker, if you're
a designer or just someone wholikes to make things happen, there's
a role for you within WordPress.
Press
so my ass today.
Pick a lane and show up.
Post an agenda.
Join a triage call.
Join a bug scrub.
Take meeting notes.
Those are all relatively straightforwardtasks that are good places to help
you grow into leadership and showand help show that you can help ship
WordPress without shipping code.
So rather brief talk.
Got that in pretty quickly.
Thanks for listening.
Um, and here's to getting more, developnon-developers active within the project.
Please feel free to reach out,out, out to me after this, um,
here today or virtually later on.
You can reach me via email at fueled,uh, jeff.Paul@fuel.com, as well as on
WordPress Slack at Jeff Paul and on BlueSky, or on my website as jeff paul.com.
Uh, thank you and we'llopen up for questions now.
Thanks.
She's got a microphone.
She'll just hang tight.
She's
wanted to do this all day.
So Jeff, um, you talkedabout triaging and, and.
You, you work in a bit of alarger team of more people.
Think about, in a typicalproject for my company will
have a designer, developer Yep.
And a project manager.
So could you gimme some ideas ofhow you're, how we, how, uh, I might
consider triaging better and mycompany to make sure that we can, we
can manage and solve or, or do things.
Sure.
I mean that, I don't know what projectmanagement tool you use or whether
you're, you know, developing sites orapps or building a WordPress plugin,
but conceptually there's probably somebacklog of work that, uh, you know, may
be well-defined, may not be well-defined.
Uh, I think generally.
Uh, the approach that has workedwell for me is, is a Kanban nature.
So the things that, you know, tobe nearer term, make sure those
things are well enough defined sothat a designer or an engineer could
pick up and, and work on it, right?
Make sure it's actionable,uh, well-defined.
Um, if it's a bug, if it's an enhancement,um, uh, you know, if it needs, if it
needs design or if it needs engineering.
Those sorts of labeling,if it's in your, uh.
Uh, project management tool,uh, again, whatever that may be.
Um, those sorts of things can helpensure that things that are defined in
whatever your backlog happens to be.
Again, in the project that would be,uh, tracker GitHub, that somebody that
is an engineer or that is a designerthat wants to jump in and pick something
up, but they can easily find thosebecause it's labeled as an enhancement
or it's labeled as needs design.
Um, and that the actual issueitself is, is well enough to
find and actionable for them.
I don't know if that's.
What you were getting at or, um,if there's a, a follow up on that,
that, that, that's, that's helpful.
Okay.
From, uh, more technical perspective,what are the tools, especially for the
WordPress project, you would say thatlike project managers should kind of
sink into a little bit and understanda little better and being able to
contribute effectively to workplace.
Sure.
I, I think, um.
You know, if you're gonna workon meeting summaries, it's
being comfortable in Slack.
If you don't use that as a, as atool, 'cause that is where most
of the teams have their, theirweekly or biweekly chats, right?
It's an actual Slack based chat.
So being comfortable there,um, being able to, you.
Scroll back to the beginning of themeeting and then con, you know, concisely
summarize what's, what's been been said.
They're now AI tools that helpwith that much more sufficiently
than there were in the past.
So I'm jealous of folks that, um, maybedon't have to physically slog through it.
But being comfortable in Slack,uh, track is, uh, what, uh, is the
ticket backlog for WordPress core.
It is not a modern tool.
Um, it dates back probablydecades at this point, perhaps.
Um, so the, the UI itselfis a little arcane.
Um, but getting in there, beingcomfortable with being able to, uh,
use some of the prebuilt reports that,uh, you know, are issues that are in
the current milestones of the, therelease we're working on, whether
that is 6.9, uh, or perhaps next6.9 0.1 if there's a minor release.
Um, being comfortable in track.
Uh, if you're contributing toGit, uh, sorry to Gutenberg,
uh, that'll be in GitHub.
So having some familiarity with,uh, issues and, and pull requests.
Um, those are probably themost common, uh, tools.
And then if you are publishing a summaryor, uh, an agenda for a team meeting
that's on the makes, uh, make blogs,those are all individual WordPress sites.
Um, hopefully many people hereare comfortable with that.
If, if not, um.
Glad that you're here.
Let's get you comfortable withWordPress and then we'll get you
into, um, communicating on make blogs.
Um, you got one in the front,
so I assume you're doing this on the sidein addition to what you do in company.
In the past it has been additional.
Part of my current job is actuallyto contribute to community
owned open source, so I am afortunately sponsored contributor.
Okay.
Um, but uh, before the role I'm in,it had been additional impersonal
time, nights, weekends, or perhaps,uh, during the day, and then having
to shift day work to some other time.
So yeah.
Part of my follow up was gonnabe how do you dedicate your time
doing this plus that kind of thing.
Yeah.
I mean, that's where fortunatelysomething like, uh, writing an
agenda or even the summary are thingsthat can be done asynchronously.
Um, don't take more realistically thanan an hour or two depending on, um, just
how comfortable you are synthesizinga Slack chat for a meeting summary.
Um, so, you know, I would say thelowest common denominator in terms of
effort would be about an hour or two.
Um, although it'll probablytake a couple weeks of just.
Maybe shadowing somebodyor asking some questions.
And those conversations probablyhappen during, you know,
business working hours perhaps.
Um, but the, uh, drafting a amake post could be certainly
on the night or the weekends.
Um, generally folks preferto have the agenda published
before, before the meeting.
So usually early in the week, thesummary, if it's the same day, great.
If it's later in the week,it's, it's not a problem.
Um, but yeah, oftentimes, uh, it may mean.
Doing some of that contributionduring your working hours and
again, needing to shift that workto some other time during the week.
And are the dev teams that are partof these contributor make groups?
Are they pretty susceptible tosomeone like us as a PM that's
saying, Hey, I wanna help.
Where can I help?
Yes.
I, I would say, um, backwhen I started, uh, it was.
Um, it was a little hard at first to findout from Helen and Aaron how I could help
them as a pm and, and they were engineers,they were committers to, to core, uh, and
I think they were kind of just so busy.
It was hard for them to even,you know, say the words of,
I need help with this thing.
Um, and so for like, I, when it started,I was just observing and seeing the
things that they were doing, and Iwas like, oh, I can run a meeting.
I can, I can take notes.
That's.
Fairly simple and that doesn'ttake an engineer to do.
Um, and I think once I started takingthat off their plate, they were like, oh
dove, of course I don't need to do that.
And thank you for doing that'cause I hate that work.
Right?
And I'm like, I understand it.
It's not the most glamorous, but likeI can do that and now I'm helping.
And, you know, that feelsgood to, to contribute.
Um.
Uh, I'm trying to rememberwhat I was thinking there.
Oh.
And so I think if you reached out to,uh, the core team reps, if you reach,
reached out to, uh, in a releaselead channel to say, Hey, I'm a,
you know, I'm a pm, I'm a a productmanager, I'm a designer, whatever.
Uh, and I'm looking to help withwriting agendas or summaries, like
they would be elated, um, becauseusually they don't have any help and it
falls to them to do all those things.
So, um, having somebody raise theirhand, um, you know, it might take.
A day to get a response.
You know, it might take a week or twoto schedule a call for them to like walk
you through, uh, the sorts of thingsthat you know, you would need to do.
Um, but absolutely I would be, Iwould be shocked and, and pretty sad
if they weren't very receptive tosomebody raising their hand for help.
And it doesn't have to be the core team.
If you're, you know, if you're passionateabout, uh, design or if you're passionate
about AI or passionate about somebody.
Thank you.
Training team docs.
There are, if you go tomake.wordpress.org, there's a list
of all the contributing teams there.
And so depending on what yourprofessional interests are or what
your personal interests are, itmight align to one of those teams.
Thank you, Courtney.
Um, and not just the core team.
Uh, I say that by default because that'sprimarily where I started, but there are
many teams on the WordPress, uh, projectthat could use PM help, um, not just core.
Perfect.
Alright.
Thank you.
Thank you all.