Cancel

Jeff Chandler

How Non-Developers Can Contribute to and Influence WordPress Core Development

If you don’t consider yourself a developer and want to contribute to WordPress core, Hugh Lashbrooke’s guide offers a few different techniques. The guide explains how and where to provide feedback and how important it is to beta test new features.

Over the years, I’ve used WP Tavern to advocate for and against features in WordPress. One of the best pieces of advice I can give non-developers is to organize your thoughts or stance on a specific feature or direction and publish them on your site. This allows you to control the conversation and gives you plenty of space to explain your perspective.

A great example is this post asking for help to add comment moderation approval notifications to WordPress. I explain why it’s needed with a link to the ticket I created to keep track of the conversation. I prefer to write about potential features and based on feedback, I’ll either create a trac ticket myself or someone will do it for me with a link to the post.

The Tavern is in the dashboard and is read by a large audience, including core developers. However, thanks to social media, a well constructed post with solid points will make the rounds on Twitter, Facebook, and within WordPress sub-communities.

It’s those posts and associated comments that serve as one of many foundations for change in WordPress without touching a line of code. Keep in mind that there’s no guarantee you’ll be able to directly influence WordPress core development with words alone, but respectful, in-depth conversations with differing opinions and perspectives are an important part of the community regardless.

Category:
Tags: , ,
21

