Review our release process + enrich release lead's role

[imath]

A message from @espellcaste about the fact we need to wait for a milestone to get its first stable version released to start working on next milestone made me think we should consider doing just like WordPress, see:
​https://make.wordpress.org/core/handbook/about/release-cycle/releasing-major-versions/#release-candidate

Following the first release candidate a branch for the release can be created so that early work on trunk can begin for the next release.

I also think Release leads should:

1. Decide about the release schedule.
2. Define bug/enhancement/task priorities for the milestone.

Priorities would be the things we absolutely need to include into the milestone. I believe this would help us to communicate early about what users can expect from a release.

• Create a release branch right after RC1
• Add 2 more responsibilities to Release Leads

Trac ticket: ​https://buddypress.trac.wordpress.org/ticket/9204

[espellcaste]

+++

[vapvarun]

Having release leads to set schedules and priorities will help us communicate better and meet user expectations. This will make our development process smoother and faster.
+++

[emaralive]

For the 14.0.0 release, this is fine since there isn't time to add more clarity and granularity. For the 15.0.0 release, we should add clarity and granularity, e.g., ​WordPress Release Team and Focus Leads, which would further expand upon our ​Release Leads & Deputies.

In fact we should take a look at the entire ​Core Contributor Handbook to see/determine what makes sense to adopt and then codify/document within our ​Contributor Handbook such that we reduce the ambiguities that are currently present in our process.

We should also publish (BP Team Update - buddypress.org announcement) a full release schedule for 15.0.0, e.g., similar to what WP had done with ​WordPress 6.6 Development Cycle, again in an attempt to reduce the ambiguity. The ​WordPress 6.5 Development Cycle publication is interesting from the aspect of how amendments to the various release dates were handled.

[imath]

In 13948:

Update release process & release lead's role

• Add espellcaste, vapvarun & emaralive to humans.txt.
• Update project roles using Pizza cooking ones.
• Update Credits screen to include vapvarun & emaralive in the BP Team section.

Props espellcaste, vapvarun, emaralive

Fixes #9204
Closes ​https://github.com/buddypress/buddypress/pull/323

[espellcaste]

@emaralive Can you outline in a new ticket the next steps for your suggestions?

[imath]

While packaging the RC1 release, I noticed the Build checklist needs some tiny improvements: reopening the ticket.

• 1 minor/major step was misplaced
• Initial branch/trunk switches needed updates to take in account the fact we are branching earlier (RC1).

Trac ticket: ​https://buddypress.trac.wordpress.org/ticket/9204

[emaralive]

@espellcaste,

I would open a ticket, however, I believe that I don't possess the requisite privilege(s) to do so with the Type option of "task", the only options available to me are:

• defect (bug)
• enhancement
• feature request

None of these Type options, that are available to me, seem appropriate. So, in lieu of a ticket, I can create a topic in Discussions within the bp-documentation repo since this would be related to a discussion related to documentation. I'll try to get that accomplished during the upcoming week (Week 28, 2024).

On another note (another rabbit hole, I fell into), to include @imath, I believe there is an issue with "Props" because they don't appear in User profiles for Activities. Apparently there are 2 different processes according to the WP Core Handbook - ​Contributor Attribution (“Props”), specifically:

• ​wordpress-develop commits in SVN
• ​GitHub repositories/merge commits

For SVN commits, apparently there should be a "." (period, dot) at the end of the Props row. If you take a look at comment ​#6 for this ticket you will find the Props written as:

Props espellcaste, vapvarun, emaralive

Which appears to be missing a "." (period, dot) at the end of the row. Thus, the Props row should be written as:

Props espellcaste, vapvarun, emaralive.

In each of the the profiles there should have been an entry, something similar to:

Mentioned in [13948] on BuddyPress SVN:
Update release process & release lead's role

I'm guessing BuddyPress is written as such because I have no examples other than examples from Core which substitutes "Core" for "BuddyPress".

As for the GitHub repositories/merge commits, the process is different and @vapvarun mentioned the WordPress/props-bot-action, during the last dev-chat (July 3, 2024), of which he may have alluded that there was an issue. The Props Bot is also mentioned ​here.

How the Props process should work is very unclear to me because the only mention of Props within BuddyPress documentation is found, maybe this is ironic, within the ​Building a new BuddyPress release - Preliminary tasks document item #2. The irony is that this document is part of this ticket and does not lend itself to where one might find out how to correctly address Props. Referencing the Core Handbook isn't ideal since it makes references to WordPress; meaning BuddyPress needs it's own rendition of the Props process which I alluded to in 2nd paragraph of my previous comment (comment ​#5.

Last but not least, as previously mentioned, I'm unclear as to how the Props process works or should work and I don't know if what the WordPress Core Handbook has laid out is applicable. All I know is that "Proper respect" a.k.a., Contributor Attribution (“Props”), are not given.

[imath]

In 13954:

Documentation: improve build checklist

• Put 1 minor/major step at the right place
• Update initial branch/trunk switches to take in account the fact we are branching earlier (RC1).

See #9204
Closes ​https://github.com/buddypress/buddypress/pull/327

[imath]

Thanks for your comments @emaralive

I believe I made the needed changes to you & @vapvarun Trac rights so that you can do what you need to :) Don't hesitate to ping me on Slack if that's not the case.

The important thing imho is to stay organized. This ticket is about packaging a build thanks to a checklist and Release leads role.

Thanks for your point on Props issue @emaralive I'll try to add the final point to it. But this part is probably another ticket story or as you said something we can work on into the BP Documentation GitHub repository to work on a specific page about it.

Let's move this ticket in 15.0.0 milestone to carry on discussing about the Release leads role part in #comment:10.