Call for Components Maintainers

All the BuddyPress development takes place in Trac. All the tickets, most of the feature discussions and confirmed bugs, are all managed via Trac. For better tickets management, we use milestones, components, keywords and other ways to categorize everything. So far we have 24 components:

Component Tickets Maintainer
Activity 87 @lmoffereins
Administration 17  @slaFFik
Blogs 15
BuddyPress.org Sites 26
Build/Test Tools 8 @netweb
Core 157 @boonebgorges
Emails 17 @djpaulgibbs
Extended Profile 58 @lmoffereins
Forums 6
Friends 9 @henry.wright
Groups 58
I18N 10 @slaFFik
Media 13
Members 32 @espellcaste
Messages 16
Navigation 2
New User Experience 2
Performance 4
REST API 2 @espellcaste
Registration 6
Route Parser 7 @boonebgorges
Settings 4
Templates 55  @hnla
Toolbar & Notifications 22

WordPress (as well as some other OSS) uses an interesting approach where a person or a group of people are responsible for a specific component of a software project. The contributors have a specific interest in their chosen component, and enjoy or see the need to focus most of their contribution time on it.

In the long run, this helps that contributor quickly triage tickets in their preferred component, as they specialize in it and build up a knowledge advantage. The overall project benefits by faster review and prioritisation of new tickets.

I propose to implement BuddyPress component maintainers, with the hope that this will help move development even further and faster.

Some components, like Activity, Extended Profile, and Groups, need special love, as the number of tickets there is 50+. These components will benefit from having multiple component maintainers assigned to them.

Component maintainers don’t need to do anything special – just consider reviewing Trac tickets for your component, when you have a will and time to contribute to BuddyPress. You will be expected to look through all existing tickets, as well as new ones, provide feedback and help the larger project prioritise bug fixes and new features.

If you have any thoughts about this, or want to volunteer to become a component maintainer – please write in comments. And remember, it’s good to have several people per component, so join in even if you see someone’s mentioned your favorite component!

#buddypress

Dev Chat Summary for November 2, 2016

BuddyPress 2.7.2

@johnjamesjacoby packaged and released BuddyPress 2.7.2 on November 4, 2016. This is a maintenance release and a recommended upgrade.

BuddyPress 2.8.0

Schedule

  • January 4, 2017 – Beta 1
  • January 18, 2017 – Release Candidate 1 (string freeze)
  • January 25, 2017 – Target release date

@slaffik, the 2.8 Release Lead whose “developer heart loves things like PHP5.3+ and changed focus in development”, would like to focus on the following:
1. Components with highest tasks number – because people care about them the most
2. Components with lowest tasks number – because they are good candidates to become 0-tasks, which is cool for Trac health
3. Working UI for developer features started development in 2.6 and 2.7
4. Security – He will dive into this topic as he developed a huge interest recently and will do an audit.

His ultimate goal is to decrease the number of tickets (650+) in Trac by 50%. Responding to @boonebgorges‘ question how he planned to meet that goal aside from own labor, @slaffik wrote that he is looking into implementing the concept of BP Component Maintainers which @offereins volunteered to set up a few months ago at Google Docs.

@djpaulgibbs cautioned, “I’m not sure most of the tickets in the Future Release milestone have been looked at in a long time, and I bet most of them are not assigned to the best Component (many probably pre-date the current lists of Components) so maybe we want to review them all first.”

@slaffik also would like to see improvements made on BuddyPress.org and codex.buddypress.org “but first I need to install all that locally and play a bit and see how things are working.”

developer.buddypress.org
@dcavins: “I’d love to see the new documentation site @tw2113 has been working on go public.”
@tw2113: “Regarding the dev site, a lot of me wants to say let’s get it set up and manually run for now, and we can work on automation later on. Perhaps get it logged in only access at developer.buddypress.org and have everyone start doing final QA.”

Caching improvements
@boonebgorges: “I don’t have any particular pet projects in mind for 2.8, but I plan to be around to help with miscellaneous stuff. Maybe more caching improvements.”

Build tooling, Behat, wp-admin area
@djpaulgibbs: I’m planning to help iterate on the build tooling. And continue to work on a test suite around Behat, which I’ve been doing for the last 3 months, but I don’t know if it’ll get ready enough in time for 2.8 consideration. Also the wp-admin area / welcome screens, @mercime and I have discussed them a bunch in a past. There’s so much we could do there. Maybe that’s something we could look at.”

BuddyPress Types UI
@boonebgorges: @dcavins started work on admin UI for group/member type creation. I’ve started to dig into it myself, and that could be a good kickoff for improved wp-admin stuff.
@dcavins: The first-draft code so far is publicly available at https://github.com/dcavins/bp-types-ui. Once @boonebgorges has worked it over, I imagine it will move to its original repo at https://github.com/buddypress/bp-types-ui.

Accessibility
@mercime: On my end, work on improving accessibility continues. Btw, one survey participant thanked us for a11y improvements. @boonebgorges: The a11y improvements are huge – aside from being the right thing to do, they also make it easier to sell BP with confidence to organizations that are legally required to meet certain a11y standards.
@mercime: There’s lots more to do, but it can be done. The most challenging area would be the xProfile draggable fields in wp-admin, I will do that last.

BP REST-API
@boonebgorges: “I have been working with @bronsonquick to work up a kickoff for the project. It’s been slow going because of scheduling issues between the two of us. I would like to do a public kickoff in the next few weeks, even if I have to prep the documents myself. We have some ideas for a proposed outline and work plan, which we want to bring to the community for feedback.
“Phasing in support over several releases. Prioritizing certain components and prioritizing read vs read-write with an eye toward selecting a couple of projects as good first implementations (which will guide the endpoint strategy). Anyway, I’ll work on getting that initial document ready, and then I’ll work with @slaffik to schedule a meeting where we can talk about the path forward. The purpose of preparing a document is just so we have a starting point for conversation – all the decisions will be made in the open.”

BP Follow, Component Loading
@rayisme: “For 2.8, I’m keen on #7218 for the time being. There was a ticket talking about folding BP Follow into Core, which I’ve been meaning to reply to (and will), but there are a couple of technical ideas in BP Follow that conflicts with other tickets.”

2016 BuddyPress Survey for Site Builders and Developers

The survey is will be open till November 30, 2016. Some updates from those who have responded so far:

  • Six survey participants have already expressed interest in sharing how they are using BuddyPress.
  • All respondents are using PHP versions 5.3 and above.
  • One respondent appreciated accessibility improvements.

@johnjamesjacoby noted, “I like the idea of putting the survey front & center on BuddyPress.org, the same way WordPress.org does.” @mercime will prepare patch for the survey banner.

Your feedback is most welcome! https://buddypress.org/2016/11/2016-buddypress-survey-site-builders-developers/

Slack log: https://wordpress.slack.com/archives/buddypress/p1478113373000026

#7218, #dev-chat

As you might know, we…

As you might know, we recently started work on a REST API implementation for BuddyPress.

To support this, we’re going to arrange a once-per-fortnight dev chat. @bronsonquick and @modemlooper will be leading the discussion. This will be run alongside the regular dev chat for the main project, so on some days, there’ll be two chats!

There will be a BP REST API dev chat this week. Here’s the times/dates for your calendar:

  • Wednesday at 22:00 UTC.
  • Dates: Every other Wednesday, e.g. 27th January, 10th February, 24th February, and so on.