Jane Wells: How WordPress Decisions Get Made

5 responses on “Jane Wells: How WordPress Decisions Get Made

  1. Jane Wells

    Errata: I mention Carl Hancock at WordCamp Chicago, but I was actually referring to a panel at WordCamp Raleigh (I said Chicago b/c someone at PDX was wearing the Chicago t-shirt, and Lisa interviewed me in Raleigh, so my brain took an incorrect shortcut) and it was Nathan Rice, not Carl Hancock. Sorry!


  2. faddah

    all these videos from WordCamp Portland 2010 need to have category/tags ‘WordCamp,’ ‘Portland,’ ‘PDX,’ and ‘2010.’ currently, none are searchable on this site via “portland” in the search box.


  3. Jane Wells

    The best way to see videos from a WordCamp is to click on the Event to the right of a video to see other videos from that event. We use custom taxonomies for a lot of this site, and multi-taxonomy queries are something that’s going to get better in WordPress 3.1. Also, this site has some bugs in the navigation in general. We’re hoping to make improvements to it in 2011 and kick the year off right.


  4. suvi

    Hi Jane,

    Nice Video. Finnaly I understand a bit more about the blog software that I use for the frontpage of my site.

    The wordpress development works great, so don’t change a running system.



  5. Jacob Santos

    The best way to lose some of your best contributors is to tell them to join another project to contribute.

    Your Microsoft example is not applicable. Microsoft development is closed source and walking in would never be accepted. WordPress core is open source, and if it is going to continue to be community driven, will require accepting people “walking in” and talking about features outside the plan.


    What about those that come to the meetings with a patch that is tested and ready to go? Are you including those people as well?

    You have a circular problem, because to get involved you have to contribute patches, but to get those patches in the core, you need to go to those meetings or talk to the lead developers.

    As someone who recently tried this process as it was meant to be, I’d say it is imperfect and needs to be revamped.


    “Govern the community”

    What are you talking about? Do you actually think you can tell the community what they are expected to work on? Do you expect that others will continue to contribute that fall outside the scope you have set?

    It is hard enough to get people to contribute patches with inline documentation and even more impossible to get contributors to include test cases. It is easier yes, to say, we want people to work on this feature and this feature, but you have to be accepting of people working outside that scope.


Continue the discussion