I’ve been reviewing how we manage trac tickets to try to improve how we manage and prioritise feature requests and suggestions. We have many great ideas in our Future Release milestone, but all too-often that’s become the place where great ideas go to die. At time of writing, the milestone contains nearly 700 tickets, and not even I know what’s good in there, or even what was once good but now redundant.
Our current workflow is: new ticket -> [Awaiting Review] -> [Under Consideration] -> [Future Release] or [Release Milestone] or closed ticket.
“Under Consideration” is where new suggestions live while we evaluate them and gather further feedback and comment. This is a relatively recent addition in the last couple of years, and it’s helped seperate tickets we haven’t looked at yet (“Awaiting Review”) to those we are looking at.
I propose we should try tweaking how we approach the “Future Release” milestone so we gain better understanding and awareness of vetted suggestions and bug reports, which in turn will help existing and new contributors find exciting tasks to work on. Et voilà!
- At the top of the pyramid, we have the two next release milestones (major and minor releases) which will work the same as they do today.
- “Up Next” is a new milestone containing important or strategic tickets that our regular contributors have expressed in working on within the next two releases.
- “Maybe Later” is a new milestone containing tickets that our regular contributors have decided that we have significant interest in working on, or are of a strategic importance, but less so than those in “Up Next”.
- “Awaiting Contributions” is a new milestone. It contains tickets that our regular contributors have decided would be valuable enhancements for BuddyPress, but which are unlikely to be worked on by those regular contributors for the forseeable future — because they are less important than those in the other milestones.
- This is pyramid-shaped on purpose. The milestones at the bottom should always contain more tickets than those at the top.
If this idea has support, we’ll have to spend alot of time reviewing the entire Future Release milestone, which is a great opportunity to close any tickets that are now irrelevant for some reason. The “Future Release” name itself would no longer be used to avoid confusion.
I would be very happy to hear your feedback on the proposed milestone changes (would they work? are they solving the right problem?).
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.
At next week’s dev chat (16th March), we can plan the dates of the 2.6 dev cycle. But before we rush headlong into 2.6 or have a kick-off discussion, let’s spend this next dev chat looking at the 29 tickets in the 2.6 milestone that have a patch attached.
Best case, we can commit those, worse case, we can identify what work each patch needs and update the contributor.
Polyglots, BuddyPress’ development branch in Glotpress has been updated with new strings for the upcoming 2.5 release (currently targeted for March 2nd, 2016). There are a quite a lot of string changes for this release, so consider this a heads-up! Our formal string freeze is targeted for next Monday 22nd.
We hugely appreciate the effort you put into making BuddyPress available across the world. Thank you very much.
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.
This Wednesday, in addition to our regular dev chat (20:00 UTC, see sidebar for details), there is a second meeting at 22:00 UTC dedicated to discussion about REST API and BuddyPress.
If you can’t make the meeting but have something you’d like to have included in the conversation, please reply to this post as a comment and we’ll make sure it’s discussed. We’ll have chat logs up soon afterwards.
Just a reminder that we’re picking up our dev chats again after the seasonal holidays. Next one is tomorrow (Wed 6th Jan). If you want to participate but not sure when/where it is, the time/location details are in the sidebar.
Hi! As usual, BuddyPress’ dev chat has been moved back to 20:00 UTC on Wednesdays, due to the magic of DST and timezones.
We recently made some additions to the Git mirrors that we provide for BuddyPress. There are three options:
- A read-only Git mirror of our development SVN (https://buddypress.svn.wordpress.org/).
- Hosted by WordPress.org, this is our most stable Git repo.
- Hashes could change in the future.
- A read-only Github mirror of our development SVN (https://buddypress.svn.wordpress.org/).
- Hashes will change in the future (to match buddypress.git.wordpress.org).
- A read-only Github mirror of our release SVN (https://plugins.svn.wordpress.org/buddypress/).
- Hashes will change in the distant future.
- This is repo is new.
As always, we’re happy to accept contributions made from either Git or SVN checkouts. For all practical purposes, the SVN and Git repositories are now equals. The majority of the core team now use a Git-SVN repo to contribute to BuddyPress.