Without furtherado, we will go from my left to the right.
We will introduce our panelistsfor you today.
So I'll just say their names
and then we'll get themto introduce themselves one at a time.
So I have Isabel Brison. I have.
Oh no I don't.
I have Ryan Welcher.
I've got the list in the wrong order here.
I've got Sergey Biryukov,I've got Krupa Nanda.
And then right at the end, over there,we have Jonathan Desrosiers.
So one at a time.Let's introduce ourselves.
First of all, Isabel. Hi, I'm Isabel.
I am here todaybecause I have contributed
to a couple of WordPress releasesin the capacity of editor tech lead.
So shall I givea bit more detail on that, or.
It's up to you.
Go deep if you wish. What's it say?
I am a contributor to Core and Gutenberg,primarily Gutenberg.
And yeah, that's it. Pretty much.
Thank you very much.
Okay. Ryan, my name is Ryan Welcher.
I'm a developer advocate and automatic,and I was actually lucky enough to be
part of the 6.9release squad as a code triage release
lead with the amazing and talentedAki Amano, who's not here. But.
Yeah, and I've been in the WordPress space
for a long time,contributing for a long time.
But it was very coolto jump into the release squad.
Nice. Yeah.Thank you. Okay. See you again.
Yeah. Hi.
I'm Sergey I've been contributing towhat was for, I think, 20 years now.
That is also
started with
support and translationsand then moved to core.
And I've been on a release team
for a few releases as core tech lead
trying to encourage new contributors
and keep remaining contributors.
Thank you.
Okay. And Krupa.
Hello.
I'm Krupa Nanda and I'm contributingto test and accessibility team, and I
had an opportunity to serve as a testlead for WordPress 6.8 in 9 release.
And happy to answerif any one of you have any questions
regarding the release processesand testing related stuff.
Thank you.
Thank you. And right the end, Jonathan.
Last but not least,I am Jonathan Desrosiers.
I've served on release squads in the pastas a core tech
lead and also a release coordinator role.
But I also do a lot of workwith project leadership
to make sure that we have the right peopleon each release squad
to help the featuresthat were targeting get
seen through to the to the final releasein a quality state. So
okay, there we go.
So there is our panelists.
Round of applausefor our panelists, please.
Thank you very much.
As I said, if you have a question,we'll do the pre-written questions first
and then we'll go to the openfloor format.
If you've got a question,just make it really obvious.
Stand up, wave your hands in the air,something along those lines.
It's going to bea little bit of interrupting.
You know, I'm going to ask questionsand whoever wishes to take
it can get involved and what have you.
So let's begin.
We're almost at the point of releasingWordPress 7
that that'sthat's very much around the corner.
And so the first questionI guess for everybody, but maybe,
maybe we'll give this to Jonathan.
First is can you just tell us a little bitabout what's involved in a release?
Yeah.
So each release is different right.
There's different featuresand things that different needs
that we're trying to meetwith each release
to make sure users have the toolsthey need to be successful.
And things are stable,things are performant.
And so when we first gointo planning a release,
the first thing we'll do is take inventoryon the work that's happening.
So what features are the individualteams working on?
How do they relate to the project'spriorities?
How do they fall into the various phasesof the Gutenberg roadmap?
And we decide what realisticallyhas a chance of being ready.
And so based off of that,we have a better understanding of the work
that's needed.
And we can start to look at, you know,who are the right people
to help make those things happen. And
it takes different shapes.
Each release takes different shapesin the form of the release squad.
Right?
So some squads have certain rolesand others don't.
And we're constantly tryingto improve that and find a good balance
release to release around
encouraging the individual contributorgroups to work
independently of the releaseso that the work just continues
without an actual squadbeing named for that really sets upcoming,
and also making sure that it happensin a coordinated way,
where all the teams are aware ofwhat's happening,
how the different parts fit together.
And so those are the real thingsthat are kind of considered that dictate
what a release squad isand how it's formed for a given release.
Okay, great.
Thank you.
Jonathan,does anybody else want to jump in
and anythingthat Jonathan may have missed out.
We all know it's a perfect answer.
No notes right. Okay.
In which case I have a slightfollow up question,
which I know Jonathan has been very busy
trying to figure out the answer to the upcoming 7.0 release.
My question was how many people thus farhave been involved in that release?
And I know you were tryingto find out the answer to that.
Do we have a number?
I do, I have a very rough number.
There's still some normalizationthat needs to happen
to make sure that we don't haveduplicate people with different cases.
And we also have a few other areasthat we manually collate the props from.
And but right now we're at about 108- 175 contributors to 7.0.
So who's who here ishas contributed to 7.0 so far.
That's a lot.
All right. That's a lot.
But there's a lot of people in here.
So our last record lasttwo releases have barely got over 900.
So I think if everybody in this roomwe can, you know, tests or contributes
in some way to the upcoming release, then,you know,
we could blow that out of the water,I think.
Yeah, there must be a coupleof hundred people in this room.
And so the next question, I suppose,is we're sort of preaching to the choir
a little bit here, but the question is,how can one become involved in a release?
And I know that you all know this,but there are
maybe some people tuningin watching this live on YouTube.
So how do we come involved?
The question basically to everybody,
but I think maybe I'll send this towardsRyan and Isabel at the beginning.
And are there any blockers to involvement?
Is there anything which might prevent onefrom becoming a contributor to a release?
It depends.
You mean a contributor
to a release, as insome of your work goes into that release?
Because that's anythingpretty much from creating
an issue testing,
helping test a pull request,doing a pull request,
anything that ends up inthe release is a contribution
to that release,and you'll be recognized for that.
So so any sort of small piece of workthat you do to help push a feature
that's going out in the release forward,well, is is a legitimate contribution.
Other than that, in orderto get involved with the release squad,
that takes a bit more experience with.
So probably the best thing to do isto start contributing to WordPress first
and then later on get involvedin the actual release squad.
Are there any sort of teamsor release that parts of the release
where you need a certain level,level of technical expertise?
Yeah, I'd say for them from
the editor tech lead roleand for the core tech lead role,
because this involves knowing deeplyhow the code is structured, how how
the editor code goes into the core code,because there are two separate code bases,
and all of that requiressome previous knowledge of of the code.
So for those,I guess that would be a necessary
first step would be to get back into thatknowledge right.
Understood. Yeah. Okay. So, Ryan,anything you want to develop?
No, I mean,
I think that's in orderto contribute to certain areas,
you have to have some expertisein that area.
But once you've sort of been around enoughhanging out
and maybe some of the core dev chatsand just sort of
get a sense of what's going on,the actual becoming part of the release
is, you know,there's a call for, for, for volunteers.
And you can, you can,you can raise your hand and then,
you know, you canif you've never done it before,
like when I did6.9, I'd never done it before.
So I was sort of shadowingsomeone that had already done it.
So there's there'sdefinitely a process in place to sort of
welcome and onboard new release leads,
assuming that they're sort of able
to, you know, like, you know,talk the talk with tech or whatever it is.
But there's also ones that
probably you don't needas much technical knowledge.
There's a lot of sort of managingof the release and coordinating people
and doing things like that.
So there's no real like
you don't have to be part of a secretgroup of people to get involved.
You just have to like,
kind of put in the workthe way that you would
trying to get your first propsin Core and Gutenberg and stuff like that.
So, okay. Thank you.
Anybody that's not answered that question.
Yeah, I'll just say like thatanybody can be on a release squad, but
there are someminimum things that are looked for, right.
Like you need to work well with others.
Obviously you need to be ableto coordinate multiple things at a time.
You need to have demonstratedconsistency and quality in your work.
And so those are things, though thatwe expect of every contributor, right?
If you want to be a quality contributor
and have a good impact, those are baseline things for that anyway.
So as you go through and participatein the community and whatever capacity is
you're passionate about or interested in,just know that you know, in the future.
You could also use those skillsfor other things like serving
in different roleslike on a release squad.
Okay. Thank you. Sergey.
Yeah. Go.
There are many ways to contribute.
It's not just writing code.
Basically,
when there's a call for volunteers,you could see what catches your attention.
That could be docs.
It could be testing,could be triaging tickets.
It could be contributing to code.
So there are no specific requirements.
Basically just show up.
And if you'reready to accept feedback and.
If you have some time.
Then
there's nothing stopping youfrom getting on the release squad.
Okay. Thank you.
And I think you had your hand up. Yeah.
So I just wanted to add one thingthat you can start
by small things doing contributionin terms of start by small things.
And if you're not sure like how to start,where to start, to whom to reach out
just by joining a dedicated channel ofyour interest will help you in a long run.
Because just being a passive Li,going through some conversation
that is happening overthis lake will also
that will also help you to addressthe many, many answers of your questions
without you being without you,you asking the questions.
So it's just by joining one meeting, joining the slack channel,
that is where you can just startyour contribution journey.
Thank you very much.
Okay.
Moving on, by the way,
somebody just walked up to me and saidthat we don't actually have a roving mic,
so don't stand up and wavinghands in the air unless, you know,
maybe that's your thing.
But if you do have a question we've beenasked to guide you towards the front.
There will be mics positionedtowards the front just right here,
maybe one on this sideand one on this side.
I can't see them just yet,but they'll be here at some point I guess.
So okay. We're beingwhere are we pointing?
Over there. Somewhere over there.
So they're sort of in the middle aisle.
Middle of the room.
But if you want to make your way, goand try and find a microphone.
And if you see somebody wandering around
clearly looking for a microphone,do the pointing and show them where.
Thank you.
That's great.
Okay. So moving on then.
So the next question is all about releasecandidates and beta testing
and things like that.
I'm sure that, you know, if you go toWordPress.org you can download a zip file.
It will be the finalfinished version of WordPress.
But there's this whole processwhich goes on in the background
of alpha releases and beta releasesand release candidates and all of this.
Why do we do that?
Is the question, why is that important,and how much testing is involved
in taking somethingfrom alpha to beta to final release?
And I'll I'll throw this one overto Krupa first.
Okay.
So first,the testing is never going to be enough.
How much you try to test things will comebecause WordPress
is a huge ecosystemand we cannot have the surety of,
okay, this thing is doneand you will not ever get the issues.
Now the thing is,that is why we have the different phases
of the testing alpha, beta, RCand the final release
now during alpha is very limited to the,you know, committers
and we are just finalizing the featuresnow during the beta phase,
we are actually trying to understand the
the exploration part,like how this x, y, z feature
or the enhancementor the improvements is actually working.
We are trying to findthe issues around it.
We are trying to understandthe different age cases, the criticality
of these specific features,and we want that things to come
so that we can address itbefore the RC phases.
So once we have that clarity, okay,these are the things that is, you know,
enough stableto move forward into the RC phase.
We start the RC part.
But let's say if certain things are therewhere we are not clear
or we are not confident that addingthose features will make create
some kind of the, you know, regressionor the other kind of the instability.
We will not put that to the RC
phase will, you know, try to drop it outfrom the release itself.
Now comes the RC phase.
So RCphase is where we are fixing the bugs,
which are more important to addressbecause issues
will anyways will be thereeven if you release it finally.
But here we need to identifywhich are the issues
that are impacting the real userwhich are mandatory to address.
So that is the thingthat we are addressing in RC phase.
And then we have the final releasebecause till now
we have the limited userbase is actually testing the releases.
Now we have the entire worldwho is going to test it.
Because WordPress is a community.
You, you, you will havea different varieties of the setup
configuration, hosting.
So from thereyou will get another type of the issues.
But things those are
going into the final release at the stablewhich will not affect the user.
And we have the confident that's okay.
Now this can be released.
So these are the main difference.
Like beta is more of the explorationphase and RC is more like, you know,
stable and confidential practicallythe things to be shipped in a final one.
Thank you so much.
Anybody want to take that carry on.
Yeah, I'll just say thatfrom the practical aspect of
of contributing, it's also a great wayto have demarcations in the,
the timeline to prevent scope creep.
Right.
Where it's very easy to say,
oh, one more thing or one more thing,but we have specific guidelines around
what types of changes are allowedduring these specific phases.
And it helps eliminate that because,
you know, we needto we need to release things eventually.
And it's okay to release imperfect thingsas long as we're
relatively confident in themand how they perform.
But it's justfrom a practical standpoint, it helps us
narrow our focus on that.
I'll also say that it's a great signalto everybody to test,
and as a community,we need to do a better job of that.
And so I encourage everybody here to, whether if you have a plugin
or if you just have a blog, maybeconsider running the nightly releases.
That's not for everybody.
But like I run that to make surethat things I commit
or the things that are going inare not breaking things for people
and they interact correctlywith the plugins that I use.
But maybe you starttesting on the beta phase,
or maybe you step back and developa specific process in your
if you have an agency,
your client deliverables where as partof your maintenance contracts,
you have when beta is released,we we do this updating of everything.
Make sure everything's in working order,make sure everything's compatible for you.
And so that's, you know,that's a way where you can
maybe generate a little bit of revenueor some reoccurring client work
based on a quarterly or three times a yearbasis right now.
And, you know, just also contribute
back in the form of testingto make sure things are polished.
Okay.
Thank you.
Anybody want to take that one further. No.
In which case we'll move on to this.
And I'm going to use the word punted,which is a lovely English word meaning
sort of to push things away.
And sadly, every so often a featurewhich has been kind of
we've been in discussion
about it, making it into the final releaseoccasionally a feature kinda
doesn't make it in, and I'm just wonderingwhat are the well, how is that decided?
How do we decide that such a featurecan't make it in, gets punted,
maybe at the final momentand wrapped into that question, I suppose,
is this whole thing that quitea lot of people have probably spent
quite a lot of timecontributing to that thing.
They've invested in it.
They've contributed a lot of time.
And then there's that sort of
disappointing moment where that'snot making it, maybe in the future.
So how are those decisions made?
How is that all communicated?
And I don't have a particular personthat wants to take it.
So okay. Ryan and and then Isabel I think.
So that's literally the job of the triagerelease lead is to look at everything
that's been flagged to go in and harasspeople about deadlines because like,
so the beta phase is all new features,anything that's not a new feature.
Sorry.
Anything that is proposed,new feature has to be done
and merged by the time beta ends.
So if you if if the work's not been done,it gets punted.
And it could be as simple as I don't like
you know,
lots of people have worked on it,but they just haven't
had a chance to work on itfor the past few weeks.
And so, you know, in thein the bug scrubs, you'll you'll be like,
hey, no one's worked on this.
I don't think this is going to make it.
So I think we're just going to punt itand then, you know,
and sometimes it's like,well the features there, but but it's not,
it's not,you know, we're not comfortable with it.
Maybe there's some performance orsecurity issues you know things like that.
So punting is quite common.
And what you'll see is likeyou'll have everything
from the previousrelease gets assigned to the next release.
So like that beta phase, you're goingthrough so many tickets going,
this hasn't been worked on in two years.
We're just going to punt itto the next one. Right.
And and so yeah, so it's reallya practical decision like I've not seen.
And maybe you know some of the otherpanelists have more experience here.
But I've not seen somethingthat gets punted
because we didn't like the feature.
Or it's usually it's not ready or it'swell that's that's really it.
It's not ready. Yeah.
And then and then it gets punted.
And you know, there's variationsof like point release
or full release and stuff like that.
Did you want to.
Yeah.
It's I'd say there are usuallythere are two circumstances
in which a feature gets punted.
It's eitherhasn't been developed sufficiently
so no one's been actively working on it,or there hasn't been enough
active work that the feature is finishedin time to get in to the beta stage.
Or the.
The other thing that sometimes happens is
there's a featurethat is being actively worked on.
But if we get to say a couple of weeksbefore beta and the feature
still isn't stable enough,and then a decision has to be made
from both the release leads and the peoplewho are working on the feature.
And if we realize thatwe don't have enough time
to make it stable, then it getsit just sort of gets pulled out.
Yeah. Which I think is a good thing.
Yeah, yeah.
We don't want to rush stuff.
Like I was working on the icon
block for 6.9, and it was heartbreakingthat I could not get it done in time,
but it made sensebecause I would have had to rush it.
And then anyways, so it's 7.0 now, so it'swhat's that?
It's in 7.0 now it is in 7.0.
I'm very excited about that.
So it's not really a case of like dislike.
It's a case of ready not ready.
It's really binary like meet yourdeadlines and stable or is it not stable.
Yeah. Yeah exactly.
I will say that that's another reasonwhy it's really important
that we're regular and consistentwith our releases is because
if we have a demonstrated record of,you know, releasing
right now, it's three times a year, right?
Is generally what we aim for.
No is not forever.
Usually no in most cases means we'lltry again or maybe next time right now.
And so by by deadlines in our arbitrators,one of our project philosophies
and by sticking to consistency as muchas possible, it's easier to punt things.
It's less painful
because we know there'sanother opportunity coming up really soon,
even if it gets puntedas soon as the new release is out,
it could get committed right then
and then it's available to beta testersand people using the nightlies.
And so from the project perspective,
that's that's one way to look at it aswell, is that, you know,
you show up looking
to scratch your personal itch or something
that you really need in the software,but don't get frustrated by that.
Just be consistent, show up,make sure that it's continually tested.
Add tests.
Ask what you can do to strengthenthe rationale behind
what you're asking for.
And sometimes it just takes
a core committer with the bandwidthor the confidence in that change,
whether it's to a componentthat they maintain or whether it's
how it alignswith the priorities of the release
or the phases of Gutenbergthat I mentioned before.
Phases of the project.
Sometimes you just needto change your rationale to show
how it helps with those things,to make it more compelling to include.
So in the run up to sorry,I want to just want to do
so that sometimes the featuresor bug fixes can be funded to
the next level isbecause they have not been tested enough.
Basically,there's an infinite combination of plugins
and hosting providersthat can affect links,
and it's not always possible to accountfor all the edge cases.
So the more people test better versionsand release candidates,
and even before that, the more people testthat version, the better chance that
thingswill not get punted to the next release.
Yeah, yeah.
And also when things you get to know,the great thing about WordPress is
it's got a very flexible and extensibleplugin system.
Right.
So perhaps you just take ityou've been punted, a couple releases,
you turn it into a plugin,people install it,
they test it because they find itthrough the plugin directory instead.
Instead of looking,nobody looks for track tickets, right?
For things that they want on their sites,install and try out right?
Usually it's nothow things get discovered.
And then that also allows youto iterate more.
Then you would be able to
if it was in track or, you know, a patchthat's being worked on.
And so that could be another way
to make the case more compelling forfor your change.
Thank you.
Before I move on to the next question,I can now see some
mics and mics have appearedas if out of nowhere.
Thank you.
So if anybody does have a question,I can see you all running desperately
to queue up for the mic.
If you do have a question,please go and pop yourself near a mic.
If nobody ends up standing near a mic,we will just carry on.
But if you go and put yourself
near one of those mics, next timewe finish a question, I will ask you to.
And these people have come a very long wayto answer your questions.
So, you know, throw them a bone.
So the next questionthen you were talking about releases and,
and what have you. And I was wondering
whether you make yourselvesmore available in the few weeks.
What does your calendar looklike basically in the three four weeks
before the final release,does it basically get a lot busier?
Do you need to sort of commita lot more time in those few weeks?
I'm not going to use the word panic, butis there a sense of it's way more busy?
Anybody want to take that?
Oh yeah. Generally.
Well, depends on how involved you arewith the particular feature
that's being worked on for the release andand how many bugs pop up
related to that featurein during the beta and RC testing phases.
But yeah, generallyit does get a little bit frantic.
But that's the mostI'll go with frantic frantic.
The most frantic point is usually rightbefore beta one,
because that's the deadlinefor all feature work to be in.
After beta
one happens, no new features can be addedto the release, and then the other one
would be probably leading up to one,which is the bugfix deadline.
And so after that only fixes for that.
Specifically polish new featuresbeing added or address regressions
that were introduced duringthat release cycle are allowed after that.
And then there's some other thingsthat are always allowed,
like test improvements.
But typically there's a there's I call itthe mad dash of of those releases.
Right.
But yeah, like it dependson your capacity, what you're focusing on.
But it also dependson your supporting roles. Right.
So I mentioned earlier how we wantcontributor teams
to be self-organized and functioningwell independent of a release.
And so the goals of thatis that they can continue working
even after these deadlines.
But the representativesof the overarching work
from the various teams on the squad,if you have a great supporting cast under
you working to manage those featuresin that work,
then your job is fairly easy, right?
You're just the coordinator of a sense,and only the release
coordinator is called a coordinator.
But largely everybody on the releasesquad is a coordinator in some way.
So that'sI guess that's a good recommendation.
There is like how do we
how do we encourage our contributor teamsto take ownership in the stuff
they're working on so that the releaseteam's job gets a little bit easier?
I'll echo that with with the triage rule,
your job is more likecommenting on tickets.
Is this ready?
What are we doing here?
And a lot of times you're like,okay, this is ready.
I need a committer. Is anyone around?Like, you're, like, pinging people?
Like the number of timesI pinged you to during 6.9 was probably.
You probably just put me on muteat some point.
Right. Muted in myself. Yeah. I was like,oh this guy again.
So it's it'sthat's where it got frantic for me.
But I mean like you said like everyoneis there supporting
and everyone like no one,no one's trying to block something.
You knowif if you're like the number of times
because you and Iare like basically the same time zone.
So I was like, hey Jonathan,how about this one? How about this one?
How about this one?
And you know, it's just relying onthe whole team to to make the machine run.
Well, so and to the point of puntingis like the last topic
is that there's only so much timeduring these things.
Right.
And so sometimes it'snot even that it's not ready.
It's just it's just not time.
There's not enough time toto give it the focus that.
Yeah.
Like the only time where things were likeyou're like, oh man.
It's like we didn't have a committer
or there just wasn't somebodybecause it's the last day.
The last, like it's the 11th hour.
Like just there'sthis nobody available to commit this.
So we have towe have to punt it, which is unfortunate.
And I don't know if it happens very often,but it does.
It does happen unfortunately.
Yeah.
So I just would like to read onething is to mentioned
that it depends on the teamthat you are working with.
So for example for the test teamit is more before the
till the beta release because we aresupposed to, you know, the moment the
the release codes are announcedfrom that point to the beta release,
we need to finalize, you know,what is going to be
shipped to home to reach outif this feature is finalized.
You know, if this feature needsany more improvement, to whom to,
you know, take in the sothere is no spoon fitting is happening.
You need to collect your informationto from the different
different peopleand make it available for the user.
Because you need to test,you need to provide the documentation
on specific featurehow to test, where to test, what kind of
the environment you should be using,what should be the general checklist.
So everything should be preparedby the beta release like beta one really.
So for testers test leadit is more hectic to till the beta one.
Then we have some breathing periodto, you know,
just adjust a bit based onwhatever the changes are happening.
Okay. Thank you. Anybody else?
That's a great point,is that every decision
impactsdifferent areas of the project, right.
The polyglots team is very closelyintegrated with the work
the core team does and the changesthey make, the test team being prepared
with instructions and how things workso that people can adequately test things.
And so, you know, for people that areaspiring to be on a release squad,
I guess that's another good recommendationis to learn how the different teams
affect their work, affects other teams,because as we run out of time
and we make these frantic last minutework changes that we think are ready,
we just have to keep in mind
the way that it will impactthe other efforts
that are happeningfor the release as well.
Yeah. Thank you.
The microphone is looking very lonely.
I have to say.
Nobody'snobody's got a question for us yet.
Oh no.
No, it looks okay. No,he just walked right.
Okay.
So the next question was put in hereby Isabel.
And it's all about Gutenberg.
And so the question really is might be interesting
to have a discussionaround the recent changes to how Gutenberg
is included in core and howthis might make release workflows easier.
So it's not really a question,just more of a discussion.
Yeah.
So so Gutenberg is the code base
where the editor code livesand it's separate to the core code base.
And for context,Gutenberg is also it's a plugin
and it's used as a place to test featuresas they're being developed.
So essentiallyif you install the Gutenberg plugin,
you have access to all the featuresthat are being worked on.
They're not always super stable,so use it in production at your own risk.
But there's always some interestingnew stuff in there.
There's always highly experimental workis usually hidden behind the flag,
so it can be enabled or disabledif you prefer, more or less stability.
And when we're preparing a release,
what happens is whatever the
the state of Gutenberg is at that point,
and we do try to ensurethat it is relatively stable.
So there's nothing seriously messed upthat gets merged into the core code base.
Now, there's been a lot of adjustmentsand tweaks to how this process happens.
And we've released squads have been
always trying to work on making it easierbecause it's not.
Historically,it hasn't been a very trivial process.
But I think we're gettingwe're getting to a point
where we have a more streamlined process.
So things are starting to worka bit better.
Yeah.
But so the idea is that allthe latest features
are happening in Gutenberg, then at onepoint will get merged into core
before beta happens, and then after that
we won't get any more updates.
Well, we'll get bug fixes, obviously,but whatever
the state of Gutenberg is atthat point is what goes into core and
and then developmentwill continue in the Gutenberg code base.
And we'll continue.
Versions of the pluginwill continue being released with sort of
alpha work that in principlewill go into the next release after that.
Okay. Thank you.
Anybody else want to take that or no.
Go on.
I was just going to say that the I seewe have to make it quick.
Yeah.
I, I think the core editor teamis a fantastic example
of how we want the contributor groupsto self-organize because,
you know, we again,we have to draw a line in the sand
somewhere of what's includedin the upcoming release.
But they continue working,even though that that release is being out
in, the only certain thingsare going to be included, right?
They have their North stars,they know what features are being worked
on, and they continue to work despitethe beta and release candidate phase.
Right.
And so in the past,when I got involved with WordPress,
component maintainers was more of a,
I don't want to say impactful,but it was more of a
organizational thing
where people would organize the workaround
track tickets and what their focuseswere at given times.
I started contributing to multi-siteas one of my first components,
and we had our own roadmap,and so we would publish that.
We would work through those thingsreleased to release,
but we weren't beholden to that releasecycle structure.
And so I think that that's a great examplethere of being able to continue working
despite
knowing we're not going to get that stuffin until three months down the road.
Thank you.
We have a question.
Who is that? Luke.
Yeah. Hi, Luke. Hey, Nathan.
I'll come to your question.
I'd come to your rescuewith your very kind.
Thank you.
You may not think soafter I ask my question.
Okay.
Genuinely.
What is the role of the release lead?
And why is it that it seems likethe release lead is always
the least visible memberof the release squad?
Interesting question.
Anybody want to take that?
So I'll say that we're constantly trying
to refine what responsibilitieseach role has within the release, right?
Largely,the release lead so far has been direction
setting, final decision maker.
And when the rest of the release squaddoes their jobs effectively,
then that person doesn'tnecessarily need to be as vocal, right?
And so typically it's peoplethat are in leadership roles,
whether they're an executive directoror they're Matt or they're
Mathias lead of the Gutenberg project.
And so a lot of their communicationcomes through in the form of the phases or
whatever the priorities are for the yearat the beginning of the year.
Mary will postwhat the focuses are for the year.
Right?
So this year it's education
and I can't have top of my headremember the rest of them, right?
Meetups. So there has to be a lead.
And so the way I perceive it isthat they're doing their job well enough.
Then people know what to work on anyway,and they're there
to be a supporting person.
If, you know,
we need some type of leadershipinput from the broader project leadership.
That's kind of my role.
And I know that some people probably wishthey were more vocal at different times,
but it's also it's very nuanced.
We don't want them to pop in and deraila bunch of work all the time, right?
We we want them to be able to alloweverybody to do their work broadly
throughout the community without being toodisruptive or interrupting too often.
Okay.
Jonathan, anybody else want to take that?
Yeah, I think the release leaders.
... general rolethat isn't perhaps so much involved
in day to day work,but so that sets the vision and.
Tracks the
goals maybe, and interacts with the other
release leads like the releasecoordinator perhaps.
And to get a bigger picture of
where the project is moving.
And that's why it may seem less visiblethan the other roles.
Thank you. Anybody?
You're done.
Okay.
I'll just say like it's a it's a challengefor everybody, right?
It's very easy to fall into private silosand DM's and talk about things.
But when I'm in a DM, I always challengemyself, like,
can this bejust a public conversation? Right?
And so I think for everybody on a releasesquad
especially, it's easy to fall into thethe void of the release specific channel.
Right.
And anything that's not relatedto coordinating those, that team's efforts
should ideally be in another channelthat's more visible with more people.
Right. And so
and I
extend that challenge up to the releaseleads as well, is like,
how can we be more visible
in our communication as an open projectfor for everybody to benefit?
Thank you.
You're all my WordPress heroes.
Oh, Luke, you're too kind. Yeah.
Thank you for your benevolence.Asking a question.
Anybody else?
You've got seven minutes and 27 secondsand counting
to wander up to the microphoneand ask a second question.
Given that there's nobody there,let's press on WordPress 6.9.
There was quite an exciting moment.
It was released at state of the word
that was kind of like thisred button moment where it all happened.
It was released at simultaneousto an actual in-person event.
There was a moment when it looked likethat was going to happen here.
Where were we going to get 7.0 droppingat this event that that didn't happen.
Does anybody want to take on the questionof what happened there?
How come it didn't occur at this event?
What what punted itfor, want of a better word?
I'm going to initially point.Everybody looked at me.
Yeah I think conference going.
So I mentioneddeadlines are not arbitrary right.
Is one of our philosophies.
And that's somethingwe take very seriously.
But we also want to ship softwarethat gives our users confidence
in what we're building, what we're aimingfor, what we're trying to accomplish.
And so
part of it
is that we've been talking about testing.
Right.
And how can we get peopleto test more earlier.
And so we typically geta lot of testing at the RC phase.
People wait until that phase
because they see RC release candidatesas the most stable.
It's going to be right.
It's in the name.
That's what we're saying iswe think this is ready for a release.
And so the feedbackwe were receiving around real time
collaboration was just that.
The chosen methodof storing the associated
data was just not efficient enough,and it was not stable enough.
And so instead of plowing forward,we are just going to take a pause.
We're going to take inventoryand look at the specific issues
that we need to solve.
And mainly it's around the data storageon that and a bit of a technical thing.
But we're looking at introducinga new database table.
And that can be quite complicated.
It's not something that's donevery often, and it's also something that's
very difficult to modify in the futurebecause we can't be
we can't be confidentthat the updates to table schema
actually is successfulor that it happens on update because,
for example, on multi-site installs,that doesn't happen
until a network administratorgoes in and clicks update network.
And so it's it's much betterto take the time at the beginning,
get it right, and make sure it's stablefor everybody and how we want to use it
in the future the first time, and where
phase three is real time collaboration,this is a very high priority
because this is the bedrock of real timecollaboration in WordPress going forward.
So where do we want to go?
How does this data storage supportthat journey?
And just truly trying to step backand get it right
so that we can move forwardand not have headaches in the future?
Anybody want to follow that one up? Yeah.
What comes to mind was the taxonomic term
structure in what was 4.3, I think.
There was some structure
in how taxonomy terms are stored,and then that they should get a unique ID
and that work spend a few releases
because of when you take out for scaling.
And there are many large sitesthat don't run this database
upgrading routines immediately
after release that can be postponedand we need to account for that.
So we take extra carewhen we try to account
for this database changes.
So that's why we wanted to pause
and think how we could.
Future proof in this.
Lake. We have one question.
Oh do we.
Thank you so much.
Hello everyone. Hello.
I am from India.
So basically in every release.
We have teams like design team, test teamlead.
So I have questionsabout how to become noteworthy contributor
because I was noteworthy contributorfor three times.
Many local people ask mehow do you become.
But I don't know the exact answer.
So what is criteriato become a noteworthy contributor?
So if you can help, what is the noteworthy contributor, how
it is calculated?
So it will be helpfulfor local people as well.
Basically the
notable contributors is just peoplethat go above and beyond for a release.
So that could be taking initiativeto lead a specific feature.
It could just be being very consistent, doing something small
that's very impactful.
And those things are typically raised.
Those efforts are typically raisedby either the release team members
or the respective teams underneath the other.
The other method is just the amountof contribution that you do.
So if you
you know, you have a particularly largeamount of time that release,
and you spend a lot of timereviewing things and focusing on doing
quality work, then that shows in grabbingall the props, collecting all that.
And so typically it's around.
I think it's aroundlike 40 or more contributions per release,
but it also varies like it varies aroundwe can't list everybody, right.
So we have to cut off the list somewhere.
And so that 40 thresholdmaybe 50 for a release or it might be 30
and but generally that's around
the rough guidelines aroundhow we determine who's up there.
Right. It's I do want to get that more.
Codified right.
And more clear about thatand more transparent every release.
When we collect those props,there is a spreadsheet that gets shared,
and you can look at that
and it says next to each personwhy they're on that notable list,
and whether it'sthe number of contributions they had
or whether it'sthey helped with a specific thing.
So we're transparent in that sense,
but we're not necessarily transparentin the process of how it's collected.
Right.
I hope that answers your question.
Unfortunately, the clock here is showingthat we've got basically one minute to go,
which is probably just enoughto do that last question.
Oh, we have another mic.
We're going to have to racethrough this one, I'm afraid.
So if you could ask the question quickly,I'm sorry to I'll be I'll be very real
and quick as well,since we talk about a lot of stuff here.
Accessibility, extensive testing, multipleround of testing as well RCs as well.
There is a term which we call it as CSP
content security policy,which is very, very important
when it comes to you have any websitewhich is running live.
But I just wanted to understandthis is one of the loopholes,
as I've been seeing from last two decadesas a developer working across WordPress.
And there was a lot of thingswhich has been happening across this,
and there was no any major updateand release extensively just to have
a better CSP in place, because WordPress
is being extensively known to be used.
Any free plugins we can use,we can go to Plugin Store.
We can implement any of the plugins.
We can go to any CRM, implementany of the forms as well,
but that is somehow breaching the CSP.
If you go to any of the WordPress siteand evaluate
the CSP score, you'll get 0 to 10.
That should be 95 to 100 as well.
If I talk about sites built on next yearsand custom build sites as well,
how do you guys think thatthis can be improved in the latest
or upcoming releasesas well from WordPress itself?
Given that we're over time,
I don't know how much timewe've got left on to this question
was our time person have we gotcan we extend for a couple of minutes?
Are we okay with that?
Let's just go to the cut us off.
Thumbs up, thumbs down.
Could we go, like a minute?
Okay, we got a thumbs up. Okay.
Who wants to take that?
So I think for the CSP,I think there are some track tickets
I've seen in the past.
I'm not really up to speedon where they're at, so I would maybe
look on track and see what discussionshave happened so far around that.
Definitely not in 7.0.
That'sdefinitely something that we can do there.
But if you could find those and contributeto those and say
why it's a problem for youand how in practice
you address it, that might be helpfulto push that forward.
Yeah.
But I don't know if like it'snot something I know
that it's been considered and discussed,but I just don't know.
I don't have a good answer as far as likewhy it's not included.
I would encourage you as like,
you know a lot about it, to get involvedand open tickets and talk about
like the best ways of approaching this,because that's something
that the individual contributorsare going to be working on.
Not not necessarilythe folks on the release squad,
but this is more of like a get involved.
You know, open tickets, talk to people,
you know, bang the drum, get, get,get eyes on on your tickets.
And I think that'll.
Yeah helps.
Just thank you so much.
I'm sure these people, these finepeople will make themselves available.
So if you've got any further questions,I'm sure that they'll be here
ready to answer.So we're slightly over time.
I apologize about that.
Thank you all for showing upand contributing today.
Round of applausefrom the panel to the people in the room.
Very much indeed.
So just a quick thank you to Isabel,
to Ryan to Sergey to Krupaand to Jonathan.
And thank you for paying attentionand listening.
Really appreciate it.
Enjoy the rest of your contributor Day.
Thank you for showing up to learnhow to contribute and make WordPress.
Yeah. All right. Thank you so much.