Core Contributor Handbook

Howdy! This is a rough draft of the handbook for contributing to WordPress.

Work here is still in progress. Indeed, some pages are only outlines, and there are many other topics left to explore. We hope for this guide to come together more fully during the 3.5 development cycle.

If you are a core contributor who wants to help, you can:

  • You can leave comments on any of these pages, which can be incorporated into the main text. Particularly helpful when fixing Jorbin’s typos.
  • Or, write something on your own blog and suggest we include it here.
  • Or, track down a core developer who can give you access to this site.

Random notes on things that need a lot of work:

23 thoughts on “Core Contributor Handbook”

  1. So, I fear I may be stepping on some toes / going over things already discussed / out of the bounds of the handbook, but what about some high level structuring here so as to make things more bitesize / manageable / follow potetially logical paths whilst recognising that not everyone wants to do _everything_ or indeed has all the strengths etc.

    I’ll merge this in with the stuff everyone is doing today at the end of the day – I believe as Beau said we have the auto content generator on which will simplify things.

    For example, as a starting point for discussion

    Learning about WordPress
    At home
    Documentation which leads to..
    Codex
    or, if directly working with wordswords not your thing.. WordPress.tv

    Contributing with Words
    Blog about it!
    Documentation: CODEX
    Forums !!
    Prefer real-time? #WordPress etc
    Spread the word in other ways
    attend a meetup
    organise a meetup
    share knowledge / encourage discussion in meetup group
    and before you know it, meetup group large enough, etc: WordCamp!

    Localisation, Translation etc etc
    GlotPress
    poedt
    etc

    Learning about Code
    Follow development
    TRAC!
    make.wordpress.org/core/ etc
    dev chat
    Ideas? > ideas forum, trac etc
    wp-hackers
    Other (this needs to be moved / better etc):
    make.wordpress.org/ui/
    make.wordpress.org/support/
    make.wordpress.org/themes/
    make.wordpress.org/accessibility/
    make.wordpress.org/mobile
    etc etc

    Testing!

    Betas, RCs
    beta tester plugin
    Finding a bug
    Check you’re sure: codex.wordpress.org/Reporting_Bugs#Before_You_Report_a_Bug
    Ask if still unsure:
    alpha/beta forum
    wp-testers list
    The world of Trac
    search
    file a ticket

    Contributing with Code

  2. Hi guys – am going to read through some of the manual today and come up with some thoughts/comments etc. I can’t believe how much has been added since yesterday – can see everyone was working really hard. Wish I could have been in SF but was in rainy England :(

    Anyway, at the risk of stepping on toes, I’ll add some thoughts – I hope they’re useful. If you guys discussed any of it yesterday tell me to stfu.

    First things first – the landing page is a bit confusing. Title is “Core Contributor Handbook” and underneath it says “Howdy! This is a rough draft of the handbook for contributing to WordPress.” So I’m not 100% sure if the handbook is just for core, or for more general contributions.

    My own feeling is to keep it for core (I think that’s the intention, right?) but to have a clear notice somewhere that says “Can’t Code? Check out These Other Ways to Contribute” – this could link to a list of the other handbooks (and the theme could be carried across the handbooks to direct people to the right place). Am assuming that there will be other handbooks – that would be fantastic. I can see a handbook for writing the Codex being really useful – also for all of the other contributor groups.

    So, back to the CCH: that top line can be remedied by changing it to: “”Howdy! This is a rough draft of the handbook for contributing to WordPress core.”

    Believe it or not, I tried to contribute to core a few weeks ago myself. I was chatting to @duck_ at WordCamp Edinburgh and he was saying that there is a massive list of documentation errors: http://core.trac.wordpress.org/ticket/20425 So I thought that this was something I could take a look at. Anyway, I tried to figure out what to do, but I failed, mostly because I wasn’t sure about where to get started. What I thought would be really useful for people like me, (and for people who can actually write code) was a “First Steps” Guide. An off-the-top-of-my-head sketch of how this would look was:

    1. Requirements (the level of knowledge required (with links to places where people can learn more should they not have the required level), what’s expected, any software that is needed)
    2. Essential reading (the absolute essentials that someone needs to read before contributing. Or even a bulletpointed list of the essential things that someone needs to know)
    3. Setting up your dev environment (with links to tutorials on how to set up MAMP, XAMPP etc)
    4. Setting up Subversion
    5. Creating your first patch (with a link to coding standards)
    6. Available patches (would it be possible to generate a list of things that need to be done, and tag them so they appear under different headings e.g. beginner PHP, advanced PHP, CSS, Docs, etc etc)
    7. Learn More & Getting Help (links to more things that need to be read)

    For an absolute beginner like me that would be really helpful in telling me exactly what I need to do. In fact, this sort of “First Steps” guide could be replicated across the manuals, so in each manual there is consistency

  5. I think it would be very helpful if a developer could take some time to write up some advice for new contributors on making their first code contributions. I would love to get involved, but despite being pretty familiar with PHP the whole WordPress API is daunting, and I’m not sure where to begin. Not related to the handbook, but maybe we could add a category in Trac for “beginner bugs” that us noobs can fix – the KDE project does this, and I think it’s a good idea.

  10. I came here looking for tips on how to disable WP loading the minified CSS/JS by default, without finding anything specific. This was the section I primarily looked at:

    http://make.wordpress.org/core/handbook/the-wordpress-codebase/#javascript-css

    It would seem as if almost every designer working on core CSS would need to apply this in their wp-config to have their changes show up immediately:

    define(‘SCRIPT_DEBUG’, true);

    I’m pretty sure this is mentioned somewhere else in the handbook, but given that this is something that almost every contributor will run into it might make sense to make it more prominent (and perhaps link to it directly from the section above).

    • Are there other things that a designer (or developer) should always do when they start working on patches? This could warrant a tutorial: something along the lines of “How to Set Up WordPress to Work on Core” – could include:
      a) turn on script debugging
      b) something else
      c) something else

      Is that something that would be useful?

      • I’d find this very useful. Questions like this, to be more specific:

        1. I want to work on ticket x. It has 10 diffs on it already. Where do I start?
        2. What is a diff? Is it a patch? How do I download a patch? How do I apply the patch?
        3. How can I undo a patch?
        4. How do I make my own patch?
        5. Now that I’ve made all these changes, my repo is now completely out of sync. What now?
        5. Can I manage this workflow with git?

        I think it would be really helpful to walk through that workflow — ie: coming into an ticket that’s well underway.

Leave a Reply