WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: core contributor handbook Toggle Comment Threads | Keyboard Shortcuts

  • Matt Mullenweg 12:10 am on July 28, 2012 Permalink
    Tags: core contributor handbook   

    Looking for a lead 

    The Core Contributor Handbook is live here, and has a lot of great content from a number of contributors already:

    http://make.wordpress.org/core/handbook/

    What we’re looking for is someone to “own” the CCH and be responsible for:

    • Expanding and editing it, getting feedback from devs.
    • Walking people through it to get ideas on how to improve it (and get people involved with WP!).
    • Soliciting other contributors (don’t want a one-person show) and keeping an eye on all the changes.
    • Figure out a cool way to package and print the handbook.

    Let me know if you’re interested in taking on this role, a comment on this post is fine.

    This also reminds me — it would be great to be able to see a feed of changes on a site, like edits to a page. Anyone have a favorite plugin there?

     
    • dremeda 12:19 am on July 28, 2012 Permalink | Log in to Reply

      Good stuff, Matt. I would like to contribute here. Whoever ends up owning it, you have your first contributor/volunteer.

    • Ben Tremblay 1:48 am on July 28, 2012 Permalink | Log in to Reply

      Detail: that URL was not clickable in EMail. ThunderBird is pretty well behaved with that sorta thing.
      Odd it wasn’t a live link.
      Links in header and footer were just fine.

    • dllh 2:24 am on July 28, 2012 Permalink | Log in to Reply

      Can you clarify what level of involvement with the community the lead for this should have had to date? For example, I’ve gotten a few patches in here and there but don’t know that I’m sufficiently familiar with all the things to be a useful lead on something like this. Wouldn’t surprise me to learn that others who’re interested in pitching in have similar feelings. Are you hoping to land somebody who already has a solid insider view of things or are you after a fresh perspective?

      • Matt Mullenweg 2:01 pm on July 28, 2012 Permalink | Log in to Reply

        I don’t think being super-involved in core is necessary, in fact it’s probably better to have a beginners mind with regard to much of this. However you’ll want to run things by folks with more experience just to make sure you’re leading people on the right track.

    • Emil Uzelac 2:55 am on July 28, 2012 Permalink | Log in to Reply

      Good stuff indeed :)

    • Tom Auger 5:16 am on July 28, 2012 Permalink | Log in to Reply

      Boy oh boy, this is such an important piece of the WordPress puzzle! My own journey (still in its infancy) in becoming a useful contributor has been fraught with good intentions and big learning curves. If I had more experience I’d definitely volunteer to shepherd this thing into a true roadmap for the would-be contributor.

    • Mike Bijon 9:37 am on July 28, 2012 Permalink | Log in to Reply

      Hi Matt, I’d like to be considered for this position too. I’m a 1-time core contributor and have worked with the PDX WP Meetup and Codex lately. More details, http://www.mbijon.com/about-mike-bijon/. Now that I’m not a full-time developer at work, and take on a lot more planning & PMing tasks, I think I could be a lot more productive with this than I’ve been with trying to make rare, quiet coding windows.

      Also, for tracking changes to the CCH:
      Audit Trail has most of what you need, http://wordpress.org/extend/plugins/audit-trail/, but would have to be turned into a feed. Adding some open diff tools could help make it more readable, http://www.raymondhill.net/blog/?p=441, or https://github.com/austincheney/Pretty-Diff. Although what would be interesting is to build a way to deploy all content via a git or Github repo, http://drupal.org/project/content_staging (which would also solve a lot of commercial users’ Dev > Production deploy problems).

    • Japh 1:34 pm on July 28, 2012 Permalink | Log in to Reply

      Hey Matt, the Core Contributor Handbook is already an excellent resource, and I’d love to see it grow even further.

      I would also like more information about what your expectations are for this role. Specifically, how much experience with core contribution do you feel is necessary? How much time per week do you expect this role will require?

      • Matt Mullenweg 2:02 pm on July 28, 2012 Permalink | Log in to Reply

        Answered the experience question above. As for time, I would plan for 10 hours a week as a good baseline, as with any serious volunteer commitment across WordPress.

    • Siobhan 3:59 pm on July 28, 2012 Permalink | Log in to Reply

      Hi Matt – I’d love to help out with this. I was looking at it before and wondering if you needed someone to help out.

      I’m a documentation specialist (http://wordsforwp.com) and I spend a lot of time communicating with devs and translating what they say into beginner speak. I build a lot of documentation projects from the ground up, and work with a lot of developers on similar projects to this, so it’s right up my street. I’d be more than happy to get involved. My time is a little limited over the next few weeks but as of the end of August I have 10 hours per week for sure.

    • Azizur Rahman 5:22 pm on July 28, 2012 Permalink | Log in to Reply

      Hi Matt, count me in to be one of the volunteer. I don’t think I can do 10 hours at the moment to take a lead, due to my other volunteering commitment at the moment. I am happy to be supporting whoever ends up taking the lead.

    • Beau Lebens 10:59 pm on July 29, 2012 Permalink | Log in to Reply

      If anyone is planning on coming to the Dev Day for WCSF, I plan on making contributions to the CCH part of the action for the day.

    • Chris Olbekson 1:33 am on August 2, 2012 Permalink | Log in to Reply

      I would love to help where ever possible on this. I think the perfect plugin to help manage the project is Edit Flow http://wordpress.org/extend/plugins/edit-flow/. I’m not sure if it has a feed but the notifications and editorial comments will be very helpful.

    • Doug Provencio 9:27 pm on August 5, 2012 Permalink | Log in to Reply

      I added a section called Suggestions, for people to add suggestions about Missing Sections, Style and Navigations, and Sections still needing major work.

      Do we want to break off a list of which pages still need work (and who’s working on them) onto its own page?

  • Andrew Nacin 11:42 pm on September 18, 2011 Permalink
    Tags: core contributor handbook   

    Write a tutorial for setting up a local dev environment 

    A section of the core contributor handbook will be about how to set up a local test install, including a web server, Subversion, and WordPress. Because of the various operating systems and software packages out there, we’re going to need a few different tutorials.

    I need some people willing to write up procedures for a number of standard setups. This includes:

    • WordPress on XAMPP (both Windows and Mac) MAMP, and MacPorts
    • TortoiseSVN and a tutorial on command-line Subversion usage, including co, up, revert, diff; patch; conflicts, etc.
    • Whatever you Linux guys use :)

    I’d also love an article on getting the test suite up and running. Anything I’m missing?

    So, for these procedures, people can volunteer (probably for their current setup). Once steps are written, others will need to test them. Many procedures may heavily borrow from or link to outside resources (such as the vendor sites themselves) — this is fine. And, there may already be some good things in the Codex or on other sites about getting WordPress running. Again, fine. (There are SVN articles by both @westi and @markjaquith, and those are probably great to start from.) Gather links, screenshots, further reading, whatever will help.

    So, who is in?

     
  • Andrew Nacin 2:36 pm on July 1, 2011 Permalink
    Tags: core contributor handbook   

    A glossary for contributors 

    As part of the core contributor handbook, there’s going to be a glossary. Here’s what I’ve put together so far.

    Something missing? Leave a comment. Feel free to also weigh in on new and existing definitions, examples, and the like.

    a11y: Accessibility, or the act of ensuring that user interfaces are accessible for persons of all abilities and disabilities.

    back compat: Backwards compatibility — a desire to ensure that plugins and themes do not break under new releases — is a driving philosophy of WordPress. While it is a commonly accepted software development practice to break compatibility in major releases, WordPress strives to avoid this at all costs. Any backwards incompatible change is carefully considered by the entire core development team and announced, with affected plugins often contacted. It should be noted that external libraries such as jQuery do have backwards incompatible changes between major releases, which is often going to be a greater concern for developers.

    backport: A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch.
    (More …)

     
    • Ptah Dunbar 2:42 pm on July 1, 2011 Permalink | Log in to Reply

      dogfood: The practice of using one’s own software, typically bleeding edge (trunk), thus “eating one’s own dogfood.”

      This also applies to using one’s own public APIs internally too.

    • Andrew Nacin 2:43 pm on July 1, 2011 Permalink | Log in to Reply

      tag: A directory in Subversion. WordPress uses tags to store a single snapshot of a version (2.8, 2.8.1, etc.), the common convention of tags in version control systems.

      Should include: “Not to be confused with post tags” etc.

    • John Lamansky 3:06 pm on July 1, 2011 Permalink | Log in to Reply

      commit (noun): An individual change to WordPress, identified by an incremental revision number. Also called a changeset.

      It seems to me a commit connotes that a change has indeed been applied to WordPress, while a changeset can refer to potential changes, as in a proposed patch’s changeset. I don’t think the two are synonymous.

      • Peter Westwood 3:26 pm on July 1, 2011 Permalink | Log in to Reply

        a changeset can refer to potential changes, as in a proposed patch’s changeset. I don’t think the two are synonymous.

        A changeset is a specific thing in the world of Subversion – It is a set of changes which were applied to create a revision in source control.

        A patch is not a changeset IMHO

    • John Lamansky 3:07 pm on July 1, 2011 Permalink | Log in to Reply

      Here are some additional terms you might consider adding:

      AJAX
      nonce
      PHPdoc
      PO / POT / MO
      salt
      WP_DEBUG
      XMLRPC/APP
      xref

    • bentrem 3:19 pm on July 1, 2011 Permalink | Log in to Reply

      Sidebar: I just realized that notification by email / subscription includes the entire post. Which, vast majority of the time, is just fine. But …
      … maybe I’m paranoid by nature. Does “send the whole” make sense as default?

      p.s. vague memory of a working glossary from Moz, shortly after the code was released. IIRC it was never authoritative, but it was a nice slab of verbiage.

      • bentrem 3:20 pm on July 1, 2011 Permalink | Log in to Reply

        erratum – s/ “make sense as default?” [yes!] / without upper limit make sense as default?

      • Andrew Nacin 3:25 pm on July 1, 2011 Permalink | Log in to Reply

        Yes, I think it does. I consume a number of blogs through RSS and a number more through email, and the lack of full content is terribly annoying.

        • bentrem 5:56 pm on July 1, 2011 Permalink | Log in to Reply

          Agreed.
          What I pondered is that rare item that is really large. Like, say, a glossary that’s fully fleshed out. NM … #quibble.

    • Andy Skelton 3:28 pm on July 1, 2011 Permalink | Log in to Reply

      The term “a11y” is ironically inaccessible.

    • Aaron Jorbin 3:29 pm on July 1, 2011 Permalink | Log in to Reply

      Missed: maybelater (since that is a way we close tickets)

      Suggest to modify: a11y . I think we should use the language that WCAG uses and say “Accessibility or the act of ensuring a high quality experience for all WordPress users regardless of blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity and combinations of these”

      • Andrew Nacin 3:36 pm on July 1, 2011 Permalink | Log in to Reply

        I have a whole separate section for keywords, ticket types, and resolutions, though they’ll all probably be cross-listed in the glossary.

    • Ron 3:31 pm on July 1, 2011 Permalink | Log in to Reply

      include the ticket tags – has-patch, needs-testing, etc.

    • Mark Jaquith 3:31 pm on July 1, 2011 Permalink | Log in to Reply

      • Bikeshed
      • Panda Raccoon
    • Chris Hajer 3:36 pm on July 1, 2011 Permalink | Log in to Reply

      Pinking Shears? http://is.gd/PjjFU9

    • Dougal Campbell 3:46 pm on July 1, 2011 Permalink | Log in to Reply

      AJAX (mentioned already), jQuery, Dashboard, Settings/Options, API, wp.org vs. wp.com?, bbPress, BuddyPress, MultiSite, must-use plugins, drop-ins, MySQL, Roles + Capabilities, Admin/Super-Admin…

    • Andrew Nacin 3:55 pm on July 1, 2011 Permalink | Log in to Reply

      We sometimes use codenames and acronyms for incoming features. For example, DFW. Can anyone think of others?

    • andrea_r 4:04 pm on July 1, 2011 Permalink | Log in to Reply

      Can’t BELIEVE you forgot alot. Alot is now sadpants.

      Also possibly not glossary worthy but maybe a mention somewhere: that devs referece parts of WP by the function names and not what they are called in the admin area.

      Some examples:
      multisite = network
      custom permalinks = pretty permalinks (tho that’s a really easy one, I have a funny story for you)

    • Jon Cave 4:06 pm on July 1, 2011 Permalink | Log in to Reply

      HEAD

    • Curtiss Grymala 4:11 pm on July 1, 2011 Permalink | Log in to Reply

      Although you included diff in the definition for patch, you might want to give it it’s own entry that says something like:

      Refer to patch

      Might also want to define hook, callback, action, filter and API. Might not be a bad idea to give definitions of the way WordPress uses common words like priority (i.e., a “higher” priority actually means it occurs later in a process), etc.

    • Brian Layman 4:49 pm on July 1, 2011 Permalink | Log in to Reply

      Debug Mode – Inside wp-config, having define(‘WP_DEBUG’, true); which enables extra messages inside WordPress that allow you to figure out what your code is doing and reveal previously hidden issues. Related to this topic are the constants WP_DEBUG_DISPLAY and WP_DEBUG_LOG

    • Aaron Jorbin 4:49 pm on July 1, 2011 Permalink | Log in to Reply

      I Would add definitions for the release process stages (Planning meeting, Feature Freeze, Beta, RC) which I imagine you have somewhere else.

      One more worth considering:

      Nacin – A robot from the future sent back in time to ensure the survival of WordPress. Rumored to be created and programmed by Matt Mullenweg’s Great Great Great Grandson and Ryan Boren’s Great Great Great Great granddaughter.

    • Brian Layman 4:59 pm on July 1, 2011 Permalink | Log in to Reply

      I’m going back and forth on ones like:
      json, serialized, escape, prepare,transient, object cache

    • bentrem 6:02 pm on July 1, 2011 Permalink | Log in to Reply

      For reference: Master Glossary from CMSCalendar.com

    • Mario Peshev 10:10 pm on July 12, 2011 Permalink | Log in to Reply

      I would define Unicode/UTF8 as an important thing to know for collaborative work with files including source.

      Copyright and Licenses as well.

      Test-Driven development and BDD. Methodology and process (beginning to the end)

      Probably IDE, backup, refactoring, high quality code, comments, test cases…

  • Andrew Nacin 8:56 pm on August 26, 2010 Permalink
    Tags: , core contributor handbook,   

    What do core contributors need to know? 

    I’ll be working on an outline for the core contributor handbook in the coming weeks, so I figured I would start a brainstorming session here. Some potential questions to ask yourself:

    • What do core contributors need to know?
    • What would have been great to know when you first started getting involved?
    • What resources (such as pages on the Codex) have you found useful?
    • What do people (including/especially non-contributors) need to know about the development process/cycle/philosophies?
     
    • Ozh 9:05 pm on August 26, 2010 Permalink | Log in to Reply

      Adam’s http://adambrown.info/p/wp_hooks/ is pretty hot

      Emphasis could be made on the Codex, too. I started coding plugins before there was a Codex, which then was pretty empty at its beginning so I never really used it. It’s just recently that I’ve discovered it again, and found it very very useful.

      • Andrew Nacin 9:37 pm on August 26, 2010 Permalink | Log in to Reply

        This comment is arguably better for http://wpdevel.wordpress.com/2010/08/26/api-status-check/. I’ve actually reached out to Adam with regards to his hooks DB, as we hope to integrate a hooks reference as part of the API reference.

      • Brian Layman 9:52 pm on August 26, 2010 Permalink | Log in to Reply

        Unfortunately Adam’s site is causing loads of extra work now as it is still big in Google but his automated code has identified many actions and filters as removed due to fine tweaking. I see people asking about it on wp-hackers and you and I chatted about it one of the reports on it Andrew.

        • Andrew Nacin 9:53 pm on August 26, 2010 Permalink | Log in to Reply

          Indeed, which is partly why it would be helpful to have a similar automated reference that is official and more complete. (And can be properly vetted by core folks.)

    • John James Jacoby 9:07 pm on August 26, 2010 Permalink | Log in to Reply

      How to use trac the WordPress way (keywords, tags, etc…)
      What is SVN? What do checkout/update/commit really mean and who can do that and why?
      How create a diff/patch, and how to attach a diff/patch to a trac ticket.
      General blog/chat/trac etiquette and community expectations.
      WordPress coding standards is a helpful codex page.

      There are probably more, but these are my few to start.

    • zippykid 9:09 pm on August 26, 2010 Permalink | Log in to Reply

      1. just a quick reminder on how to search the archives :).
      2. history of some decisions (see #1)
      3. coding standards
      4. contributing etiquette
      5. Triage process

      • Jacob Santos 9:59 pm on August 26, 2010 Permalink | Log in to Reply

        I think #2 is a good idea. There are a few areas that are/were asked repeatedly on the wp-hackers mailing list that would be good to just link to. It wouldn’t mean it is set in stone, but it would provide some reasoning for people on where to leave off when continuing discussions.

    • Kenny Younger 9:22 pm on August 26, 2010 Permalink | Log in to Reply

      I always knew the trac mailing list was available, but it wasn’t until recently that I started subscribing to it that I started to really appreciate the workflow in trac – mainly because it’s now literally at my fingertips (email on my phone).

      I just have gmail filter it off into its own label, so it doesn’t clutter my inbox (I actually do this for all the lists). One of the huge benefits is that I can drop into that label and then very quickly see what tickets are getting heavy commenting/changes. Plus I can star items that I feel I want to pay attention to more so than others.

      Another added benefit: quick searching from my phone for a particular ticket’s history.

      • Andrew Nacin 9:39 pm on August 26, 2010 Permalink | Log in to Reply

        My current workflow is very similar to this, though long ago I spun that label off into its own inbox. Even when I’m at my computer, I often use Gmail search to find tickets.

        Talking about different ways to absorb the firehoses of information, if you are so inclined, is a good idea.

    • Jacob Santos 9:31 pm on August 26, 2010 Permalink | Log in to Reply

      Requirements for patches. Adding / Modifying inline documentation and changing existing documentation when changing requirements. Writing Unit Tests. Expectations of the time for patches to get committed. What to do when there isn’t any feedback? What to do when patches don’t meet expectations.

      What it means when someone from Automattic doesn’t like your patch and therefore doesn’t gain traction. Who’s who at Automattic and WordPress core community that might need to be looked for and debated for certain patches to get in.

      • Andrew Nacin 9:36 pm on August 26, 2010 Permalink | Log in to Reply

        s/Automattic/WordPress core team/. That said, a who’s who is important, especially given the number of committers, contributors, and those who triage.

        • Jacob Santos 9:52 pm on August 26, 2010 Permalink | Log in to Reply

          No, I mean Automattic. They have just as much power, most of the time, as core commit team with what goes into WordPress. There are people at Automattic who have certain areas of expertise and core commit team has historically relied on their opinion over that of the core contributor community members.

          It is helpful to know who these people are without having to go to automattic.com web site and checking. Partly because the name(s) on the web site do not always translate to Trac.

        • Jacob Santos 10:01 pm on August 26, 2010 Permalink | Log in to Reply

          Yes, the first Automattic should have read WordPress core team. The second should have read Automattic and WordPress core team and WordPress core community.

        • Andrew Nacin 10:02 pm on August 26, 2010 Permalink | Log in to Reply

          That works for me.

      • Andrew Nacin 9:39 pm on August 26, 2010 Permalink | Log in to Reply

        Also, I really like your thoughts on patch requirements, expectations. Thanks!

    • JohnONolan 9:35 pm on August 26, 2010 Permalink | Log in to Reply

      Probably need a mini section for designers / front end developers. We can title the section “for dummies” – as Nacin will attest to by the number of questions that I asked him in the early days :)

    • Andrew Nacin 9:35 pm on August 26, 2010 Permalink | Log in to Reply

      Random quick hits:

      • Jacob Santos 9:53 pm on August 26, 2010 Permalink | Log in to Reply

        Inline documentation is found at http://codex.wordpress.org/Inline_Documentation

      • Matt 10:34 pm on August 26, 2010 Permalink | Log in to Reply

        • Andrew Nacin 2:09 am on August 27, 2010 Permalink | Log in to Reply

          Thanks! Liking that new page a lot.

        • scribu 9:40 pm on August 27, 2010 Permalink | Log in to Reply

          Nice, but the page title reads WordPress > About > Requirements

        • filosofo 5:07 pm on August 30, 2010 Permalink | Log in to Reply

          From the Philosophy page:

          There’s a good rule of thumb within internet culture called the 1% rule. It states that “the number of people who create content on the internet represents approximately 1% (or less) of the people actually viewing that content”.

          So while we consider it really important to listen and respond to those who post feedback and voice their opinions on forums, they only represent a tiny fraction of our end users. When making decisions on how to move forward with future versions of WordPress, we look to engage more of those users who are not so vocal online. We do this by meeting and talking to users at WordCamps across the globe, [sic] this gives us a better balance of understanding and ultimately allows us to make better decisions for everyone moving forward.

          (emphasis added)

          Mathematically speaking, it’s unlikely that “we” has spent enough time chatting at WordCamps to engage more than 1% of WordPress users. The counter says 13 million downloads of 3.0 so far. Assuming one user per download, talking to 1% of them for just one minute each would take by itself a full-time job for over a year, with no time to process or organize the results. It would also mean that all the past WordCamps would have had on average a couple thousand unique attendees each.

          More importantly from a statistical perspective, those with the means, the time, and the interest to attend a WordCamp are not likely to compose a representative sample of WP users in general. Nor are they are going to speak many of the hard truths in a WC reception line.

          I’m not just being pedantic; something as fundamental as a guiding philosophy should be accurate and honest. There’s nothing wrong with saying that, when it comes to resolving contentious disputes or setting big-picture goals, the ultimate arbiter is Matt Mullenweg’s judgment, which has served him well so far in numbers of WP users and the financial success of Automattic. Mullenweg keeps his finger on the pulse of WordPress users by meeting with hundreds of them at WordCamps across the world, reading thousands of blog posts, etc.

          Spelling this out would have the additional benefit of avoiding needless frustration for some contributors in controversies like capital_P_dangit, as you could just point them to the philosophy document.

      • bentrem 5:45 pm on August 27, 2010 Permalink | Log in to Reply

    • JohnONolan 9:40 pm on August 26, 2010 Permalink | Log in to Reply

      Further thoughts and questions that took me a long time to learn:

      Who are the core team?
      Who answers to who? What is the hierarchy of power?

      (oh I see that Nacin just added this above)

      What is ETIQUETTE on Trac? I was petrified for months of Trac, not being able to edit stuff is frightening. As is changing the status/priority/anything of a ticket without knowing whether or not it’s the right thing to do.

      How do you apply a patch (in detail, inc info about how to dowload it FROM trac) for testing?

      A template for bug reporting which people can use to create better, more substantial tickets.

    • Mr Mist 9:51 pm on August 26, 2010 Permalink | Log in to Reply

      A really simple guide on how to create a workable patch in various O/S.
      When to re-open a ticket / when not to re-open.
      What to put in the tags fields

    • Andrew Nacin 9:52 pm on August 26, 2010 Permalink | Log in to Reply

      From Ryan: The two most important attributes of a core contributor are brevity and thick skin.

      I’d argue that the brevity can be applied widely: to patches, comments, personal agendas.

      • John James Jacoby 10:08 pm on August 26, 2010 Permalink | Log in to Reply

        Agree with this completely. No one wants to read through a 4 paragraph explanation of a bug. And no one is out to hurt anyone else’s feelings; and if your feelings are hurt, you’re doing it wrong.

    • bentrem 9:53 pm on August 26, 2010 Permalink | Log in to Reply

      25c reads like this: a) as I cited in IRC, ” Boeing’s old “Sequential Thematic Order of Presentation” (STOP)” … time tested and industry-strenght. Else you get caught up in subjective aspects. Gotta have a matrix or tree to hang things from. –ben

    • Brian Layman 9:56 pm on August 26, 2010 Permalink | Log in to Reply

      A default assumption that others know at least as much as you, if not more. This helps you ask why something was coded a particularly way rather than going in with a “this code is bullocks” attitude.

      • Jacob Santos 10:03 pm on August 26, 2010 Permalink | Log in to Reply

        This a good suggestion but hard to do. Sometimes the personality of people (like mine) is to assume everyone doesn’t know what they are doing until they prove otherwise. However, it is very quick to learn who knows what they are talking about verses those who relatively don’t.

    • Andrea_R 10:26 pm on August 26, 2010 Permalink | Log in to Reply

      Just a few broader ones for those new to the process:

      • what do I need to keep tabs on?
      • should I hang out in IRC? When? If I’m contributing on a regular basis, is there an expectation that I should show up for dev chats?
      • after reading all the above resources, who do I turn to if I have a question that needs clarifying?
      • do I need to join particular mailing lists?
      • if I file a ticket, is it expected that I need to also produce a patch? Will it help if I do?
      • Jacob Santos 10:30 pm on August 26, 2010 Permalink | Log in to Reply

        I think dev chats has always to me been a point of contention. Decisions are made there and I suppose they are tentative, but the problems has been that work places usually do not allow for IRC chats that aren’t work related. Generally also, one can not bring up dev chat related topics after the dev chat is finish barring both those who work at jobs restricting access to the IRC chat and those who sleep during the time periods of the chat.

    • Ron 10:32 pm on August 26, 2010 Permalink | Log in to Reply

      I jumped into the deep end of the pool in January. A brief guide to trac (which others have mentioned) would be indespensible, imo.

      Second, for people who are interesting in being actively involved on an ongoing basis, I would strongly recommend that they follow activity in trac and review all the IRC logs for at least a month. The huge benefit to the contributor is that they will become familiar with the “regulars” and how they work together.

    • Ryan McCue 12:47 am on August 27, 2010 Permalink | Log in to Reply

      One essential piece of knowledge is knowing how to get your patches actually committed. I’ve found that the trick is to bug committers until they get sick of you doing so and finally commit it. ;)

      (Seriously though, at least mentioning your patch in #wordpress-dev helps to get it committed)

      • Andrew Nacin 2:12 am on August 27, 2010 Permalink | Log in to Reply

        Justification is also important. I like this from our Release Philosophy page on the Codex: “If you’re too lazy to do the homework and think through the big-picture rationale, I’m too lazy to add the feature. On the other hand, patches that come with well-thought-through rationale are often applied right away.”

    • Andrew Nacin 2:32 am on August 27, 2010 Permalink | Log in to Reply

      Another good thing that takes a while to figure out, is navigating specific aspects and functionality of the codebase, and how that goes into creating patches. A few examples that come to mind:

      • CSS and JS. Don’t minimize. It keeps the patches small, it prevents patches from going stale over an otherwise unrelated change in the file, and it allows the committer to confirm that the file was indeed properly minimized.
      • Images. Attach them to the ticket, preferably the originals too so we have a record of them. (Good for UI group.)
      • Script/db_version bumps. No need to include the bumps in the patch; we can handle them that way we know we got everything.
      • DB upgrades. How it all works is definitely confusing as first. Same with update-core.php.
      • Deprecated functions. Where they go, how we do it, etc. Maintaining full functionality is vital.
      • Also knowing how to test certain aspects of the code, using WP_DEBUG, etc.
    • dougwrites 5:59 pm on June 4, 2011 Permalink | Log in to Reply

      Still taking suggestions? Thank you for doing this!

      General: having patience with the cycle, but also understanding deadlines and when to jump before those points when no longer can get something in.

      Docs: especially contextual help but also inline. Different from other patches?? Best way to package patches (individual files, omnibus sets, also attach text files of what text would look like with changes?). Knowing that writing is rewriting and re-rewriting. Balancing brevity with hitting enough key points.

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel