Skip to:

More Core Committers?

  • paulhastings0


    I’ve been mulling this over the last couple of weeks in my mind.

    Remember a couple of months ago when there was quite a stir about where Andy had gone and if BP was stuck in the mud? And then after a lot of public outcry @johnjamesjacoby came to the rescue, issued several bug releases, wrote a few blog posts and empowered @boonebgorges and the BP Ninja team to fix some bugs on Remember all that?

    According to the Trac Timeline BP 1.2.6 is 3 weeks late and still has 14 tickets waiting to be fixed. And trunk is who-knows-how-far-behind the current branch?

    At it’s peak moment BP had 3 core committers: @apeatling, @johnjamesjacoby, and @mrmaz, but at this time only JJJ is truly active on a regular basis. I hope I don’t sound like I’m complaining, life comes up and we all realize that. Andy is being called by Automattic to work on non-BP related projects, the last time he logged into was almost 40 days ago. Marshall just had a newborn; he logged in 4 days ago. And John… well actually John’s been pretty much amazing. Last night I watched him commit something like… 10 Trac tickets in the middle of the night? He lives in Florida so it was like, 3am? But John is also working hard-core (excuse the pun) on the new bbPress infrastructure, so he’s got a lot of irons in the fire. I’m surprised that he hasn’t burned out.

    We all know that it’s time to get 1.2.6 out the door and trunk merged. But that’s not a task that 1 guy can do alone. Sure, we can continue submitting patches and bugs (I try to do my part by submitting errors when I find them via Jing videos and provide feedback… I’ve even tested a few patches and submitted sample code once) but at some point we just flat out need more active committers who can commit the submitted patches. Like JJJ said in a blog post, “Activity Breeds Activity”.

    Basically I think we’re looking at a project that really should have 3 or 4 core committers, but only has 1 active committer. BuddyPress has ample talent in the forums. These are the guys running support, submitting patches, and on the BP Ninja team. We know who they are: @hnla, @jeffsayre, @boonebgorges, @djpaul, and @r-a-y. Not surprisingly, all 5 of these guys have logged in within the last 24 hours.

    If we were a democratic body (sorry I can’t help it, I’m an American ;) ) I would cast my vote to give at least 2 of these guys commit access to the core. They’ve proved themselves worthy in my opinion. In the words of @Matt, OS projects like BP are meritocracies. These guys above have shown their value and their merit, so now let’s let them lead.

    And for reference sake, WP has 6 active core committers while BP only has 1. Albeit WP is a much larger project than BP… but perhaps that’s why?

    Hypothetically speaking: Who would be in favor of at least a couple more core committers?

