Can we look at adjusting the dev chat time in a week’s time? Clocks go back this Sunday in the UK, and I believe in places in N America a week after that.
Ideally, I’d like it shifted from 19:00 UTC to 20:00 UTC, but more than happy to hear counter-proposals from others here.
How do we stop Trac’s “Future Release” milestone becoming a graveyard?
Or, what should we use the Future Release milestone for?
The issue is that we get tickets with good ideas or, in some cases, small bugs (or big bugs that we know will take several releases to resolve) that don’t fit into the current release roadmap, the ticket is moved to Future Release. These tickets almost always rot there unless a contributor does some work on a change, and we move the ticket back to into a release.
Over time, this builds up and currently we have 439 tickets in there.
Interested in any ideas because the way we’re doing it now just doesn’t scale.
Worth keeping an eye on the work happening on the WordPress dev site about standardising phpdoc markup for actions and filters:
I think they are going to post another update soon about whatever they format standardise on, but this is something BuddyPress should also try to do going forward.
For the record, BP has 2614 actions and filters:
$ grep -iR “do_action” * | wc -l
$ grep -iR “apply_filters” * | wc -l
At yesterday’s dev chat, we agreed the scope of BuddyPress 1.9. Very exciting news, and we’ll have a post up soon for people who missed the chat. If you’re super-keen, read the IRC logs.
A smaller group of contributors had a separate discussion before the dev chat. We discussed the big picture, our thoughts on how we want BuddyPress to grow in the future, and the kind of things that we think we need to do to get there. Boone summarised this well in the dev chat:
We’ve been talking about some major ways in which BP could be improved over the next couple releases. Some that were mentioned: some media/upload support; better new user experience (NUX) for the new site admin and new site user; privacy/roles/permissions.
The first two of these are things that are likely to be built as plugins, by teams that include members of the core team but will probably include others as well, and then integrated into core when and if it’s felt appropriate. Kinda like the template pack stuff.
The last stuff about privacy is quite complex, but there is already a ticket or two in Trac in the 1.9 milestone having to do with some first steps toward having more fine-grained permissions in certain aspects of BP, which’ll create the groundwork for fine-grained privacy sometime down the road.
Other topics that came up were the codex and buddypress.org, and how important those are towards making BuddyPress approachable as a developer’s toolkit, as well as aid to attracting new contributors to the project (aka selling the dream).
We don’t expect any of these things to be done by 1.9 but we imagine that work on them will be ongoing through this dev cycle and the next few as well. We’re going to write more dev posts on this blog about these possible projects, so if anyone’s interested in contributing in any way, check back here soon, or you can contact members of the core team directly.
It’s Wednesday! It’s also 14 days before feature development ends for BuddyPress 1.8, so let’s recap where we’re all at!
Wednesday updates! How’s your BuddyPress gone this week, feature leads?
Let’s try something new; each Wednesday, would people leading on a headline feature for 1.8 please publish a brief progress update to the weekly update post.
Doesn’t matter when on Wednesday, as long as it’s still Wednesday wherever you are :)
I’m hoping this will increase visibility of things that are in development, as it’s hard for someone not going to the dev chats or reading the IRC logs to find out the current status of a particular feature, and in turn help us keep 1.8 on schedule.
I’ll post mine later to kick things off!