View in #core on Slack
@James_Nylen: !channel let’s have a core development meeting 
@Laurence has the agenda
@Laurence: Will paste it here for follow up
Agenda
• CP 1.3.0 release and features expected. Communique
• Ref: https://github.com/ClassicPress/ClassicPress/milestone/13 4
• CP Community Core action Plan. Can we commit to having at least 1 or 2 PRs a week fixed. (Testing and dev commits depending on PR weight) Discussion
• Monthly core meetings. Do we resume them as earlier agreed? Discussion.
@MattyRob: 
@Laurence: AOB if time allows. We have sloted 30 mins for this meet.
@Viktor:
@James_Nylen: AOB?
@Laurence: Good to see you Matt & Victor
@Marco_Zehe: :skin-tone-3:
@William_Patton:
@James_Nylen: Welcome everyone
@Laurence: Ignore that. it is a default item where I come from. (Any other business)
@James_Nylen: oh ok
@Laurence: James you can kick us off with the 1.3.0 plan
@James_Nylen: I have about 1 hour, maybe 1 hr 15 min, so we can extend a bit if needed
basically the plan for 1.3.0 is to get as many as possible of the outstanding PRs merged
here is a list: https://github.com/ClassicPress/ClassicPress/pulls?q=milestone%3A1.3.0-rc1+
we also have a number of bugfixes that have already been merged
@Laurence: As summary of that list, we have about
• 9 accessibility
• 1 text change.
• 8 other backports
@James_Nylen: here is another summary:
• bugfixes and a few small enhancements
• accessibility fixes from @Marco_Zehe
• (if time allows) the ability to update a plugin/theme from a zip file since that would be a good benefit for ClassicPress users, thanks to @MattyRob for this fairly complicated PR
• (shortly after the 1.3.0 release) enable migration from the latest versions of WP, this is waiting on a core change and some server-side work
also there will be a 1.3.0-rc1 release to allow people to test before auto-updates go out, I have targeted the rc1 release for May 4th but this is dependent on everything being ready by then.
@Laurence: James, are there any particular ones that are troublesome or need more help? How can we jump in?
@MattyRob: That’s an ambitious list to get through. What do you need in terms of help and support?
@James_Nylen: thanks for asking
a lot of these PRs are backports from WP
so I look to make sure the backport is done correctly, with attribution to the original WP committer. there have been some issues with this script in the past but I think that part is sorted now
then if there are merge conflicts during the backport, I look to see whether they have been resolved correctly, by comparing the final changes from the full PR against the corresponding WP changeset(s). or, I resolve them myself if the PR author wasn’t sure how to do this step.
@Marco_Zehe: Yeah the accessibility ones are and have proved themselves on WP, for example.
@James_Nylen: also, a change that “has proved itself on WP” is not necessarily enough to know that we want it in ClassicPress
there are a lot of things that can go wrong with backports, so it helps to give the PRs a clear title, explain what this is and why ClassicPress in particular should adopt it, and also explain what testing has been done on the PR and what may be left to do
@William_Patton: I am sure we want all accessibility improvements in CP but backports get more complex as ClassicPress diverges more
@James_Nylen: yes, basically that
another thing that will help as we’re getting ready for this release is for people to take a look at the open PRs that are marked as 1.3.0-rc1, and review them
@Laurence: Does this complexity come with css changes as you highlighted in one of the PRs? How can we look out for that?
@James_Nylen: lots of merge conflicts that look especially messy
that’s one way
@MattyRob: Unexpected files being changed is another way, in my experience.
@William_Patton: If the commit history also says a CP committer instead of a WP committer then it could also be a sign to pay extra attention because the code might not be 1:1 with WP changes.
@James_Nylen: if you’re not sure how to get started reviewing PRs I would suggest a couple of starting points: the ones marked with Accessibility, and the ones authored by “renovate” marked with bot
those Renovate PRs are a bit different, they are generated automatically to keep CP’s npm dependencies up to date for the build process. they come with a list of instructions to review them. most of the time they can just be merged straight away but it’s helpful to have eyes on them, if you know of the context of whatever changed in that npm package, etc.
and the Accessibility PRs need to be tested and understood using a local development install of CP.
@MattyRob: Is it useful to report self-testing? So a PR submitter (me) adding a comment about testin a PR I created? Or would it make more sense to test PRs from others?
@James_Nylen: it is definitely useful for a PR submitter to explain how they have tested the PR
extremely useful
@Laurence: I think we need to have both. If I might interject, we have a new “community tested” label.
@James_Nylen: and yes, ideally both
generally the more eyes the better
@MattyRob: And best place to record testing - PR comment or the Issue (if there is one)?
@James_Nylen: also if you are looking at something and you’re not sure, jump in here and ask
testing should be recorded directly on the PR
oh another thing that’s very useful for backports in particular is looking back through the associated WP tickets and commits, and looking for other WP commits that might be a follow-up to that change
@Viktor: What kind of testing needs to be done? On a local instance of CP?
@Laurence: Thanks Victor, after the automated testing running and manual ones, what more can be done?
Side note: Looking forward to some .gif testing reports.
@James_Nylen: yes, gif or video tests can be very useful also
screenshots are good too though
text instructions aren’t bad either
all of those tell other people looking at the PR how they can actually see and verify the changes, which can be a bit difficult to figure out from scratch
@Laurence: I think James pointed out we can always ask for help about testing in the channel. So I am going to push item number 2;
Can we commit to having at least 1 or 2 PRs a week fixed. (Testing and dev commits depending on PR weight)
@MattyRob: I presume this is for after 1.3.0 as there is a lot to test in 10 days.
@James_Nylen: in the next week and change we can do more than 1 or 2 a week
beyond that, on my end I can commit to checking in on PRs and issues once or twice a week, merging what is ready to be merged and commenting on the rest to move them forward (something I haven’t always been good about doing)
I have a lot less time for CP than I did earlier in the project, so the rest of that will be up to other people’s contributions
@MattyRob: To aid a PR commit each week can ticket labelling be widened? Thing like “needs testing” and “tested”?
@Laurence: I bring that up so we do not have to condense so many items when we have a release coming up.
Matt raises the issue of triage in that. I had slotted that in AOB.
@James_Nylen: yes, I will add those labels, and also grant you access to manage labels @MattyRob if you are open to that
@MattyRob: I’d be happy with that - thanks
@josh: sorry to butt in - speaking from my own experience, i think a detailed CONTRIBUTING.md file would help in getting started with the process in general
> on a local development installation of CP (this is basically just git clone [https://github.com/ClassicPress/ClassicPress](https://github.com/ClassicPress/ClassicPress) and pointing a web server at that folder), check out the git branch for the PR. make sure the change works as intended, try to break it, and leave a comment about what you tested.
this, for example, is super valuable information and it makes the process more approachable from the outside
@James_Nylen: https://github.com/ClassicPress/ClassicPress/blob/479b5aefddf3743bdf5a3091ac099977b7fd31da/.github/CONTRIBUTING.md
good suggestion for specific content to add there, let’s move that to an issue, or better yet a PR against that file
@Laurence: Thanks @josh We shall review the meeting notes and add if there is any missing to the link James shared above.
@josh: wow, did not know this file existed, thanks!
@James_Nylen: I am always open to suggestions for how to make contributing easier, that is one of the main reasons we are here
@Viktor: Maybe contributing.md would be a good place for that backporting tutorial video? @Laurence
@James_Nylen: Probably some wording changes we could make to this section of the main readme https://github.com/ClassicPress/ClassicPress#contributions to make it more obvious “hey you can find developer contribution instructions here”
@Laurence: Yes, @Viktor. As soon as James reviews that with the current additions mentioned above and we can store it on the CP channel.
We might need more of those as we build better documentation of the processes.
@James_Nylen: Also, I haven’t talked about this much yet, but I’ll be looking to add more people to the ClassicPress repository over the next few months. I’ll be looking for basically the things that we’ve been discussing - a record of high-quality PRs and code reviews/testing.
@Laurence: We are 40 mins in.
On the PR picking, I am of the view, we can pick an issue or PR from the milestones and have discussions in here.
@James_Nylen: agree
@Laurence: Alright one more item: Monthly meetings. These had been earlier agreed upon to boost growth. However, we all got busy. Do we continue with this mode? Or a “guerilla” tactics better?
@James_Nylen: I am open to have meetings whenever someone can volunteer to handle the scheduling (forum post and Doodle) and agenda.
I will help with public-facing announcements and show up to talk about whatever people need to know in order to help make ClassicPress better.
@Laurence: We could agree to have the monthly every 23rd of the month to pick up from this one.
Thoughts?
@James_Nylen: I think it’s probably better to do a Doodle each time.
People’s commitments and availability change (mine definitely do).
@MattyRob: In some ways a set monthly time to review issues and PRs sounds great but life gets in the way.
@Viktor: Yea, a Doodle might be better a week in advance.
@MattyRob: So perhaps a looser support system on here to raise issues for discussion with a more formal meet if needed?:man-shrugging:
@Laurence: Humans are creatures of habit. I am proposing some predictability with a mind that we shall continue having the small discussions over time.
Agreed @MattyRob if needed.
@James_Nylen: yes, I agree with all of that, but I wouldn’t be able to commit to a set date each month for meetings.
@MattyRob: Same date each month means a different day each time which might impact attendance.
Maybe try for a more formal meeting every 2-3 months or earlier as needed.
@Laurence: Last Friday of the month/A day in last week of the month? (I am just pushing my luck here)
@James_Nylen: something like that would be easier for me
I guess it’s up to whoever is volunteering to run the meetings if they want to try it that way
@Laurence: 50mins in
AOB
• Could milestones provide that much needed look forward? How can we improve the triage process?
• Enable migration from the latest versions of WP, this is waiting on a core change and some server-side work
• Is there anyone who would be willing to take on the next meet?
@MattyRob: IMO milestones would help to see what the future holds for CP for both devs and potential users.
@James_Nylen: I think regular meetings would be important to be able to plan more clearly in that sense
@MattyRob: We can then move Issues and PRs to defer work and focus attention on more imminent things.
Meeting will help focus attention and close things off too.
@James_Nylen: yes, I have some ideas there
• 1.4.0 or 1.x - improve handling of plugin “required” and “tested up to” versions, and maybe PHP version compatibility for plugins/themes also
• 2.0.0 - adjust the roadmap based on progress so far
probably best to save that for a future meeting after 1.3.0 is out though
@MattyRob: @Laurence You’ve done a great job pulling this meet together. How would you feel about doing the same again?
@James_Nylen: Yes, great job and thank you
@Laurence: Thank you. Will look out for the signs of the next and communicate with all persons.
Thanks for attending. We are an hour in.
Feel free to continue the discussion.
@James_Nylen if we can archive this on forum, I could pick a few things to add to contributor.md
@James_Nylen: alright
@Laurence: Thanks.
.
.