Viewing 13 replies - 1 through 13 (of 13 total)

  • Pisanojm


    I’m for anything speeding up the process… BuddyPress is on the verge of taking off and “taking over”. I check the trac daily to see where we are in the process and help as much as I can… mainly because I NEED to get some of these seemingly basic fixes accomplished. The guys you’ve mentioned above are very SHARP, but there are time/money & commitments/constraints involved…

    I firmly believe that once the 1.2.6 patch is released the BuddyPress platform will have shaken off it “childhood” stage and be primed to be THE major contender in the field of Social Media Platforms. Once “we”/”They” knock out 1.2.6 (and fix the issues with searching the BuddyPress Site and Site Spammers) the sky is the limit and people are going to begin to look at the fledgling “ugly duckling” of WordPress as the SWAN that it is.

    BuddyPress is on the tarmac waiting to fly… it won’t be long now…

    Paul the question of core committers is a thorny issue, but your views run in tandem with my own on the subject and this aspect and many others have been thrashed out in a long winded thread in the moderators group, where I think I have tended, probably, to make myself a little unpopular as I will keep re-iterating what I see as major issues in order that they don’t simply get talked about a lot and then simply fade form everyone’s mind (not that I think they will but…)

    At the moment the best the core dev team and members such as yourself who do have the ability to create patches, test patches etc, can do is keep that side of things moving with vigor, I think that the more that can be patched and tested the less work for the committer/s to have to do however I acknowledge one important factor here, one of disillusionment when people jump to it do ‘stuff’ only to see it languish, unattended to; but concerns like this are uppermost in the minds of that core set of devs you reference.

    What is positive is that we do now know from the dev chat recently that Boone has the access he needs to be able to start to pull this site together – when he has dusted down his copy of ‘SVN – the Myths and Confusions unraveled’ and managed to create that local working environment? :) – What is a factor and a factor that we have to keep at the forefront of our minds is the one huge drawback with OS community projects ‘Time’ in this world we can’t expect people to drop their day to day professional work in favour of unpaid voluntary work so we have to be patient- too an extent :)

    I think, personally, getting the site running effectively is a hugely important step ; at the moment I find it a painful and off putting experience and it shouldn’t be, it’s the home of the project and needs to reflect the project in the best possible light. Also mercime has apparently been hard at work re-factoring the codex layout – as also mentioned in last dev chat – which looks impressive and I am eager to see that in place so that further documentation can be started as this is another rather weak aspect of the project at the moment.

    @pisanoim 1.2.6 will hopefully be out soon, I think though it will be 1.3 that stands as the revision that sorts a lot of the cruft out and adds enhancements that will mark a defining point for BP? We will need to get behind the patching, testing for that release to help out as much as possible as there – last time I looked – were a lot of tickets to be covered.

    I’m going to take a stab at answering this. John has been actively involved as a core developer for almost a year. The post which you refer to did not change that in any way. We all love John and the commitment that he shows to BuddyPress is without question.

    I feel the communication has improved. We’ve more posts on the .org blog about BuddyPress and its future in the last three months than we did almost all of last year. We also have the biweekly development chat which all are welcome to attend. Not to mention the variety of support and “Can I use BuddyPress for x, y and z” questions that we get on this forums, and at WordCamps. I’d like to segue briefly about WordCamps.

    WordCamps are fab! There’s a central list at, and I’d urge you to attend one if there’s one near where you are. This year’s events which covered BuddyPress:

    @boonebgorges presented at WordCamp Boston (slides).
    @johnjamesjacoby organised or presented or both at WordCamp Miami.
    I presented at WordCamp Ireland (slides) and twice at WordCamp UK (slides).
    @matt mentioned and answered several BuddyPress questions during his keynote at WordCamp San Francisco.
    Henrik Hammer Berthelsen presented at WordCamp Denmark.
    Esteban Garcia Bianchi and Juan Manuel Olivares presented at WordCamp Argentina.
    Paolo Maffei presented at WordCamp Milan.
    Jimmy Ngu presented at WordCamp Malaysia
    @lisasabinwilson presented at WordCamp Raleigh.
    Mitsuhiro Suwa presented at WordCamp Japan.
    @danmilward presented at WordCamp Chicago. @wpmuguru did, too!
    Annie Vranizan presented at Reno Tahoe WordCamp.
    @lisasabinwilson presented again at WordCamp Boulder.
    @gigalinux presented at WordCamp Berlin.
    Robert Popovic presented at WordCamp NZ.
    @johnjamesjacoby is presenting again this weekend at WordCamp Savannah.

    There are BuddyPress talks scheduled for more WordCamps this year (including at two different WordCamps this coming weekend); the list above is of events which have already happened. I sometimes forget how popular BuddyPress is, and putting this list together has reminded me how awesome the software and our community is. :)

    I would not hold much stock in the dates on the Trac timeline; it is a rough guide, just like the roadmap page is. Personally, I’m thankful for the extra time we have for 1.2.6; we’ve had a number of bugs fixed and enhancements reported and added to core which we only discovered after weeks’ worth of testing.
    The best way for people to contribute to BuddyPress is to reports bugs, write patches and to test and leave feedback on them. The danger of topics like this one is that they have a tendency to go around in circles, and produce lots of talk but little action.

    Roger Coathup


    I concur with most of what @paulhastings0 has to say (I was thinking the same thing just a few days ago). If only for the safety and security of the project, it needs more than one active core committer.

    Additionally, I’d like to see:

    – Someone giving clear lead & making decisions on features / future development – is that @johnjamesjacoby or @apeatling or someone else?
    – Somewhere clear on the site to make and comment on feature requests

    I’m on here everyday, an experienced BuddyPress developer, but still have to ask these questions. That they are not obvious is somewhat concerning.

    Some ‘off track’ thoughts on improving the site: 1. make the documentation / guides more obvious to find (so many support questions are asked when people haven’t read the guides – it’s not necessarily their fault). Let’s have the site lead visitors where we want them 2. tidy up all the dead / out of date information and plugins 3. don’t close threads that are still active, or at least give the originator the opportunity to confirm they’ve received a satisfactory response before closing



    @hnla It’s good to hear that yall have at least been discussing this then. Or at least it’s reassuring that I’m not totally off the wall here.

    @djpaul, Yeah, I would agree that communication has improved.

    But still, I fail to see why it would hurt to add a couple of core committers. Committers are supposed to be committed. Currently we only have 1 committed committer. Exactly why would it be a bad idea?

    I’m not trying to cause dissension here, I’m just trying to point out what may be a relatively risk-free enhancement to the community.

    John James Jacoby


    Quick thoughts from my iPad…

    For there to be more core committers, there needs for there to be more outstanding core patchers. There are a handful of great ones already, and they are noticed and recognized for their contributions. The leads are Andy and myself, and ultimately the future of the core project is decided by us. Very similar to WordPress, we keep an eye on developer plugins to look for anything that would make a good core feature.

    Feature requests are great when there are people to do create them, but the best place to talk about core development is on the trac. The forums are more for support and discussion than they are for code talk, but part of that is also because currently the forums don’t play nicely with code blocks.

    I don’t think we’re closing threads unless the discussion goes severely off topic or is no longer productive. If we are, I would agree that we shouldn’t be locking topics prematurely. Regarding the codex, anyone has the ability to modify it, so if anything is out of date anyone is free to fix it.

    I also agree that things will be easier for us and make more sense when is a website worthy of being in its own showcase. Right now it’s a basic install with lots of custom bits to help integrate plugins.

    It hurts to just add committers for the sake of having committers. Commit rights are earned through writing great core patches and showing a comprehension for the direction of the core project. There are plenty of great plugin devs that have written thousands of lines of their own code, but haven’t directly contributed to core.

    Ultimately it would be great if we had one developer per core component to focus on it’s future, but so far no one has showed initiative to want to make improvements to anything. Right now we’re in a transition period where the branch and trunk need to be merged before I think a few more people are comfortable writing giant patches, but that time will come.

    Paul hit almost every nail on the head in his reply above. It’s great that you see the need, now fill it. :)

    We only close threads in the main support groups if it is a lengthy thread which goes off-topic, if it’s a duplicate of another very recent thread or if someone posts on something like a 6+ months old post.

    Of course, individual Group admins can do what they like in their Group forums.

    Roger Coathup


    @djpaul – I saw one closed this week, that had been open just a day or so. I think you closed it. The guy was referred to another old thread, which didn’t reach a conclusion on how to solve the problem.

    I’ve also seen a user, albeit an irritating user, blocked from using the site for the ‘crime’ of arguing with a core developer. That really isn’t good practice. The user was being abusive, but not overly so; the core developer arguing with him was being equally petty though.

    Amend: apology, @djpaul it wasn’t closed by you, but it was closed and pointed to a thread that finished without a working answer



    The thread was probably closed by me because of a duplicate discussion. We don’t want multiple threads talking about the same thing. Even if there is no satisfactory conclusion, a discussion can continue from the originating thread.

    Roger Coathup


    @r-a-y – yes, it was :-) There’s a bit of follow up on my profile about it. I’m worried about the effect it has on the OP.



    Speaking of… we’re getting off-track from the thread title here.

    I agree with @djpaul that it’s great that BuddyPress is getting more attention at WordCamps and such. In fact the proposed “BuddyCamp” has really caught my eye (I might even go to that).

    Exactly what is the risk of promoting a couple of the guys here ( @hnla, @jeffsayre, @boonebgorges, @djpaul, and @r-a-y) to core committers? I mean, besides the risk of them committing bad code? I mean, I’ll accept what yall decide in the end and be happy with that, but I just want to know the reasoning behind it.


    John James Jacoby


    @rogercoathup Happy to talk privately about why I opted to block the person in question from Don’t want to air the dirty laundry but rest assured it takes quite a bit to get to that point.

    @paulhastings0 Very little ‘risk’ but you’re on the right track. IMO one of the harder things about running such a large project is deciding what belongs in the core and why. It’s something that Andy was really strict about and did a great job of training me on because I was anxious to learn and asked for feedback with every patch I submitted for more than a complete calendar year before asking if he could use more ‘official’ help. You can look back through my commit history and see a few blunders here and there, as they’re fairly easy to make when you’re bouncing between installations. Every one of the guys you mentioned (including @cnorris23 and a few others) are the top of the list of being considered for core commit access. You could say it’s the next step on the ladder for each of these guys and they all deserve the promotion fairly equally.

    If/when it comes time, it will be a hard decision to make. :)



    Ok, cool. I’m satisfied for now I suppose… just one of those things that had been stewing around in my mind for a while and wondering if I was the only one thinking it.


Viewing 13 replies - 1 through 13 (of 13 total)
  • The topic ‘More Core Committers?’ is closed to new replies.
Skip to toolbar