We made available today BuddyPress 2.4.0 beta 2. More details on BuddyPress.org.
Author Archives: Paul Wong-Gibbs
Tomorrow (Wed 29 July, 2015),…
Tomorrow (Wed 29 July, 2015), let’s use dev chat to set roadmap and dates for BuddyPress 2.4, and figure out what we need to do to ship the fixes in the 2.3 branch.
If you can’t make dev chat yet have feedback you’d like the team to consider, please either leave a note in our Slack channel, or comment on this post. Thanks!
As usual, BuddyPress’ dev chat…
As usual, BuddyPress’ dev chat is moving back to 19:00 UTC, thanks to DST. America switched a few weeks ago, and Europe switched yesterday). If you’re not sure what that is in your local timezone, check here. #DST
We had a discussion in…
We had a discussion in our Slack channel recently (logs here) about how we use Trac, focusing around tickets and milestones. This morning, I was inspired to think about how we use Trac, and put some suggestions forward for ideas we could consider. I’m sharing them here to start a discussion and see what everyone else thinks.
(In the following, I’m defining “milestone” as a version number, e.g. 2.2 or 2.3. “Future Release” and “Awaiting Review” are special milestones and what follows isn’t meant to apply to them.)
Problems
- Tickets are often punted from one release to the next, then to the next release, then to the next release, and so on — because no-one wants to work on them. Yet at some point, we felt they were important and are reluctant to close them.
- It’s impossible to look at a milestone report and easily understand which tickets are planned for the next release (or are realistically achieveable).
- Future Release is a graveyard where old tickets go and die, rather than a holding area for tickets yet to be assigned to the next milestone.
Ideas to fix this
Moving tickets to a milestone
If you move a ticket to a milestone, you are accepting the responsibility to get that task done for the next release.
- You must maintain an active presence on the ticket by monitoring it for new discussion or any changes, and responding promptly.
- You must keep the rest of the project up-to-date with the progress on your ticket. It’s preferred that this update is made at least every 2 weeks, in either: a dev chat meeting, a post on the bpdevel blog, or as a new comment on the ticket.
Generally, a person should not be responsible for more than 2 unfinished tickets in a milestone at any given time. Estimating time is hard, and real life is full of unexpected demands on one’s time, which are more important. 🙂
Tidy up the Future Release milestone
Let’s audit all tickets in the Future Release milestone. If a ticket has not been updated in over 1 year?, close it as “maybelater”.
Closing tickets does not mean the project will never implement the suggestions, but it will help to de-clutter our workflow and return the Future Release milestone to being a list of actionable “patchless things that are not scheduled for the next release”. I think this feels like a hard idea but is something we need to do.
We’ll need to do this on a periodic basis; maybe 2 or 3 times a year (looking for the “needs-patch” keyword).
Managing new contributions
Tickets should never be moved directly from a milestone to another (“punted”). If a ticket fails to make a release, and if we still want to implement it in a future version, then it is moved back to Future Release.
New tickets with patches (often bug fixes)
- Will be moved to the Future Release milestone, with the “has-patch” keyword.
- Remain in Future Release until the patch has been reviewed and is ready to commit (therefore being “sponsored” by the reviewer for inclusion in the next release).
New tickets without patches (often enhancement ideas)
- Remain in Awaiting Review until the idea is fully explored. It needs to be detailed enough so it is ready for a contributer to start working on.
- If the exploration takes some time, assign a new “in-review” keyword.
- Once the idea is ready and it has been decided that the project would benefit from having it included, move the ticket to Future Release with the “needs-patch” keyword.
Trac reports
Most of the existing Trac reports were copied from WP’s Trac a few years ago. My feeling is that most of them aren’t useful for us. Let’s remove them all, and build the following reports to match our workflow:
- All tickets waiting review
- All tickets in review
- Future Release tickets needing a patch
- Future Release tickets with a patch
- Tickets in the next major milestone
- Tickets in the next major milestone, grouped by Owner (i.e. the person who set the milestone).
I just want to make clear these are my own ideas which I’m sharing for discussion. Maybe nothing will come of them, but it would be nice to try something different for the 2.3 cycle.
At #WCSF, some attendees of…
At #WCSF, some attendees of the community summit/working days spent time discussing BuddyPress 2.2 and plans and ideas for the future. We’re pleased now to share our notes from our conversations, below.
(These notes are high-level summaries of our conversation, and should not be interpreted as a firm roadmap or as a promise of any functionality for any particular future release — but it should help you align your expectations with ours.)
Thanks to Rocío for help with taking notes. 🙂
Hi! BuddyPress’ dev chat has…
Hi! BuddyPress’ dev chat has been moved back to 20:00 UTC on Wednesdays, due to the magic of DST and timezones. If you’re not sure what UTC is in your local timezone, check here.
We’re going to move our…
We’re going to move our weekly dev chats to our new #buddypress Slack chat room.
What’s Slack? Why the change? Learn about WordPress’ recent Slack announcement over on make.wordpress.org, and join in! We’ll see you there. 🙂
We’re skipping today’s dev chat…
We’re skipping today’s dev chat as things are hectic for some of the team this close to WordCamp SF. Normal service should resume next week. 🙂
In just over a week,…
In just over a week, WordCamp San Francisco happens. As far as BuddyPress goes, some of the BuddyPress core team will be there, and — more importantly — a number of community contributors will be there. 🙂 We’re looking forward to catching up with everyone, old friends and new, and chatting with you about BuddyPress.
WordCamp is on Saturday (and Sunday), and the highlight of the weekend is, without doubt, our very own @boonebgorges‘ session, “Be a Volunteer, not a Martyr: a Practical Guide to Contributing“.
Sunday is split between regular presentations and a Contributor Day. If you’re planning to attend the Contributor Day, would you be interested in learning about the variety of ways that you can help contribute to BuddyPress, and getting the benefit of advice and the experience from existing contributors to help you get started? Let us know.
After the conference has wrapped up, Tuesday and Wednesday will be set aside for WordPress.org contributor team meetups — and BuddyPress will be there, too. 🙂 It’s an opportunity for some of the people from the contributor teams who normally work across the internet to talk face-to-face and enjoy working in each others’ company.
The purpose of this blog post is to invite suggestions that you would like the BuddyPress contributors to discuss while at the event. Questions that are open and prompt further discussion are best. For example, questions about a specific Trac ticket are best to keep on Trac, but open-ended questions like “what is BuddyPress planning to do with media in the future” are fun and would work really well.
So… what’s on your mind? 🙂
I just wanted to drop…
I just wanted to drop a quick note to mention that in yesterday’s dev chat, we’ve agreed that the BuddyPress #2.2 release cycle will formally start on Oct 25 2014, with the release expected on 28 Jan 2015.
This is gives us more time to explore alternative technical solutions for some of the changes that we’re hoping to include in 2.2. We’re aiming to confirm the major features of the release by around Oct 15 (just about two weeks away).
Another reason for choosing the end of October as a starting point is to coincide with WordCamp San Francisco (WCSF), which some of the BuddyPress team will be attending. Our release cycle often serendipitously syncs up with WCSF; 1.6 was released at 2012’s event, and 1.8 was released about a week before 2013’s event. If you’re also going to WCSF, we’d love to meet you and find out how you’re using BuddyPress. 🙂
More details to come in #2.2 in a couple of weeks, and we’ll be sure to make it clear how new contributors can get involved.
BP Dev Updates 