Simon Wheatley – If Simon runs into a problem in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. then he tries to create a tracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. ticket and follow that through
Jonathan Davis – Shopp. Contributes bug fixes, hasn’t managed to get a ticket in.
Mike Pretty – Wants to work out how to work with core to create a team to work on bigger tasks.
Jake Goldman – 10up Ad hoc trac widgets, donate 50% of Helen’s time to core.
Tom Auger – Runs an agency, attends events. Wants to work to GPLGPL GPL is an acronym for GNU Public License. It is the standard license WordPress uses for Open Source licensing https://wordpress.org/about/license/. The GPL is a ‘copyleft’ license https://www.gnu.org/licenses/copyleft.en.html. This means that derivative work can only be distributed under the same license terms. This is in distinction to permissive free software licenses, of which the BSD license and the MIT License are widely used examples. his plugins
Tom Willmot –
Ronnie Burt – Edublogs no formal process, developers create bugs, focused on MultisiteMultisite Multisite is a WordPress feature which allows users to create a network of sites on a single WordPress installation. Available since WordPress version 3.0, Multisite is a continuation of WPMU or WordPress Multiuser project. WordPress MultiUser project was discontinued and its features were included into WordPress core.https://codex.wordpress.org/Create_A_Network.
John Hawkins – no formal process, runs on trunk, more of a ticked submitter instead of a patcher
Alex King – Lots of ad-hoc trac tickets, they run into a lot of edge case issues that might not be found otherwise. Have found that larger tickets can stall
Ptah Dunbar – Runs an agency, hires contractors – Has “Open SourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. Fridays” to contribute back to core but finds he ends up doing a lot of admin work.
Ron Rennick – Copyblogger Media – Does a lot of multisite testing, does a lot of testing of large new features coming in the next version (like media stuff). Self funded his way through the work to merge mu and single, it took a lot longer than expected which was tough.
Justin, iThemes – No formal core contribution policy, would like to have one.
People find that they spend to much time on admin around trac tickets and not enough on developers.
Jake shared how they started the process of Helen contributing to core, it’s driven by her passion, started as a small percentage of her time, increased over time.
Helen is not the only person that has “non-client” time, others choose to spend it on plugins etc.
It has to be driven by the person, you can’t expect all employees to contribute or to want to contribute. There is a large amount of trust. You can’t micromanage the amount of time you are allowing that person to core, it’s a privilege to be allowed to contribute to core.
Alex felt that the issues around trac tickets not being well received, abandoned etc. can put people off. It’s a worry that one of your staff spends a month of company time on a patch that then isn’t accepted. What about if core team had a better roadmap that they shared with companies, companies could then pick large items off the roadmap.
Nacin joined the discussion, was asked about assigning large tasks to agencies to work on. The point he made was that agencies would often write that feature anyway because it’s something that they need for a client site, so build that feature as a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and if it gets traction then it can find its way into core.
Why can’t core team reach out to development shops and ask them for help with specific items. Nacins point was that he wasn’t sure that agencies would want to do that. Also large feature development shouldn’t be happening behind closed doors. Also agencies could offer to help develop specific features.
iThemes shared their experience with the image uploader, they had a meeting where they brainstormed how they would fix the image uploader but they found that Koop was already working on it. They felt it would have been better if that had been shared earlier. Nacin felt that it was shared as early as it could be. Nacin talked about the menu’s code, although it wasn’t architected correctly it didn’t matter that non of the code was eventually used, it acted as a starting point which then lead to menus making that release.
Alex wanted to talk about how larger changes could be “pre-approved” so that we avoid large patches that are then left to rot.
Nacin felt that large features are a special case that don’t / can’t follow the standard processes, they really require the personal touch, chatting over a beer or pick up the phone.
People wanted to know how to get involved at the roadmap level.
The underlying issue seemed to be about the fact that core contribution is a 24/7 lifestyle which doesn’t always match with the time that an agencies developers have.
Another issue that was raised was the pushback against new features, when a core dev says “thats not going to make it in” does that mean never? Nacin recommended releasing the feature as a plugin. Nacin went on to explain the process that goes on when planning new releases. The perfect time to pitch new features is between releases, before the scoping sessions for the next release, core developers will go back and look at features that didn’t make the last release.
Jake asked about planning a cycle ahead so that agencies could assign a developer or a set of developers could work on. Nacin suggested a lot of things that could be worked on for 3.6. Can we have a roadmap of future tasks. Nacin said that trac has got too large which prevents a lot of changes that would help these issues.
Another important thing to remember is that you can give back in other ways that just code, there are a lot of administrative tasks that need doing, agencies could help create that roadmap.
One great option that should work for agencies is to run trunk and test patches against your client sites. Unit testing is another area that agencies could make a big difference, it is good for developers to learn how to write unit tests. If someone only has 3 hours per week to contribute they can still help with admin on trac or write a unit test for a specific patch. Remember that having developers working on core benefits the agency because it is on the job training.
Jake asked Helen whether the other people in the company that have contributed to 3.5 would have contributed if Helen hadn’t have been there. Helen felt that there wouldn’t have been as much contribution. Jake wondered if the fact that Helen is on the team meant that more of 10ups contributions got into core (contributions from other developers), she felt not as a lot of her stuff ends up sitting round not getting in as well.
Could we have an ombudsmen from the core team that could reach out to agencies with sanctioned features that need working on.
Nacins final point was that the number of new tickets per day was increasing at an unmanageable rate, he said we can help by testing patches and triaging tickets. He would like to see teams per component that can be in charge of triaging. Those component owners are then often given commit access for that release.
Nacin wants to build a list of future features that people could start working on, a list of easy fixes / low hanging fruit and component owners.
WP Tuts can help by posting about upcoming releases and betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.’s which raises awareness and increase the number of people testing that beta.
Nacin wanted to re-enforce that we can all contact him at any time to ask about how we can help.
Our action item is to create a mailing list for companies to discuss how they can help make each other aware of things they are working on, patches that need testing.