21 responses to “How Non-Developers Can Contribute to and Influence WordPress Core Development”

  1. Good piece Jeff, and I can say I hope it’s true. I think however the more and more insular nature of the core development team means that we may be talking to ourselves. It’s frustrating at times, but what can you do?

    Create forum topic from comment

  4. I don’t want to get into a long discussion about this (because that would be thoroughly defeating the point), but to respond to alex and Pixelarge to say that the core development team is definitely open to feedback and input from everyone in the community. The problem is that much of the feedback is given in angry blog post comments (primarily on WP Tavern). I don’t know about you, but if I’m a core developer for a product then I am highly unlikely to listen to angry and insulting comments about the way we do things.

    The point of my blog post that was linked in this article, was to show people where the appropriate channels for feedback are located so you can make sure your voice is heard. So if you have ideas or input then please go to the correct channels (they exist for a reason) instead of commenting elsewhere and then wondering why you aren’t being heard.

    So the moral of the story is to use the right channels instead of the wrong ones and be respectful when you communicate your opinions :)

    Create forum topic from comment

    • @Hugh,

      Actually, the moral of the story has yet to be seen. And your “right channels” for non-developers like me exist only for us to give feedback on things you’ve already decided to implement.

      In other words, you don’t have anywhere that I can say “Please — just stop!” and have that receive anything more than short shrift. Yet respect works both ways, you know.

      And, in case anyone is wondering what I’d like to stop, it’s this. Please stop bundling additional functionality with security improvements and patches.

      Since I am not a developer, I don’t want to be fiddling with my sites all the time. If there’s a security problem, then sure, of course I’ll install the patch. But I don’t want some new functionality added to the patch, because then I have to test for breakages.

      At some times of year, it’s absolutely critical that nothing breaks. Currently, core updates often leave me choosing between not updating and remaining open to what is now a well-known security vulnerability, or updating and risk something breaking.

      That’s a disrespectful position to put me in.

      Create forum topic from comment

      • and your “right channels” for non-developers like me exist only for us to give feedback on things you’ve already decided to implement.

        This is not true. The make core blogs are where people publish their feature plugin merge proposals. It’s these specific posts that allow you to give feedback before something is approved and implemented in WordPress. In addition to the merge proposal posts, they’re discussed in the weekly WordPress developer chats held on Wednesdays where you can chime in on the proposal along with core developers. These feedback opportunities all exist prior to things like feature plugins being implemented.

        As for other things in core, I’ve learned by now that WordPress development by committee would likely result in a slow pace of development or no development at all.

        In other words, you don’t have anywhere that I can say “Please — just stop!” and have that receive anything more than short shrift. Yet respect works both ways, you know.

        What is it that you want to happen if you leave that type of comment on a merge proposal post? Your voice and opinion is not the one that rules the land, it’s part of a larger pool of voices. Are you expecting the core team to just stop what they’re doing because you said so?

        If WordPress did not push out security updates, it would be a disrespectful position to put everyone in. We know that at least three major updates to WordPress are released a year. The amount of point releases to fix bugs or security issues varies. However, ultimately it’s your responsibility to ensure that nothing will break and you do the appropriate amount of testing to make sure the upgrade goes as smooth as possible. I will say though, WordPress does have a small history of updates breaking things that are out of the user’s control but they’re more of an anomaly than common place.

        Create forum topic from comment

        • @Jeff,

          Who said that I didn’t want core to put out security updates? I certainly didn’t.

          I did say that I don’t appreciate them being bundled with functionality additions.

          However, ultimately it’s your responsibility to ensure that nothing will break and you do the appropriate amount of testing to make sure the upgrade goes as smooth as possible.

          I know. That’s why I do precisely that. But it’s an odd position to put a non-developer in when WP is supposedly about democratizing publishing. I could publish much more if I weren’t compelled to test and fiddle. But apparently, I either need to work out a developer-like testing schedule, or else pay a developer to test everything before updating.

          As for things not breaking on a WP upgrade, that really depends, I suspect, on how complex the site is. On a simple blog, breakages are probably few. On more complex sites, though, my experience is that that is just not true at all.

          Create forum topic from comment

          • I wouldn’t mind seeing security updates contain nothing but the fix but depending on the timing of its release, the team usually bundles in fixes applied since then so there isn’t two separate releases. However, with the notion of automatic updates for point releases, maybe that’s really less of an issue to be concerned about.

            Is there any way you can document your experiences with automatic updates and complex sites and describe what breaks? Is it core, is it a plugin, is it a theme that breaks? By documenting the process and describing what goes wrong, it’s possible you can help improve the process so you experience fewer issues updating on more complex sites.

            Create forum topic from comment

        • @Jeff,

          Is there any way you can document your experiences with automatic updates and complex sites and describe what breaks? Is it core, is it a plugin, is it a theme that breaks? By documenting the process and describing what goes wrong, it’s possible you can help improve the process so you experience fewer issues updating on more complex sites.

          Jeff, that’s exactly what I have done. Testing systematically is the only way I’ve managed to keep myself sane. But it’s a very long schedule.

          If security patches are bundled with added functionality, that means I can’t apply the patches until I have worked through my testing schedule. Getting time to do that is hard. So weeks may go by before I can install the patch.

          I just can’t see any justification for such bundling.

          Create forum topic from comment

        • Jeff:

          Is there any way you can document your experiences with automatic updates and complex sites and describe what breaks? Is it core, is it a plugin, is it a theme that breaks?

          Any site that uses any custom code at all would break every time an update occurs. Having to patch and re-patch file on each update (one per month on average) is a huge waste of time. However, there are few options, WordPress does not have stable supported versions, just a single bleeding edge version, and everyone has to play keep up.

          A security fix should be a security fix, period. It should provide only the files that need to get fixed, and should be applied. There should be no change in functionality unless there is an exceptional circumstance where a function is itself the security issue.

          One of the issues for me is a lack of “hooks”, places where code can be easily added to the most basic of files. Security on wordpress sites (especially those using Cloudflare or other “edge” providers) is very difficult, made harder by the fact that there are no hard coded points where extra code can be added to monitor access to critical parts of the installation. No, htaccess won’t work (edge providers, remember), so I have forced on every update to manually edit a half a dozen files on each install to assure better security and logging.

          A security fix should be a security fix, period. It should provide only the files that need to get fixed, and should be applied. There should be no change in functionality unless there is an exceptional circumstance where a function is itself the security issue.

          Functional upgrades should be “full version” things. The .1s and .2s should be fixes to those functions (without adding new). The reminder bug for those versions should be able to be disabled or ignored. If they are patching something because it’s a security issue, then issue a security patch.

          Right now, having to make a full site update twice a month per site is a full time job. (twice because the themes and plugins are always late). Even an hour per month per site, over a couple of hundred sites it more than a full time job alone. Either I contract that out or hire someone at cost, or I do it myself and lose the time that would be spent doing something profitable (or enjoyable). Too many updates, too many versions… it’s hard.

          A personal suggestion for wordpress: STOP. Build out a stable version (say 4.5) and stop adding features and such. Then go away, and work on wordpress 5. Clean sheet it if you want, whatever. Don’t come back for 6 months until you have a fully functional product. When you do release it, allow for and support theme and plugins versions for 4.5 (ie, allow there to be a stable 4.5 version of everything in the WP universe) and support 5.0 and beyond as itself. That will let you clear up the code, make major overhauls in how things work without worrying so much about legacy coding, and at the same time provide a stable (and supported) version 4.5 that would be perfect for users who don’t want or need the bleeding edgem but who do want to have a secure and supported version.

          It’s time to move forward.

          Create forum topic from comment

        • Any site that uses any custom code at all would break every time an update occurs. Having to patch and re-patch file on each update (one per month on average) is a huge waste of time.

          Yes, modifying core files is strongly not recommended, and the desired result can generally be achieved in other ways.

          A security fix should be a security fix, period. It should provide only the files that need to get fixed, and should be applied. There should be no change in functionality unless there is an exceptional circumstance where a function is itself the security issue.

          That’s exactly how background updates for previous branches currently work.

          One of the issues for me is a lack of “hooks”, places where code can be easily added to the most basic of files.

          If there are hooks missing in some particular files, could you create a Trac ticket and describe your use case and the changes you have to make in detail?

          I’m sure either the hooks would eventually be added or a more appropriate solution would be suggested.

          Create forum topic from comment

    • Hugh, I understand where you come from, but perhaps where we poor users and end product producers are isn’t a good place to be.

      If we go to the wordpress support forums to raise issues, we generally get trashed. The “support” people there are generally not at all involved in core. It takes a while to figure out that while they speak with great authority, they in fact have none. That by itself is insanely frustrating.

      Opening a TRAC for issues isn’t much more useful. There are outstanding TRAC requests that go back years, and have never been fully addressed or resolved. Generally it seems that the hope is that if they are ignored long enough, a moderator type can come along and close the TRAC out as no longer relevant or to point it to another, vaguely related TRAC to make it go away. That too is insanely frustrating.

      As KTS915 point out, it seems that almost all of the channels open to non-developers limit us to trying to close the barn door after the horse gets out. Most of what comes out is attempts to mitigate decisions made and released which end up impacting our sites, our client sites, or our business. It’s almost impossible to get ahead of the curve unless you are a decent enough programmer to create complex plugins to change functions of wordpress itself.

      I am not yet seeing a way that I can get my two cents in.

      Create forum topic from comment

      • If you don’t see a way that you can have your voice heard then I’m guessing that you never actually read my post that was linked in this article? I’ll add the link here again for you: http://hughlashbrooke.com/2015/11/03/a-non-developers-guide-to-getting-involved-in-wordpress-core-development/

        To be honest, there’s no real point in discussing this further as it seems that you have made up your mind that your voice will never be heard even when I can guarantee you that the core development team is always open to *constructive* feedback.

        I say all this, by the way, as someone who is NOT on the core team, but who has managed to get involved in core development – initially by giving feedback through the channels I list in my blog post, then also eventually by submitting patches. I found the core team very receptive to thoughts and ideas, even before I was not in a position to submit any patches.

        So I’m sorry that you feel the way you do, but I strongly disagree with you and I would encourage you to use the correct channels at the correct time (i.e. before a feature is rolled into core). If you truly do care about core features then you will follow the Make Core blog and provide feedback before the barn door is closed – if you don’t do so, then I can only assume that you enjoy ranting and being angry about these things instead of actually having a say that will make a difference.

        I’m going to tap out of this conversation because if it goes any further I will just end up repeating myself over and over again, but I will leave by repeating what Jeff said in a comment above to remind you that just because you have an opinion, doesn’t mean the whole WordPress world must bend to your will:

        Your voice and opinion is not the one that rules the land, it’s part of a larger pool of voices. Are you expecting the core team to just stop what they’re doing because you said so?

        I hope to see you on the Make Core blog soon – I would love to hear your voice in the comments there giving some truly valuable feedback because it is clear that you have some valid opinions and I think they would be very useful if you expressed them in the correct channel :)

        Create forum topic from comment

        • Hugh, I read your piece.

          I mentioned (as an example) that TRAC has become almost useless. It’s passibly good for dealing with broken existing features, but it’s not a core influence thing. New ideas generally get shut down or merged into vaguely similar concepts, usually those that have already been “answered” as not possible or not required. You need only go look at the number of TRAC items related to comment handling to see how things generally get shut down.

          Most importantly, TRAC is mostly about fixing what is broken, not about deciding what gets to be included (and broken) in the future.

          Are you expecting the core team to just stop what they’re doing because you said so?

          Nope, I am however expecting more than a casual brush off of “I don’t see the use for me, so your needs end user are not that important”. We don’t just come up with random things to ask about for fun, we don’t make code changes ourselves for amusement, we do it because we see and feel a need. That our situation may not match a core developer’s situation doesn’t make the ideas and needs less valid.

          I will look more into the Make blog, but honestly, it seems quite a bit more on the technical and “talk at you” announcement of features more than a spirited give and take about future developments and ideas. Seem again to be more oriented towards “this is what we are doing…” as opposed to “what do you think we should be doing?”.

          then also eventually by submitting patches

          Alas, for those of us who cannot code at this level, are we left out in the cold because we cannot properly code our own fixes?

          I have been around since wordpress 1.x – it’s been a long hard slog that doesn’t get any easier by the day!

          Create forum topic from comment

        • I will look more into the Make blog, but honestly, it seems quite a bit more on the technical and “talk at you” announcement of features more than a spirited give and take about future developments and ideas. Seem again to be more oriented towards “this is what we are doing…” as opposed to “what do you think we should be doing?”.

          You couldn’t be further from the truth – while the discussions are obviously going to be at least somewhat technical (we are discussing code here after all), that is probably the best place you can supply feedback that will be heard. That and the Slack channel, which I also mentioned in that post.

          If you’re going to continue not getting involved there even though you have strong and valid opinions, then I’m afraid you can’t really complain that your voice is not heard.

          So, like I said – hope to see you on there soon :)

          Create forum topic from comment

        • I can guarantee you that the core development team is always open to *constructive* feedback.

          @Hugh, @Jeff,

          That evidently depends on what the development team chooses to deem “constructive.”

          You see, I am not talking through lack of experience. After a year or so of using WordPress, I started to realize that some of the issues I was experiencing could not be addressed by the support forums for themes and plugins on wordpress.org, so I Googled for further information.

          My Google searches took me to Trac and Make, where I saw non-developers like me getting repeatedly trashed by developers — and especially by core developers. I was appalled. (And, frankly, of the core developers whose names I know, there are only two whom I haven’t seen engage in that sort of conduct.)

          But my Google searches also brought me to the Tavern, where there appeared to be genuine discussions about WordPress issues. So that’s when I started commenting here. And I’ve found a number of people who are clearly experiencing the same frustrations as I do.

          Apparently, though, I should take my medicine on Trac and Make and the like, and be abused just like those other poor devils before me! Catch 22 comes to mind.

          Create forum topic from comment

      • You’re right that most of the volunteers who moderate the support forums do not work on core but many of them are liaisons to the core team. For example, if specific issues are raised in different threads or patterns are determined, members of the support team will forward the threads and information to the core team. The WordPress.org support forums are for giving and receiving support, not for airing grievances or general discussions of WordPress.

        Opening a TRAC for issues isn’t much more useful. There are outstanding TRAC requests that go back years, and have never been fully addressed or resolved.

        How about this one from six years ago? There has been a significant effort from core contributors like Chris Christoff who have been going through the massive backlog of Trac tickets to either punt, close, or update them. Filing Trac tickets should be done to address or discuss a specific issue with WordPress. Again, not to air grievances but to be as specific as possible and either suggest solutions to the issue or attach a patch to the ticket that contains a fix.

        If none of the communication channels mentioned by Hugh Lashbrooke fits your need, I suggest writing your two cents in a blog post or two and then telling me about it as I’ll help spread the word.

        Everyone wants the core team to create the version of WordPress that’s tailored specifically for them and their clients but that isn’t how WordPress is developed. End user needs come first followed by developer tools. If WordPress is not satisfying the needs of you or your clients because of it’s development cycle or it’s not adding the right features you need, perhaps it’s a good time to look for a different solution.

        Too many people get stuck in the rabbit hole where they air grievances about WordPress until their blue in the face and upset at the world. It’s ok to move away from WordPress as your goal is to provide the best solution to your clients as possible. This isn’t to say you can’t complain or raise issues with WordPress, it’s just that there comes a point where it makes the most sense to move away.

        Create forum topic from comment

        • Everyone wants the core team to create the version of WordPress that’s tailored specifically for them and their clients but that isn’t how WordPress is developed.

          Actually, I want no such thing. What I really want is a little less moving target and a little more consideration for needs outside of the “gee whiz feature of the month” stuff.

          WordPress has a real problem in not having a “stable supported version” system in place. Instead, everything is dragged forward all the time. It is a situation that creates friction, as people are forced forward even if they don’t need the latest cool gizmo to run their sites.

          Theme and plug in developers are also encouraged not to dally at any one level, and their plug ins often are not longer compatible with older versions as a result of code changes to match the latest wordpress versions. There is no provision in the wordpress universe for secure / stable versioning, it’s always move forward or risk problems.

          it’s just that there comes a point where it makes the most sense to move away.

          Considering the investment and the time spent on existing projects, there is no simple way to “just move away”. WordPress isn’t like choosing MariaDB over another database system or what have you, it’s a whole way of operating and creating content that isn’t easily exported to any other system. Once you are in, the costs related to getting out are huge – essentially recreating complete sites into another system in parallel with live sites, from the ground up. Give people the old “my way or the highway” just isn’t possible in this sort of a product, the longer you are using wordpress the more expensive it becomes to walk away. So when people are complaining or trying to get something done, it’s because the alternatives are out of reach and potentially fraught with their own problems.

          I complain because I care. I want WP to be better, I want it to be lighter, I want it to be less of a resource hog, and I want it to be less of a security nightmare looking for a place to happen.

          Don’t you?

          Create forum topic from comment

  5. @alex I’m replying to the above comment. This may be long. ;)

    WordPress has a real problem in not having a “stable supported version” system in place.

    1. WordPress does not have that problem and every release is a “stable supported version”. I’ll circle back to that.

    Give people the old “my way or the highway” just isn’t possible in this sort of a product

    2. No one says that, no one does that. But someone disliking how the development model works is not the same as saying to you “get lost”. It really isn’t.

    Considering the investment and the time spent on existing projects, there is no simple way to “just move away”.

    3. No ones asking anyone to “just move away” and moving away is not a solution to your problem.

    I complain because I care. I want WP to be better, I want it to be lighter, I want it to be less of a resource hog, and I want it to be less of a security nightmare looking for a place to happen.

    Don’t you?

    4. Oooh, I like that one. It makes your problem into “I care. You all disagree with this. Ergo you must not care for WordPress users”.

    See why I like that one? ;) It’s not on point but does manage to get away the real problem here. It’s a distraction and I am 100% positive that people will not only like that comment but use it as an often repeated battle cry.

    Now to address those items.

    Item 1: There has never been a test branch of WordPress and all WordPress releases are stable.

    That does not mean users have not had problems with some releases. There is a lot of add-on code in the form of themes and plugins that either are just doing it wrong intentionally or without realizing it. Usually it’s the latter and theme/plugin authors learn from their mistakes. Updates get released quickly for those themes and add-ons, you see that with every release of WordPress.

    Add-on code gets better all the time. No one (generally) repeats the same mistakes in their code. But please don’t mistake problems with add-ons for a WordPress problem. It’s not.

    Item 2: The replies aren’t “my way or the highway” it’s always been “Hey, work with the community, use the actual existing channels and make your case. If the case is persuasive then changes will happen.”

    These comments here about your problems? Not persuasive, doesn’t make a case and last time I checked WP Tavern isn’t the place to influence those decisions. Also the vitriol doesn’t help especially when the complaint can be summarized as “Core Team hates users. Why won’t the compromise?” A capitulation to reversing design decisions that were made in line with the design philosophy isn’t a compromise.

    See Hugh’s guide for how to get involved. That’s a good place to start.

    Item 3: When a WordPress release happens the best place to check the temperature is the WordPress support forums. Almost a year ago I wrote this in the make/support blog.

    Please report any 4.1 related issues there and update the OMGWTFBBQ post as needed. If needed; it looks like it’s been a smooth release* in the support forums.

    There have been releases that have generated A LOT of support topics in the WordPress forums. The stated goal of WordPress releases is to become transparent and issue free. That’s actually happening; WordPress version upgrades are approaching the same success rate as Chrome browser upgrades.

    That does not mean some users will not have problems. With millions of installations how could 100% success rate ever happen? But see Item 1 above and when you do have a problem, the support team wants to know and help you out.

    Item 4: A litany of complaints does not work anywhere with any community.

    There is a certain therapeutic effect when anyone complains. I complain all the time. Work, WordPress community, my commute etc. Who doesn’t complain?

    But I don’t think my complaints work or accomplish anything. What works is getting involved and again, Hugh’s post explains that very well.

    If you are a WordPress user then odds are that the version upgrades will not effect you in any negative way. Just volunteer in the support forums, it really is an excellent way to see that.

    If you are concerned about upgrades and that’s good, then you (the user) really need to do the following.

    a. Have a back up strategy. Store full DB and file backups off of your web server. Test them, make sure your backups work. I backup my whole network every night automatically and occasionally confirm that they’re good. I use a plugin, there’s a lot of them out there for free.

    b. Build a copy of your live site either on localhost (sub-optimal) or on a second vhost (much better). Some add-ons don’t work unless the service can get to your site and localhost won’t work in that case.

    c. Upgrade the backup copy. See how it goes. If it goes well the do it for real on the actual live site. If the live site goes belly up then you’ll be glad you have a backup strategy.

    *Re-reads*

    Wow, that’s a lot for a comment. I think “WP Tavern Comment Effect” should be a MEME.

    Look, no one will take responsibility for your site, that’s all on you. And there is no way everyone will be happy with what any group does. You and others do not like how the development process works and that’s fine.

    But please stop trying to identify your problem managing your site as a WordPress problem. It’s not and my saying that isn’t telling you to “take the highway”. It’s me suggesting that you manage your site and upgrades. That’s not an unreasonable suggestion.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.