Howdy, folks. Today’s dev chat is on as usual, but it’ll be pretty low key. We’re currently not planning to formally kick off the 2.0 development cycle until at least next week’s dev chat (22nd), which will give our survey a little more time to cook.
If anyone’s decided to contribute to 2.0 and has a particular area or focus they’d like to look at, but would like some guidance identifying some specific ticket or any help getting started, today’ll be a good time to get that help. See you there!
A couple of weeks ago, WordCamp London happened. As is becoming increasingly common, the day after the conference was Contributor Day. In a nutshell, a Contributor Day is an opportunity for you to learn how you can make your own contribution to WordPress, in a room full of friendly and helpful people.
A small group of us got together and spent the time contributing to BuddyPress; big thanks to those who stopped by, even for a quick chat. Mad props goes to Noel Tock, haykayltduk (Anand), @karmatosed, and @hnla. We spent a long fun day working on a couple of projects and brainstorming.
We’re pretty proud to share one of these with you now. Introducing a refreshed appearance for the BuddyPress Codex: new header colour, re-designed sidebar, countless typography improvements — and be sure to scroll to the very bottom of the page!
This has inspired us to focus on making many more improvements to our websites in the year ahead, and already there’s all sorts of things happening behind the scenes to make it much easier for people to contribute in these ways. Stay tuned!
BuddyPress 1.9 beta now available!
I’ve enabled markdown on this P2, because markdown is cool.
@karmatosed and I spent a little time this morning updating the appearance of this P2 to more closely resemble buddypress.org; the blue was super old. :)
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.