WordPress.org

Make WordPress Core

Updates from Helen Hou-Sandi Toggle Comment Threads | Keyboard Shortcuts

  • Helen Hou-Sandi 8:50 pm on May 23, 2016 Permalink |
    Tags:   

    May 20 toolbar and admin menu meeting summary 

    This is a summary of the May 20 toolbar and admin menu meeting, which was held to jump start toolbar changes proposed in #32678 (chat log). The next meeting will be held May 27 at 16:00 UTC.

    The biggest component of this initial phase of changes is bringing the entire admin menu to the toolbar on the front-end. Given that this involves the admin menu “API”, we need to bite the bullet and dive into what it takes to give it a real API and fix #12718 (among others). In order to complete this for 4.6, work needs to move quickly.

    Participants: @helen, @celloexpressions, @folletto, @emathison, @deshack, @morganestes, @rdall, @boonebgorges, @thomasplevy, @jeremyfelt, @clorith

    Key points

    • Action item: A document outlining strategy, documenting the current API, and describing the design of a new API has been started. Sections that are empty/marked for help are in need of owners. This is to be completed by the next meeting.
    • While there are many interaction changes that need exploring, and a few included in the current proposal, the focus for this cycle is content changes.
    • The links currently in the W menu will be relocated/reproduced in other places, e.g. About in the Dashboard submenu and as the link for the version number in the footer of the admin.
    • @boone helpfully provided some background on BuddyPress’s very similar changes to its navigation API last week. This is also documented in the Google Doc above.
     
    • Jon Brown 9:24 pm on May 23, 2016 Permalink | Log in to Reply

      These looks _really_ good and double props for including multi-site _with_ lots of sub-sites.

      One thought that has been bouncing around in my head is moving the network menu (key) to the far right, right of the user avatar. At least in my use, it’s very few users who actually have the need to switch sites or get to the network admin. It’s more akin to switching users than navigating the backend of a single site.

      It’s not a well thought out thought, just one that seemed worth floating for discussion.

  • Helen Hou-Sandi 1:44 am on May 19, 2016 Permalink |
    Tags: ,   

    Toolbar and admin menu meeting this Friday, May 20 

    A meeting will be held on May 20 at 16:00 UTC in #core to take a look at the proposed toolbar changes for 4.6 in #32678 (image below). As the bulk of this proposal involves showing the admin menu as a toolbar dropdown on the front-end, we need to discuss that “API” (#12718, #33418, etc.), as well as what can be done for user testing in the meantime.

    Unified admin menu toolbar concept

     
  • Helen Hou-Sandi 6:45 pm on May 17, 2016 Permalink |  

    May 17 feature projects chat and prompt 

    Today’s feature projects chat will be held at May 18 01:00 UTC. We should cover what each project needs to do next, any other stuck points, and new proposals or ones that need some workshopping. If you cannot make this meeting, leave a comment below with new proposals or questions, and the next meeting will be at May 31 17:00 UTC.

    As a reminder, each feature project needs to develop a clear statement of purpose. This may be an answer to the oft-asked “what problem does this solve?”, but may also be more exploratory in nature. The important thing to keep in mind is to stay away from the “how” or implementation details in the statement itseflf, and focus instead on the what, why, and for whom.

     
    • Pascal Birchler 8:55 pm on May 17, 2016 Permalink | Log in to Reply

      Emerging out of #28197, I’d like to propose a new Preferred Languages feature project. Currently, users can select the site language in the settings, but it has become clear that this has some limitations, especially for different locales (de_CH, de_DE, formal/informal for example) and missing translations.

      There was quite a long discussion about how this could be fixed implementation-wise, but we really should explore this from a feature project side of things.

      The Preferred Languages project should improve the experience for users which speak different languages. Currently, if your site is configured to be served in de_CH, but a plugin is only translated into de_DE, English strings will be shown, which definitely unexpected.

      For this, I’d like to first explore how other software accomplishes this UI-wise and proceed from there.

      So far @Kau-Boy has shown interest in this too.

    • bonger 12:43 am on May 18, 2016 Permalink | Log in to Reply

      This is a repost of https://make.wordpress.org/core/2016/04/19/new-time-for-feature-projects-chat-on-tuesday-april-19/#comment-30126

      A possible featured project has arisen from #30130 “Normalize characters with combining marks to precomposed characters”.

      The goal of the proposed project (UTF-8 Normalization and Audit) would be to have a consistent, unsurprising experience for users on all systems when dealing with UTF-8 data from any source. This to be achieved by exploring if and when UTF-8 should be normalized, and by auditing existing manipulations of UTF-8.

      Currently no normalization of UTF-8 occurs in WP, which can cause issues for users particularly when they copy and paste from non-normalized sources, or refer to non-normalized file names (eg on Mac OS X systems).

      The code basis of the project would be the existing normalization plugin by @zodiac1978 at https://wordpress.org/plugins/normalizer/ and its exploratory fork at https://github.com/gitlost/tl-normalizer

    • Pascal Casier 8:37 am on May 18, 2016 Permalink | Log in to Reply

      Yes, yes and yes please 🙂
      This discussion about language fallback has been running around for long now among the #polyglots and we all agree this would be extremely useful. The project could evaluate the feasibility of putting it into core, have the choice on website level or (even better) at user level.
      Pascal.

  • Helen Hou-Sandi 8:35 pm on May 15, 2016 Permalink |
    Tags:   

    New committers for 4.6! 

    Each cycle, the lead developers review guest and potential committers. We’ve been taking the time to assign each new committer a dedicated mentor and ensure we’re getting feedback from and giving it to existing committers, so it took us a little longer to put it all together this time around. Without further ado, we’ve got two new guest committers and two new permanent committers!

    First up, we have Joe McGill (@joemcgill), whose work on responsive images both as a plugin and post-merge has proven invaluable over the last few releases. He has also been serving as a component maintainer for the extensive media component. I look forward to his continued work in this area, as well as other features and parts of core.

    Next, Peter Wilson (@peterwilsoncc) will be joining our Australian contingent of committers. Peter has shown solid judgment and admirable tenacity in chasing down tricky issues across a number of areas, especially as we’re approaching the finish line. The trickiest things always get left for last, and help in those areas is always appreciated.

    Finally, I’m happy to announce that Ella Van Dorpe (@iseulde) and Weston Ruter (@westonruter) are now permanent committers. Their continuous stewardship of the editor and customizer respectively have been exemplary, and we have all been enjoying the great strides that have been made in these areas thanks in large part to them.

    Please join me in congratulating everyone!

    Update: Additionally, all current guest committers have had their commit renewed for the cycle.

     
  • Helen Hou-Sandi 2:48 am on April 19, 2016 Permalink |
    Tags:   

    New time for feature projects chat on Tuesday, April 19 

    Time change

    Per the comments on the introduction post, the next feature project chat will be held at April 20 01:00 UTC. This will alternate with the first meeting’s time of 17:00 UTC (1:00PM Eastern) (sorry for the initial error, math is hard). Since there are a number of people in place where only one of the times is at a reasonable hour, as activity picks up we will likely move to weekly meetings that alternate times; for now, we will remain at biweekly (i.e. each time will occur every 4 weeks).

    Meeting Agenda

    • A look at feature project pages.
    • Check-ins with existing feature projects.
    • Call for feature projects and feature project ideas.
    • Open floor.

    To help keep us on track and prevent us from missing things, please comment below with any feature projects/ideas and a brief statement of purpose, as seen on the feature projects page. If you have items for the open floor, also add those in the comments.

     
    • David Shanske 2:47 am on April 20, 2016 Permalink | Log in to Reply

      At the feature project meeting, I had proposed a feature project to refresh Linkbacks in WordPress. Trackbacks and Pingbacks are the implementations of the concept of a linkback…sending notification that another site has linked to your own.

      However, the current implementation with Pingbacks and Trackbacks leaves much to be desired as a user experience. The default display is limited and the code is in need of a serious look. There is also a newer protocol, webmentions, which was designed as an update/replacement for Pingbacks, that would be worth integrating into WordPress in future.

      I’ve been trying to boil this down to a simple project brief, and am having trouble, so I could use some help. There is an existing Webmentions ticket(#35435) and one for Improving Linkback Presentation(#32653).

      At the same time, the biggest comment people who see no utility(yet) in pingbacks as they exist now is that they are subject to abuse. There is also a ticket to update the code itself(#34419). So concurrent with looking at improving what exits the code, it is an opportunity to see about how Core can better handle abuse and/or support plugins to do same.

      Doing this correctly may span releases, because it needs not only to incorporate above, but needs user testing and feedback.

      Looking for help boiling down the concept into brief and working on it, if it is accepted as a project.

    • Konstantin Obenland 5:00 pm on April 26, 2016 Permalink | Log in to Reply

      For Shiny Updates:

      Shiny Updates replaces The Bleak Screen of Sadness™ with a simpler and more straight forward experience when installing, updating, and deleting plugins and themes. Progress updates for these actions don’t add a benefit, they are disruptive and confusing. Shiny Updates deals with these details behind the scenes, leaving users with clear actions and results.

      This caters to two core principles of WordPress, designing for the majority, and striving for simplicity. Users don’t really care about the internal process of installing or updating themes and plugins. Listing out these technical steps for them is unnecessary at best. With Shiny Updates these actions also don’t require a page reload anymore which creates a simpler workflow and lets users achieve their goals of an enhanced WordPress experience quicker.

      • Helen Hou-Sandi 5:41 pm on April 28, 2016 Permalink | Log in to Reply

        Some thoughts:

        • For the statement of purpose, I think it’s best to stay away from descriptions of what precisely the project does on a technical/functional level.
        • “disruptive and confusing” is not very informative and doesn’t give us specific things to measure/compare against. What sorts of things are being disrupted? What is confusing about them specifically? The statement may not need that level of specificity but I think we could shape it better around that.
    • MikeNGarrett 9:49 pm on April 27, 2016 Permalink | Log in to Reply

      The developers at The Web Development Group have worked on a plugin called Jarvis for a while now, improving upon the idea of a quick search interface for finding and navigating to content and settings admin pages.

      Recently, we have started discussing what it would take to integrate a feature like this into core and whether or not it would be useful to the greater community beyond existing as a plugin. It is our opinion that a feature like this would augment the functionality of the admin and provide a better user experience for power users of the WordPress admin.

      Our testing with clients has revealed a high rate of use from content editors and developers, allowing these users to find and access the edit pages for content quickly just as the admin bar has aided this user experience on the frontend of WordPress sites.

      https://wordpress.org/plugins/jarvis/

    • bonger 2:30 pm on May 3, 2016 Permalink | Log in to Reply

      A possible featured project has arisen from #30130 “Normalize characters with combining marks to precomposed characters”.

      The goal of the proposed project (UTF-8 Normalization and Audit) would be to have a consistent, unsurprising experience for users on all systems when dealing with UTF-8 data from any source. This to be achieved by exploring if and when UTF-8 should be normalized, and by auditing existing manipulations of UTF-8.

      Currently no normalization of UTF-8 occurs in WP, which can cause issues for users particularly when they copy and paste from non-normalized sources, or refer to non-normalized file names (eg on Mac OS X systems).

      The code basis of the project would be the existing normalization plugin by @zodiac1978 at https://wordpress.org/plugins/normalizer/ and its exploratory fork at https://github.com/gitlost/tl-normalizer

  • Helen Hou-Sandi 12:09 am on March 31, 2016 Permalink |
    Tags:   

    Iterating on Feature Plugins 

    Feature plugins appeared in the wake of the 3.6 release cycle, in which two large efforts were reverted before the final release: a UI for content using post formats and a refreshed aesthetic for the admin, notably with a new set of icons. Both suffered from the same problem: attempting to create and iterate on a significant feature within a single release cycle. The identification of that problem led to the idea of developing features as plugins, decoupling them from the time restrictions of fairly quick release cycles.

    (While post formats had further issues that led to changes not landing in core, the admin design changes became known as MP6, a feature plugin which was merged in WordPress 3.8.)

    Over the last two and a half years, we’ve had successful feature plugins that were merged into core, efforts that began small and grew as discovery happened, ideas that never quite got off the ground, and ideas that were initially explored in “plugin” form but ultimately became patches for various reasons, usually technical. With over two years of active feature plugins behind us, it’s time to take a look at what’s been successful, what hasn’t been, and where we go from here.

    So, what’s next?

    Feature plugins projects

    Thinking of features as plugins has strapped us in a number of ways, in large part because the “plugin” part implies a functional project from the start. From observation, experienced and newer contributors alike set their initial goal to be some sort of functional plugin. As a result, by the time something is being proposed in whatever forum, there’s been a fair amount of effort spent – and personal attachment developed – for something that might be headed in the wrong direction. Changing direction at that point is very demoralizing and has led to burn out and less participation.

    My suggestion is to move both nomenclature and mindset to “feature projects.”

    Feature projects are similar to feature plugins in many ways (including in name), but may not take the form of a plugin; in fact, they likely will not begin as plugins. Most will start as ideas that need exploration to be more fully formed/fleshed out before implementation. Others will become discrete patches on tickets. Others may turn into multiple plugins, breaking out the successful parts of the project into patches for core, while iterating on the less-successful pieces. Still others may remain in plugin format even after reaching a polished point, as they may not make sense as a bundled part of core but serve a valuable purpose for users.

    To start, there is now a feature projects overview (still in progress) that is more of a higher level overview than the current status dashboard, with listings of feature projects that are in progress or merged, with sections for wishful thinking and projects that have been abandoned for one reason or another to be added in the future. Each project should be accompanied by a brief statement that clearly states what problem the project is solving, its goals, and how it supports the various philosophies and objectives of the WordPress project. The overview will also serve as a sort of roadmap for potential project features, albeit one without promises of delivery timeframes.

    The general goal of this shift in framing and process is for feature development to be successful and lead to a stronger product with more contributors. Some individual goals in support of this are:

    • Attracting and retaining a greater range of skill sets in contributors, for example through being able to more thoroughly engage designers in early stages.
    • Implementing methods of collecting usage information and other data (more on that coming soon).
    • Supporting feature projects with resources for user testing and more structured feedback.
    • Advance both contributor and general community knowledge around product design and development.

    Life cycle of a feature project

    Today, feature plugins move forward in varying directions, frequently without a clear goal or target. This can make it hard to determine what their status is or what next steps might be. Learning from the current situation, feature projects will have clearer check points. For one, there will be bi-weekly meetings where anyone can propose a feature project, check in at specific goal points, update the community on the current status of a feature project, and/or ask for help if they’re having issues advancing their idea. We will kick these off in the #core channel in Slack on April 5 17:00 UTC.

    Beyond this, there are several parts in the life of a feature project.

    First, a feature project should have a brief statement of purpose. Explaining why a feature project is important to WordPress – and how it fits in with the values and philosophies of WordPress – is a necessary part for success. Without such a statement, projects can (and do) get “lost” along the way, ultimately heading in a direction that is not right for core, or start off on the wrong foot entirely.

    This statement of purpose should outline the justification/explanation for why the feature project should exist. This statement is not meant to be encapsulate the entire idea, but should give an idea of how the idea fits into core and its concepts. Keep in mind that a simple statement is better than a long one; comprehensive statements may be all-inclusive, but they narrow the focus in a way that might not make sense as ideas morph based on feedback.

    Here are some examples of previous feature ideas – since implemented – in the form of a brief statement:

    • MP6: Simplify and modernize the design of the admin, with a focus on the rapidly growing user base using HiDPI, touch, and small-screened devices.
    • Widgets Customizer: Improve the WYSIWYG experience of widgets through non-destructive live previews. The current approach of making some changes immediately live but not others breaks users’ expectations and trust.

    After creating and proposing a project with statement at a meeting, ideas should move through a discovery and design process (more on that below).

    Once the discovery results have been put together and published, it will be proposed to the core team as an official feature project during a regularly scheduled meeting. The core team then has the opportunity to study the direction before giving it the green light to move into implementation. It’s important to question ideas and assumptions early on to ensure the design and discovery process went well and that the project heads along the best path.

    Next, with the endorsement of the core team, development of the feature project can begin. Development may take the form of a plugin, a patch on a core ticket, or whatever way works best for the specific feature project.

    Finally, once a feature project is fully developed, it can be proposed for inclusion in core. Proposals can take the form of a Make/Core post along the same lines as feature plugin merge proposals, or by raising the specific ticket at a weekly core devchat. As the project gets closer to the finish line, it’s recommended that the team report on its status at one of the scheduled feature project chats.

    Throughout the entire process, the feature project team should hold weekly meetings, allowing others to ask questions, gather feedback, and help develop the feature.

    Discovery and Design First

    WordPress has always taken a user-first approach to features and often even the APIs that power these features. The benefits of this approach show in adoption and the myriad creative ways developers have found to push its limits. In the past, the project has spent time testing features after they were developed, helping determine if the features were ready for core. However, as we find in product companies and digital agencies, design (interaction, visual, etc.) should be based on data gathered from discovery with real users and happen before design and technical implementation begin.

    Feature design and development should come from interviews with users, developed personas, surveys of those personas, documented flows, and other fairly standard methods. Proper discovery will allow for testing long before functional development begins using low-fidelity storyboards and walking through potential concepts with users, both verbally and visually. Projects should check in at a meeting when discovery results are available and continue to check in through the design process.

    It’s important to note here that some discovery and design stages may be successful by most measures but not lead to a viable feature for core. This is okay. Going through these stages will often still lead to improvements that can be brought back to core and will help us refine feature project approaches in the future.

    Conclusion

    Feature plugins as a concept were a great idea; decoupling features from the release process gives us a lot of room to get things right. Adjusting our approach to cover all features – and to focus on discovery and design first – will give us a better WordPress.

     
    • Tammie 12:18 pm on March 31, 2016 Permalink | Log in to Reply

      “Discovery and Design First”… this entire section made me so happy. Totally agree and look forward to this being in more areas.

      I would like to put myself forward to help with any discovery anyone in any feature project needs. I know there are going to be people in some projects that will be up for it too, but happy to help or pass on what I know about discovering to others too. My offer is also there for those that either want more help or don’t have it in the project currently.

    • J.D. Grimes 12:31 pm on March 31, 2016 Permalink | Log in to Reply

      I think this is a good direction to take the concept of feature projects. If only WordPress were more modular/composible, it would be even easier to develop new features and tweak existing ones.

    • Ryan Boren 1:34 pm on March 31, 2016 Permalink | Log in to Reply

      +1, cosigned, thank you

    • Michelle 1:47 pm on March 31, 2016 Permalink | Log in to Reply

      Love this, not only because it a) treats WordPress more like an actual product where decisions on features should be tested and vetted before they’re built, and b) validates the design and discovery process as “important to WordPress” and saves a ton of unnecessary dev time, but also c) will help encourage those with other important talents like design/ux/ui/user testing (but not core-level development skills) to contribute.

    • Ipstenu (Mika Epstein) 2:14 pm on March 31, 2016 Permalink | Log in to Reply

      Development should take place where it is most logical for the project. Yes! Helen, you sing the song of my people. Thank you. This is a good start and direction for feature projects 🙂

    • Morten Rand-Hendriksen 2:45 pm on March 31, 2016 Permalink | Log in to Reply

      This is great, in particular the Discovery + Design component (which for reference was implemented and heavily criticized in ImageFlow). Building features that are user-centric is paramount as we move forward.

    • Josh Pollock 9:16 pm on March 31, 2016 Permalink | Log in to Reply

      The one really great thing about feature plugins is it makes it really easy to test a feature plugin. You just install that plugin. What would be the equivalent for testing a feature project? If the answer is “apply a patch in git or svn” then I think this will drastically reduce participation by users who are not active contributors, and that concerns me.

      • Helen Hou-Sandi 9:33 pm on March 31, 2016 Permalink | Log in to Reply

        Development may take the form of a plugin, a patch on a core ticket, or whatever way works best for the specific feature project.

        I imagine most projects will still result in plugins when it comes to implementation. This is a reframe, not a replacement. That said, it’s very important that testing happens earlier in the process; testing functionality is sort of meaningless if we haven’t determined the direction.

        • Josh Pollock 9:41 pm on April 1, 2016 Permalink | Log in to Reply

          Ok, that makes sense. Thanks for the clarification.

          I wonder if it makes sense, for projects that are maintained as patches, to provide an easy/ automated way to maintain an updated fork of WordPress with that patch applied that people could test with…

    • Mike Selander 7:42 am on April 2, 2016 Permalink | Log in to Reply

      I love the idea of treating these improvements as a scoped project in and of itself – I think that it will lead to better considered and architected solutions. This is a great path for future features!

    • Torsten Landsiedel 3:28 pm on April 3, 2016 Permalink | Log in to Reply

      This is a great idea, but I think we need much better communication at this point. Where do I get feedback to my feature project idea(s)? At the moment we have this “sorry, wrong channel, try it at xy” and after “too many redirects” people lose their motivation to help anymore. Or the wrong type of people give feedback and the idea is dying, because the right people don’t give any feedback even if the comments just show “+1s” …

      • Samuel Sidler 12:51 am on April 4, 2016 Permalink | Log in to Reply

        As the post says, going forward there will be meetings every two weeks to propose and get feedback on feature project ideas. Those meetings are the perfect time to get feedback on your idea(s).

    • Aaron Jorbin 6:55 pm on April 4, 2016 Permalink | Log in to Reply

      Love this direction and really excited to help provide feedback. I’m wondering if it may make sense to rotate the time a bit in the long run( Perhaps every two months?) or potentially add in a second meeting during a different time of the day. There is no time that will be perfect for everyone, but 1700 UTC is 2am in Tokyo, 5am in Aukland and 10:30pm in Mumbai.

      • Ryan McCue 11:49 am on April 6, 2016 Permalink | Log in to Reply

        Absolutely agree. There’s no way I can viably make a meeting at 3am. Maybe multiple to accommodate differing timezones, or alternate the time for each meeting?

      • Helen Hou-Sandi 8:13 pm on April 6, 2016 Permalink | Log in to Reply

        I agree about differing times and think alternating is a great idea. I have a little bit of an odd schedule, so perhaps keeping one at 1500 UTC and the other (including the next one) at 0100 UTC? The latter makes the date kind of weird (would be Wednesday technically) but seems like it’s okay.

  • Helen Hou-Sandi 7:56 pm on December 9, 2015 Permalink
    Tags:   

    Welcome the 4.5 class of committers! 

    As announced in the State of the Word this year at WordCamp US by @matt, there are seven new committers to introduce.

    Many of you have seen Michael Arestad‘s (@michaelarestad) design and front-end development contributions over the last couple of years, notably with the redesign of Press This in WordPress 4.2. His numerous, high quality contributions are a welcome addition to core. I personally am looking forward to his work on markup and styling, having relied heavily on his judgment for quite some time now.

    WordPress 4.4 adds a new embed feature to WordPress, making it an oEmbed provider for the first time. Work on this new feature was done in a large part by Pascal Birchler (@swissspidy), who has been doing great work for the past few releases. Pascal’s clear communication and thorough support of the flow mindset are things we can all be inspired by.

    Rachel Baker (@rachelbaker) is the co-lead of the REST API, a Comments component maintainer, and a major contributor to WordPress 4.4. Her work has made it possible for sites around the world to utilize the REST API, making WordPress a great application platform. Look for more of these contributions as the REST API iterates within core.

    Likewise, Joe Hoyle (@joehoyle) is a major contributor to the REST API. As we prepare to commit the REST API endpoints in an upcoming WordPress release, there will be more and more to come from both him and Rachel.

    As a Media component maintainer and a long-time contributor across many components and features, Mike Schroder (@mikeschroder) helped shepherd the responsive images feature plugin into core for WordPress 4.4. He was also a backup release lead for WordPress 3.9.

    Throughout the WordPress admin interface, everywhere you look you’ll see the work of Mel Choyce (@melchoyce). Her design and experience contributions are long-standing and have benefited the entire ecosystem. As one of the maintainers of the Dashicons project, the icons you interact with daily are a big part of her contributions, as well as themes available in the WordPress.org Theme Directory.

    Eric Andrew Lewis (@ericlewis) has been contributing in various forms for many years, exploring lesser-known areas, documenting them, and challenging assumptions. Most recently, you may have seen his work as a Media component maintainer or with the shiny updates feature in WordPress 4.2.

    Additionally, Ella Van Dorpe (@iseulde), Konstantin Obenland (@obenland), Weston Ruter (@westonruter), Tammie Lister (@karmatosed), Andrea Fercia, (@afercia) and Ryan McCue (@rmccue [that’s one M, two C’s]) have all had their guest commit renewed.

    Please join me in welcoming this great set of new committers!

     
  • Helen Hou-Sandi 7:37 pm on December 9, 2015 Permalink
    Tags:   

    Announcing the release leads for 2016 

    As announced during the State of the Word this year, we have a brand new selection of release leads for 2016.

    Mike Schroder
    Previously a co-lead for WordPress 3.9 and long time contributor, Mike Schroder (@mikeschroder) will kick off the year as the release lead for WordPress 4.5.

    Dominik Schilling
    Following WordPress 4.5, Dominik Schilling (@ocean90) will be the release lead for WordPress 4.6. Dominik has been a core committer for a couple of years now and was a backup release lead for WordPress 4.4.

    Matt Mullenweg
    Finally, closing out the year, Matt Mullenweg (@matt) will put on his release lead hat and lead WordPress 4.7. Matt previously led the WordPress 3.8 release.

    Each of these release leads need your help! Every release is made by hundreds of contributors over many months, not just by its release lead. Additionally, every release lead needs a backup lead or two to help ensure the release moves forward at a solid pace. These backup release leads get great training for the real deal, as they often become future release leads (see both Mike and Dominik above!).

    Are you interested in being a backup release lead? Just comment here to let Mike, Dominik, and Matt know.

     
  • Helen Hou-Sandi 1:56 am on November 27, 2015 Permalink
    Tags:   

    Coming up: 2015 Community Summit 

    The 2015 community summit is next Wednesday and Thursday, December 2–3. There were a lot of great discussions last year, and I look forward to more this year and planning next steps for core.

    Ahead of the community summit, the lead developers and committers are getting together to discuss a few overarching ideas, including project vision, core features (existing and future), code and contributor infrastructures, and the competitive landscape. The goal isn’t to dictate what comes next for WordPress. It’s unlikely that 20 fiercely independent and stubborn minds would come to a deep agreement in just two days, anyway. 😄 Rather, this initial smaller meetup will aim to bring some specific ideas to the community summit to encourage productive, focused workshopping and tangible outcomes.

    Unconference Day

    The first day of the community summit is an “unconference” day, where topics are proposed and discussed by groups. This day is meant for in-person interaction and a chance to talk through things that may be more sensitive or controversial. Like previous community summits, only session note takers should be using electronics. We all need to be able to feel comfortable having frank discussions without worrying about quotes or other snippets being posted publicly without context.

    Topics will be wide-ranging and not necessarily focused on core; any attendee can participate in any topic. If you’re an attendee, you can suggest topics ahead of time in the community summit forum. Some additional topics may be collated from the committer meetup. Here are the notes from the 2012 summit and the CSS roadmap that came from the 2014 summit as examples.

    There will be four 50-minute session slots and 8 group seating areas, with the possibility of doing smaller breakout groups on a related topic (e.g. component roadmaps) during a session. Each unconference session should produce notes and at least one action item. At least a few of those action items should be things that can be worked on the next day. Notes for core-related conversations will then be edited and posted here on Make/Core in the weeks that follow.

    Work Day

    The second day of the community summit is a work day. Here, we have two blocks totaling about six hours to fill, from 9:15 a.m. to 12:00 noon and from 1:30 p.m. to 4:40 p.m.

    Action items for the work day may include:

    • Improving documentation
    • Feature planning and roadmaps
    • Preparing for the Contributor Day on Sunday
    • 4.4 sprint, if necessary

    What’s on your mind?

    What things do you think we should discuss and work on at the community summit? Be sure to propose unconference topics on the community summit forum. Mention any potential work day items in the comments below, keeping in mind that it is six short hours with a limited number of people.

     
    • Justin Sternberg 3:51 pm on November 30, 2015 Permalink | Log in to Reply

      I propose some improvement to the REST API docs. There is definitely confusion around V1 vs V2, what is in core, what value the plugin brings, what can/can’t be done with the current in-core implementation, etc.

  • Helen Hou-Sandi 6:33 pm on November 24, 2015 Permalink  

    Let’s do a scrub to push through the remaining 4.4 tickets on 3:00 PM EST so we can get to RC tomorrow, Wednesday the 25th. Please take a look through those tickets and review what remains to be done, test patches as applicable, and patch/comment where you’re able. See you in #core in about 1.5 hours!

     
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
Skip to toolbar