WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from Samuel Sidler Toggle Comment Threads | Keyboard Shortcuts

  • Samuel Sidler 8:13 pm on September 16, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Feature Plugin Chat on September 23 

    Last week we mentioned holding a feature plugin chat today, but that didn’t happen. Let’s have it next week on September 23 2014 20:00 UTC.

    We’ve done this before, but just to recap…

    If you have an idea for a new feature, this will be a great opportunity to bring it up and find others interested in helping out.

    Please leave one comment per feature idea with the following information:

    • A brief (one paragraph) overview of your feature plugin proposal.
    • Current plugin status (idea stage, planning stage, under development, existing feature plugin, prior work, etc).
    • A list of those involved or already interested in your feature plugin (including you!)
    • What you’d like help with (scoping, planning, wireframing, development, design, etc).

    This post and the accompanying chat are for posting ideas that you’d be interested in working on. It is not for posting every feature idea you have for WordPress.

    Current feature plugin leads: Please post an update for your plugin here, along with the information above.

    See you all at the chat!

     
    • Nikola Nikolov 10:08 pm on September 16, 2014 Permalink | Log in to Reply

      The meeting is going to be held in #wordpress-dev channel right? I’m adding the time & date to my calendar :)

    • Caspar 5:35 am on September 17, 2014 Permalink | Log in to Reply

      Added to calendar, thx!

    • Peter Luit 7:35 am on September 17, 2014 Permalink | Log in to Reply

      In general the installation of plugins will have to be done on a site-by-site base. It would be very nice to have the possibility to have pre-defined sets of plugins for certain applications. Now we can just ‘favorite’ a plugin at wordpress.org, in others words ‘you make one set’. Would it be a nice idea to be able to make more sets?

      It could be done in wordpress.org, but it would also be great to have one plugin-installer (as a plugin) in which you can choose one of your own pre-defined sets and then download them all…..

      I am sure the WordPress community would love such a feature.

      Kind Regards,

      Peter Luit
      The Netherlands

  • Samuel Sidler 4:37 pm on April 28, 2014 Permalink
    Tags:   

    Feature Plugin Chat tomorrow 

    As mentioned at the dev chat last week, we’re having a feature plugin chat tomorrow, April 29, 2014 20:00 UTC in #wordpress-dev. That’s the same time, same place as the dev chat on a different day. (The dev chat will take place on Wednesday, like normal.)

    Just like we did before, post your feature ideas here in one comment with the following information:

    • A brief (one paragraph) overview of your feature plugin proposal.
    • Current plugin status (idea stage, planning stage, under development, existing feature plugin, prior work, etc).
    • A list of those involved or already interested in your feature plugin (including you!)
    • What you’d like help with (scoping, planning, wireframing, development, design, etc).

    Again, this post and the accompanying chat is for posting ideas that you’d be interested in working on. It is not for posting every feature idea you have for WordPress.

    Current feature plugin leads: Please post an update for your plugin here, along with the information above.

    We’ll go through current feature plugins at a brisk pace, then talk about the new ones that are forming.

    See you tomorrow!

     
    • mttktz 6:38 pm on April 28, 2014 Permalink | Log in to Reply

      I think WordPress lacks a feed reader.

      If you look at the most popular new blogging platforms: Facebook, Twitter, Tumblr, etc, they all have a way for you to see what others are writing and then re-blog or re-share that info. It’s a key feature that lets people communicate with each other. I’d like to see WordPress do this well, to have a feed reader integrated into the admin site with the ability to blog and comment on what you are reading in the world. It’s a feed reader with integrated “PressThis!”

      I’ve made a rough edged version of this plugin that works and people have started using it without me promoting it at all.
      See: http://mattkatz.github.io/Orbital-Feed-Reader/

      It’s just me working on it so far.

      I’d love help with design and development. Any advice appreciated – I think this is a big feature for WordPress-as-blog rather than WordPress-as-CMS.

      • Tomas Mackevicius 3:03 pm on May 1, 2014 Permalink | Log in to Reply

        Good idea! Are you using internal SimplePie library to produce the feed? I noticed that if it takes a bit more time to get the complex feed (I was trying to parse Yahoo Pipes feed), SimplePie would render an empty page with an error message :(

    • Ryan McCue 3:12 am on April 29, 2014 Permalink | Log in to Reply

      The JSON REST API is marching towards 1.0, with all the pieces beginning to fall into place. We want in on 4.0, and we’re determined to merge this cycle. :)

      For anyone who hasn’t seen the project, we’re working on providing a JSON-based API to access all your data in WordPress. Work on the project is happening over on GitHub, and we chat about the project over on our o2.

      We’re always seeking people to help, and we’d especially love some designers to help out with some UI pieces. If anybody’s using the API, we’d also love to hear about that and your experiences with using it!

      (I’ll endeavour to be present at the meeting tomorrow, however if I don’t make it, Rachel Baker will be present on the team’s behalf.)

    • Manny Fleurmond 3:58 am on April 29, 2014 Permalink | Log in to Reply

      I know the that the last time the post formats feature was proposed to get an overhaul there were kinks and setbacks to be had. My proposal, which might be a bit controversial, is this: instead of post formats being lumped together with the main post type, I believe they should be split up into their own post types.

      I wrote a blog post a few months ago about this a few months ago but to sum it up: I think post formats are an arbitrary distinction that causes confusion to WordPress users. They are technically types of posts, so why can’t they be post types? My proposed set of features is as follows:

      1. The ability to allow individual formats to be enabled/disabled
      2. The ability to allow individual formats to be included or excluded from the main loop.
      3. Rework the quickdraft meta box on the dashboard to allow the choosing and quick posting of different post formats, using some of the old code/interface from the last attempted redesign
      4. They should be extensible, via the new meta field initiative
      5. Stricter definitions of said post formats.

      I’ve only done some brainstorming, specifically with the more media based formats, which I plan to enhance via some of the new media modals now available since WP 3.9 (audio, video and playlists). That being said, I would love feed back in planning and developing such a plugin. I think that this would help make post formats a lot more accessible and less confusing.

    • trishasalas 12:24 pm on April 29, 2014 Permalink | Log in to Reply

      Admin Help is in the initial stages of project scope and planning. Our goal is to make the WordPress Admin area easier, and more intuitive to use and to hopefully reduce the attrition rate in the process. The focus is on the existing Admin Help documentation with the knowledge that it could be completely re-written or morphed into a more intuitive UI. The idea of a tour has been mentioned many times in the past, but we are beginning with user testing to make sure that we solve the correct ‘problem’.

      We are currently in the planning stage doing user-testing, personas, storyboards and discussion. Project scope is also a focus because we want to keep the initial idea at a manageable level (i.e. we do *not* want to re-do the entire admin area!)

      Those currently involved include myself (@trishasalas) and @clorith as co-leads, @jazzs3quence, @ubernaut, @brainfork and @jerrysarcastic. @designsimply is helping with user testing.

      Our biggest need is to have more people familiar with user help/user support and those who are familiar with UI/UX design. The more input we have during the initial planning stages, the more successful we’ll be.

    • Svetoslav Marinov 12:58 pm on April 29, 2014 Permalink | Log in to Reply

      Hi,

      Plugin: Orbisius Quick Nav
      Info: This plugin allows you to quickly switch between pages, posts, or any other custom post types from a dropdown.
      Status: up and running at http://wordpress.org/plugins/orbisius-quick-nav/
      Who is involved: just me (but I am both using my personal and company WP accounts)
      Need help with: ideas people, testers and programmers.

      Slavi,
      http://Orbisius.com

    • Michael Arestad 6:50 pm on April 29, 2014 Permalink | Log in to Reply

      Press This is a redesign with a focus on automation and speed. It will have a simplified interface, efficient media upload, and site switching.

      The plugin is currently in the idea stage You can see discussion and progress at corepressthis.wordpress.com

      I am the project lead (@michael-arestad) and those who are involved or have shown interest are:
      @melchoyce, @bilalcoder, @danielbachhuber, @folletto, @georgestephanis, @helen, @ryelle, @morganestes, @ryan, @stephdau

      If you’re interested in contributing, ping one of us on IRC and we’ll add you to the Skype Group and blog.

    • Dave Navarro, Jr. 7:51 pm on April 29, 2014 Permalink | Log in to Reply

      Native support for mobile platform detection is critical, in my opinion. Check out the Mobble plugin (http://wordpress.org/plugins/mobble/) which adds functions for detecting the OS and device characteristics.

      Mobile web sites and Responsive web sites are NOT the same thing and right now we can create responsive sites with CSS, but we can’t create Mobile sites without help. A mobile site doesn’t just HIDE elements on mobile devices, it never even sends the data (like unregistering widget areas on mobile to prevent data from widgets being sent).

    • John Blackbourn 8:46 pm on April 29, 2014 Permalink | Log in to Reply

      I know I’m late but I’d like to look into improvements to user profile editing in core. I’ve recently looked at quite a few plugins which add the ability to upload an avatar in addition to Gravatar, and I’ve been looking at how WordPress.com does this, as well as how it separates the screens for managing your profile and managing your user settings.

      Current status: Idea and research stage.

    • shaunandrews 8:47 pm on April 29, 2014 Permalink | Log in to Reply

      Sorry for the late reply, I wasn’t sure if I could make the meeting today (which is in progress), but I wanted to mention that there’s a group of people working on the media-grid plugin: https://make.wordpress.org/core/2014/04/22/remember-the-media-grid-project-it-was-original/

      We had a single meeting (which I also missed, due to being a fool and confusing timezones), and are just gearing up. I’m @shaunandrews) planning to lead the project, and we have @helen, tillkruess, caseypatrickdriscoll, jcastaneda, kopepasah, klihelp, and ericlewis all showing interest in helping.

      We’ve got a GitHub repo: https://github.com/helenhousandi/wp-media-grid-view/

      I’m considering setting up a WordPress.com blog and/or a group Skype chat to help keep us all connected. Hit me up on Skype (shaun.andrews) or email (shaun@automattic.com) if you’re interested in helping.

      • Dave Navarro, Jr. 9:31 pm on April 29, 2014 Permalink | Log in to Reply

        Would love to see the ability to use a Taxonomy (separate from categories) to better organize media. I have sites with 10’s of thousands of media items and it’s a PITA to browse all that.

        • shaunandrews 12:22 am on April 30, 2014 Permalink | Log in to Reply

          Some sort of grouping (or, collecting) is in our plans, but its too early to know how that’ll shape up. If you have any specific thoughts on the matter, please feel free to share :)

    • pressupinc 9:13 pm on April 29, 2014 Permalink | Log in to Reply

      I’d like to build a version with more consistent written tone that is less colloquial–especially around error messages (e.g. “Are you sure you want to do this?” and the default 404).

      I have a few people interested in work on the project, and have done a survey to see what tone most community members would like to see.

      • John Blackbourn 10:17 pm on April 29, 2014 Permalink | Log in to Reply

        This has been brought up before. If you have a search through Trac you’ll probably find a couple of tickets relating to changing of phrases in core. Do you have a link to your survey?

        That said, this isn’t related to feature plugins. A better place to discuss it would be in a ticket on Trac.

    • vivekgounder@gmail.com 1:53 pm on May 1, 2014 Permalink | Log in to Reply

      Congrats Helen :)

  • Samuel Sidler 10:22 pm on March 19, 2014 Permalink
    Tags:   

    GSoC Chat Tomorrow 

    For those interested in Google Summer of Code, we’ll be holding a chat tomorrow on IRC in #wordpress-gsoc, March 20, at 18:00 UTC (2pm EDT, 11am PDT). Bring your proposal along and you’ll have five minutes to talk through your proposal with mentors. We’ll try to fit everyone.

    If you haven’t already, be sure to submit your proposal as soon as possible. There’s not much time left to get feedback prior to the submission deadline! Keep in mind that you can modify your proposal up until the deadline.

    See you all tomorrow!

     
    • Andrew Nacin 10:25 pm on March 19, 2014 Permalink | Log in to Reply

      The deadline is Friday, March 21 at 19:00 UTC..

      Worth pointing out that you can edit your proposal after it is submitted, up until the deadline. After that, you can still comment on your proposal, such as if any mentors ask you questions.

  • Samuel Sidler 4:40 pm on February 27, 2014 Permalink
    Tags:   

    Feature Plugin Chat on March 4 

    As mentioned at this week’s and last week’s meeting, we’re going to be holding a feature plugin chat on March 4 2014 21:00 UTC. If you have an idea for a new feature, this will be a great opportunity to bring it up and find others interested in helping out. In fact, just like we’ve done before, post your feature ideas here.

    Please leave one comment per feature idea with the following information:

    • A brief (one paragraph) overview of your feature plugin proposal.
    • Current plugin status (idea stage, planning stage, under development, existing feature plugin, prior work, etc).
    • A list of those involved or already interested in your feature plugin (including you!)
    • What you’d like help with (scoping, planning, wireframing, development, design, etc).

    This post and the accompanying chat is for posting ideas that you’d be interested in working on. It is not for posting every feature idea you have for WordPress.

    Current feature plugin leads: Please post an update for your plugin here, along with the information above.

    See you all at the chat!

     
    • scotthack 4:52 pm on February 27, 2014 Permalink | Log in to Reply

      I’d like to see a plugin built that will accept an XML file to import custom post types and taxonomies. That way theme authors can just provide an XML file with their themes. Then the end user can use the import file to create custom post types and taxonomies and it would be imported independent of the theme.

      This is in the idea stage. My coding skills are very basic, so I’d be of little to no help in the coding department. It would need to be picked up by a competent programmer to actually see it through. I’m only able to help with testing, feedback, and idea conception.

    • UaMV 5:33 pm on February 27, 2014 Permalink | Log in to Reply

      Extend proper author/contributor support when defining custom post types. Currently, when a CPT is registered with support for ‘author’, the metabox returns a list of users with the author role (even if those users don’t have ‘edit_posts’ capability for the CPT. Even in the standard post editor, the author metabox includes only users with an author role, not necessarily those who can contribute (or have edit_posts capability). I believe this metabox should return any user that has the ‘edit_posts’ capability for the specific post type in which the author metabox is being supported.

      There is currently a plugin, Authors Autocomplete Meta Box, in the repository that extends this functionality.

      Rachel Carden (aka bamadesigner) is the author of this plugin (commissioned by ereleases.com). I have, as of yet, had no contact with her regarding the plugin, but find it of great use on my site with multiple CPTs and multiple custom roles.

      Not sure at the moment how I might assist.

    • Janneke Van Dorpe 6:36 pm on February 27, 2014 Permalink | Log in to Reply

      The Front-end Editor is a plugin that allows posts to be edited on the front-end (so it’s really WYSIWYG) and aims to have all the features available that the back-end editor has.

      It’s currently in development on GitHub and updates a posted weekly on the UI blog.

      I’m the project lead (@avryl) and those who are involved or have shown interest are @azaozz, @brainstormforce, @bravokeyl, @gcorne, @helen, @henrywright, @hugobaeta, @joen‎, @kraftbj, @markjaquith, @melchoyce, @mrahmadawais, @obenland, @protechig‎, @rafaelxt, @rhurling‎, @roundhill, @samuelsidler, @shaunandrews, @tillkruess, @ubernaut, @wholegraindigital and others.

      If you’re interested, take a look on GitHub and join our Skype chat (add jannekevandorpe). The next meeting will be Tuesday, 4 March 2014, 17:00 UTC in #wordpress-ui.

    • Chris Reynolds 12:46 am on February 28, 2014 Permalink | Log in to Reply

      AH-O2 (aka Admin Help) is venturing to reimagine the help system in the WordPress admin.

      It’s currently in development is on GitHub with updates being pushed weekly to the WordPress plugin repository. Updates are posted to the Docs and UI P2s.

      I’m the project lead (@jazzs3quence) and other contributors and folks who’ve been involved one way or another are:
      @brainfork, @trishasalas, @jdgrimes, @ubernaut, @zoerooney, @ninnypants, @mdbitz, @clorith, @nikv, and @veraxus

      We need help with:

      1. Documentation — new tooltips are being added to every admin page. Coders (the folks adding them) != writers, so many of these need to be (or will need to be) reviewed, fixed, updated or written. Also, it’s been pointed out that the help overviews we’re building — which replace the help tabs — may not be best suited for the existing documentation in the help tab (which we’re currently pulling from). So help documentation for those areas may need to be edited/changed/added/removed/etc.
      2. Coders — tooltips are added with javascript (and a little php, just to add the translatable string) but fear not! It’s really easy and repetitive. With about 10 minutes of guidance I think I can walk just about anyone through the process of adding a tooltip.
      3. Testers — please break our stuff (and create tickets)! https://github.com/jazzsequence/WordPress-Admin-Help/issues
      Also, extra brownie points to anyone who can test existing, open tickets to confirm/deny a behvior that has an open ticket.

      We meet weekly in #wordpress-sfd on Monday 18:30UTC.

    • Greg Ross 7:50 pm on March 4, 2014 Permalink | Log in to Reply

      The Admin Theme Experience is an update to the existing admin theme system to try and match the site theme user interface. It has two primary goals; simplify the creation of admin color themes and bring the Site Theme Experience to admin themes.

      Current plugin status: under development

      A list of those involved or already interested in your feature plugin: Me!

      What you’d like help with: Anyone with knowledge of the current site theme code would be helpful.

  • Samuel Sidler 11:27 pm on October 22, 2013 Permalink
    Tags: ,   

    Preparing your feature for the 3.8 merge 

    Now that 3.7 RC has shipped – and the final release is coming soon – it’s time to talk a bit more about how merging to core will work for feature plugins. First, let’s talk about decisions.

    Decisions

    I’ve been asked a few times “who decides” what goes in core and variants of that question. There’s actually three decisions that need to get made. In order:

    1. Does the feature belong in core?
    2. Is the feature ready for core?
    3. Should the feature be in this release?

    Core contributors and members of the community are strongly encouraged to help inform and guide each of these decisions. You may even want to offer some of your feedback in the form of answers to these questions. Each question is ultimately answered by a different group.

    1. Project leaders determine if a feature belongs in core.
    2. Contributing developers determine if a feature is ready for core.
    3. The release lead – for 3.8, @matt – determines if a feature belongs in a particular release.

    We’re now at the point where these questions need to get answered. To do that, it’s time to present your feature plugins.

    Present Your Feature

    If you remember back when we first started the feature plugin process, each team had to present its feature idea and answer a few questions. We’re going to do that again, but with a bit more information. If your project thinks it’s ready for core – and specifically for 3.8 – your team lead should make a post to make/core with the following information:

    • A visual and written overview of your feature plugin, along with a link to your plugin.
    • What problem is your feature plugin trying to solve?
    • What brought you to this solution and what other potential solutions did you explore?
    • Have you done user testing of your feature plugin? If so, what were the results? What worked and what didn’t?

    In your post, be sure to include links to previous posts and even specific comments that have helped form your decisions.

    Be ready for feedback from across the WordPress community – especially UX and code quality  – and be ready to defend your decisions or change your mind if a better idea emerges. Everyone will be reviewing the make/core posts and feedback in their discussion threads to determine if the answers to the questions above are all “yes”. If so, the feature can land when the merge window opens.

     
  • Samuel Sidler 7:15 pm on September 30, 2013 Permalink
    Tags: ,   

    Making preparations for 3.8 

    As mentioned previously, 3.8 development officially opens shortly after 3.7 ships. With the first beta of 3.7 behind us and the final release scheduled for mid-October, it’s time to talk about what’s expected of feature plugins.

    @nacin mentioned at last week’s dev chat that 3.7 will likely branch at the WordCamp Europe contributor day, on October 7. At this point, most core developer focus will be on shipping 3.7. However, feature plugins that want to be considered for 3.8 should be ready by October 14 to give everyone time to review them.

    What does being ready mean? Here’s what will be examined:

    • a strong and well-tested user experience
    • fully-baked design
    • positive feedback from the community
    • core-quality code
    • no major bugs or issues
    • a belief that the feature belongs in WordPress core

    Some of the above is subjective and will vary from feature to feature. If you have questions, look to a lead developer for guidance.

    Of the feature plugins listed, the furthest along are MP6 and global admin search, with Dash not far behind. Plugins in the “feedback” stage should be prepared to answer the question “Why should we include this in core?” As of today, they should prepare their code for core, removing anything unnecessary and making the feature into a patch that can be easily merged with core.

    tl;dr

    • Feature plugins wanting consideration for 3.8 should be ready for presentation and inclusion by October 14.
    • Feature plugins will undergo review shortly after 3.7 ships.
    • Plugins must be ready to merge when the merge window opens.
     
    • Weston Ruter 7:24 pm on September 30, 2013 Permalink | Log in to Reply

      We’ve also been making great strides with the Widgets UI Refresh, specifically with the customizer integration (from my perspective). The plugin project for this is Widget Customizer, and development is happening on GitHub. I’m hoping that we’ll have the remaining issues addressed by October 14th.

      /cc @shaunandrews

      • Bryan Petty 8:06 pm on September 30, 2013 Permalink | Log in to Reply

        Hi Weston, it appears like the widgets team working on this decided to switch the plugin being used for development on this effort entirely just 6 days ago… this shouldn’t happen honestly. If your team has decided on a direction to go in, it should be integrated back into the officially tracked plugin as listed on the core plugin tracking page.

        That aside though, it’s usually a good sign that the plugin is not really “ready for core” when major decisions like that are being made even in the last week here. Nothing new there has had time to be discussed, tested, and generally baked – and it’s really hard to get that feedback when development isn’t even being done on the official plugin where it’s supposed to be.

        • shaunandrews 11:57 pm on September 30, 2013 Permalink | Log in to Reply

          We haven’t switched. We’re developing multiple concepts and testing them simultaneously.

          That being said, I don’t think we have (or will have) “a strong and well tested user experience” by October 14.

        • Weston Ruter 5:28 am on October 1, 2013 Permalink | Log in to Reply

          OK, thanks. I’m obviously over eager. Sorry to jump the gun.

    • Jonatan Santos 8:32 pm on September 30, 2013 Permalink | Log in to Reply

      One point that could be seen would be a button to turn the text to uppercase and minuscule vise versa in menu text editor

      • Mark-k 3:43 am on October 1, 2013 Permalink | Log in to Reply

        As far as I know non latin langs, which are used by more people then latin ones, don’t have uppercase/lowercase distinction, therefor IMO this kind of feature should not be in core

    • Mufasa 4:22 am on October 2, 2013 Permalink | Log in to Reply

      It’d be really great if there was a way to collapse menus in 3.8 (or 3.7). If you look at the following image you can see that in order for me to drag the menu at the bottom to the top I have to do quite a lot of dragging.

      If I could collapse the encyclopedia menu so that I can’t see all those children it would be useable… well if the page didn’t grind to a halt with that many menu items it would ;)

      So I was thinking you could either have a button to collapse them OR when the user starts dragging they close. Which is something we executed in another app and its quite nice to use. I’ve thought the same UI would be nice on the widgets admin page too.

      Thoughts?

      Menu Pain: http://files.kiwijs.org/dan/arghhh.jpg

      • Sam Sidler 5:01 am on October 2, 2013 Permalink | Log in to Reply

        I’d recommend filing a ticket (perhaps there’s already one on file). Fixing that in the way you suggest isn’t something that would be covered by a feature plugin, though there was a (now on-hold) proposal for merging pages and menus.

  • Samuel Sidler 9:35 pm on August 27, 2013 Permalink
    Tags: ,   

    WordPress 3.8 agenda for tomorrow 

    Our next WordPress 3.8 chat is tomorrow, August 28 at 21:00 UTC, following the 3.7 dev chat. Here’s our agenda:

    • Answer questions/comments about the features as plugins process (see yesterday’s post).
    • Review projects with no lead or weekly chat.
    • New feature presentations. Is there a new feature you want to work on that’s not being tracked? Now’s the time to present it. Bring as much information as possible and comment on this post beforehand.
    • Office hours.

    Hope to see all of you tomorrow!

     
    • Charleston Software Associates 3:24 pm on August 29, 2013 Permalink | Log in to Reply

      I am new to the make/core process but would like to start contributing to improving WordPress. I have some “contributor newb” questions:

      • Is creating a Trac ticket the best way to log new concepts for the admin UI?

      Assuming the answer is yes…

      • Is there a way to get Trac to show me more than 10 results at a time?

      I want to log my “wish list items” while working with WordPress over the next couple of weeks. For example:

      • Admin tables Infinite Scroll
      • Adding “delete permanently” w/ “are you sure?” confirmation to bulk actions (skipping trash = one less step in some cases)
      • Adding a page length option to admin tables v. the fixed 20 items limit.

      I’m not clear on the process, but thought it should start with a formal enhancement ticket in Trac. That at least organizes the wish list so myself, or another code geek, can come back and create a MP6-like plugin for a future release of WordPress.

      My other thought was a GitHub / Bitbucket project with an independent issues list, but that just feels wrong as it fragments the community and efforts to improve core. However I can see the benefit of not filling up trac with concepts, many of which do not belong in core.

      Maybe a new “wishlist” Trac?

  • Samuel Sidler 6:12 am on August 27, 2013 Permalink
    Tags: ,   

    Features, Plugins, and WordPress 3.8 

    At the dev chat last week, we talked a bit about WordPress 3.8 and the features-as-plugins process. Here’s a recap of what was discussed:

    Expectations

    A lot of features are in development right now, at varying stages. Given the huge list of new features, there’s no way they’ll all be in WordPress 3.8. That’s okay, and it’s by design.

    The features-as-plugins model makes it easy to wait for a feature to be ready before including it in a release. It also allows for a lot of experimentation. Some ideas might not otherwise be developed into potential features, while others are large and complex, and might take multiple cycles to complete. But experimentation can lead to a fully scoped or even fully developed feature that never makes it into core because, after hashing out the details, it’s realized it isn’t something that belongs in core. Don’t let that discourage you — trial and error is part of the process and will result in better features and a better WordPress. Features that don’t get included in core can continue to live on as awesome plugins, and the whole ecosystem benefits. In the past, the core team would have suggested that a feature start as a plugin anyway; this formalizes that process.

    Ultimately, the decision on whether a feature makes it into core rests in the hands of the core team. To ensure you’re on the right track, keep in contact with the next release’s lead and the lead developers. The release lead should understand what problem you’re trying to solve and why the direction you chose is the appropriate one to solve that problem.

    Timeline

    For features to be included in a release, they must be ready for the release’s first meeting — that is, day one when the development period begins. At that point, the release lead will review current projects, and along with core developers, determine if they’re fully baked and ready for merging into core.

    They’ll be looking for a number of things, including a strong and well-tested user experience, fully-baked design, positive feedback from the community, core-quality code, no major bugs or issues, and a belief that the feature belongs in WordPress core. Every feature is different, so “ready” will mean different things depending on the specific feature, but a release lead must feel comfortable taking on primary responsibility for a feature and the core team must be comfortable taking on responsibility for the long term.

    If the core developers decide a feature isn’t ready for core, they’ll let the feature lead know why and what can be done to prepare the feature for a future release.

    Features that have been approved for inclusion will have a merge window of about two weeks (timeline still being decided) to get their code into core and wrestle with any latent issues getting it merged. However, as stated above, features must be ready for merging at the start of the merge window.

    Who’s responsible for features?

    After a feature gets merged into core, the feature team remains responsible for the feature, with added support from the core team. As with any part of WordPress, feedback comes from the entire community. However, after merging into core, a feature will receive a lot more visibility than in the plugin phase. Focus is important to ensure the feature ships.

    Keep in mind that while the team remains responsible for the feature in core, ultimate decision-making rests in the hands of the core team, as with any part of core. The release lead will obviously work closely with the feature lead and entire team.

    tl;dr

    • Sometimes features won’t end up in core. That’s okay! Not everything belongs in core. It’d still be a great, community-built plugin that helps to improve the ecosystem. Maybe it serves as a prototype, or lessons learned, or even a base for a future initiative.
    • Don’t expect your feature to make it for 3.8. These are features being built with the potential for inclusion in a future version of WordPress. They are not “3.8 features.”
    • To be included in 3.8, features must be “ready,” as defined by the core team, at the start of 3.8 development, shortly after 3.7. Be sure to keep in close contact with the release lead.

    Questions? Comments? Ask away!

     
    • Tom Auger 1:43 pm on August 27, 2013 Permalink | Log in to Reply

      I’m having trouble wrapping my head around features-as-plugins for one specific reason: many of the features we want to roll out require core modifications! How do you implement big changes to the way, for example, the Media Library or the Widgets work, without requiring changes to core, whether it’s additional hooks, or complete rewrites of certain sections?

      I may have missed something important here, but are we allowed to submit plugins that have core patches as required components?

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

        I think this is a great question. Essentially, our plugin architecture is so rich that it’s really easy. On occasion, a team may “fork” a JS or CSS file (don’t try this at home), or override an entire admin screen. There is also a procedure in place now for the leaders of these teams to ask a lead developer for a temporary hook as necessary. Basically, we don’t see this as much of an issue, especially since these plugins are going to be developed against trunk. Once the merge begins at the start of a release, we’ll massage things as necessary to make sure it is as much a part of core as it should be. But, it should be mentioned, a substantial amount of core just hooks into itself as if it is a plugin, including many newer features.

  • Samuel Sidler 3:47 am on August 16, 2013 Permalink
    Tags:   

    WordPress 3.8 Chat Wrap Up 

    The WordPress 3.8 chat ran a bit long today, but we got a ton of information on the projects people are interested in. I’ve compiled a list of features-as-plugins from the chat today to get a better handle on the status of each project. I may have missed some details, so let me know and I’ll update that page.

    If your group hasn’t already, do the following things before next week’s chat:

    • Setup a weekly IRC chat – ideally these should occur before the weekly 3.8 chat.
    • Use your weekly chat to select a lead. Keep in mind that your lead can change later if it needs to, just as MP6 has switched hands.
    • Create a wordpress.org plugin and use that page to list your group’s members, what you’ll be working on, and a link to all the relevant docs (including mockups). Add “wordpressdotorg” as a contributor to your project.
    • If you’re not yet at the stage where it makes sense to create a wordpress.org plugin, make sure you create a thorough overview document.
    • Each week you’ll want to post the status of your project to the relevant make P2.

    Other than that, see you August 22 at 18:00 UTC for the next 3.8 chat.

     
  • Samuel Sidler 11:15 pm on August 14, 2013 Permalink
    Tags: , ,   

    Present your 3.8 feature idea at tomorrow’s meeting 

    Tomorrow’s WordPress 3.8 meeting at Thursday 18:00 UTC is a great time to present your feature idea to the community. Many groups have already started forming around different ideas.

    Comment on this post with a group name to add your group to the list of projects presenting tomorrow. Make sure you bring the following things with you:

    • What problem(s) are you trying to solve?
    • What proposal solution(s) are you interested in exploring?
    • When and where is your group communicating?
    • Who has joined your group so far?
    • If you’ve selected someone to lead your group, who is your lead?
    • If you’ve already started work on your plugin, bring a link to your plugin page.

    See you tomorrow!

     
    • Matt Mullenweg 11:21 pm on August 14, 2013 Permalink | Log in to Reply

      And as many mockups / visuals / links to existing solutions as possible.

    • tomdryan 12:23 am on August 15, 2013 Permalink | Log in to Reply

      It’s not a feature per se, but is there a group looking at global usability improvements throughout WP that would make using WP a more pleasant experience, especially for new and casual users?

      I would happy to lead or participate in such a Usability group.

      • Sam Sidler 12:25 am on August 15, 2013 Permalink | Log in to Reply

        In general, I think you want the UI group. Minor usability updates can take place in any release cycle, including 3.7.

    • Justin Sternberg 12:31 am on August 15, 2013 Permalink | Log in to Reply

      I’m not ready to claim a big-picture group, but we at WebDevStudios have put some time and effort into re-thinking the admin’s widget admin page.
      A good post summarizing our vision, and some proof of concept mockups: http://webdevstudios.com/2013/08/14/webdevstudios-take-on-a-wordpress-core-widget-ui-refresh/
      Our p2 for discussion around the subject, open to the public:
      http://core.webdevstudios.com/
      A github repo with the skeleton of a plugin for iterating:
      https://github.com/WebDevStudios/WordPress-Widgets-Refresh

      There are also other discussions revolving around the subject both new and old.
      Shuan Andrew has some really intriguing thoughts & mockups and even a prototype:
      http://www.shaunandrews.com/
      & has posted a survey for the subject on this blog:
      http://make.wordpress.org/core/2013/08/14/howdy-everyone-theres-been-a-lot-of-discussion/

      Ipstenu has two posts discussing the subject (which we based a lot of our ideas on):
      http://make.wordpress.org/core/2013/08/08/excellent-3-8-brainstorm-session-today-people-talked-about/#comment-9697

    • shaunandrews 12:39 am on August 15, 2013 Permalink | Log in to Reply

      I’ve been thinking a lot about widgets, menu’s, post-formats-as-content-blocks, and a grid-view for the media library. A few links to share for tomorrow:

    • Konstantin Obenland 12:56 am on August 15, 2013 Permalink | Log in to Reply

      Featured Content.
      It is part of Twenty Fourteen and it would finally provide a canonical solution that is portable between themes. I talked to a lot of people in the last week, the group that has assembled around it is fairly impressive, and @wonderboymusic has already updated the base plugin with a first proposal.

    • Ryan McCue 2:30 am on August 15, 2013 Permalink | Log in to Reply

      JSON REST API.

      Working on it for now as part of GSoC, which means only I can write the core code for it at the moment, but there’s tonnes of extras around it that need doing until GSoC ends, and plenty of feedback to get at this stage. @japh, @jshreve, @mzaweb, @mordauk, @coenjacobs, @markoheijnen have all expressed interest in this for 3.8, plus @bpetty and @ericmann who are my current mentors.

      • Ryan McCue 2:35 am on August 15, 2013 Permalink | Log in to Reply

        GSoC’s pencils down date is September 23 (about 6 weeks away), which is when I’ll call the GSoC part done and move on to the core project part. In the meantime, anything out of scope is free game, including multisite, further JS API work, integrated unit tests, and any other new APIs (options? widgets?).

      • Japh 2:36 am on August 15, 2013 Permalink | Log in to Reply

        Yep, would love to get in on this one.

      • Andrew Nacin 3:13 am on August 15, 2013 Permalink | Log in to Reply

        I think this will need more time. Which, by the way, is completely OK. Let’s just be wary of saying “for 3.8″ — it should remain as a plugin until it and core are both ready.

        • Ryan McCue 3:58 am on August 15, 2013 Permalink | Log in to Reply

          Definitely. I’d like to push hard to get it ready for 3.8, but if it ends up slipping then that’s not a big deal, IMO.

        • Bryan Petty 3:58 am on August 15, 2013 Permalink | Log in to Reply

          Right, definitely, but worth mentioning that it could be awesome to see a large focus on this with a full team and lots of eyes.

          This probably should not be happening, but I know there’s at least one mobile project putting bets on this making good progress quickly.

    • Matías Ventura 3:19 am on August 15, 2013 Permalink | Log in to Reply

      Theme Experience for 3.8 and beyond, or THX38 for short.

      To significantly improve and re-imagine the admin theme screens for a better user experience. More beautiful, visually focused, fast, and up to date with the current times of mobile ubiquitousness, flexible resolutions and retina devices. Aiming to bridge the admin themes.php and the .org directory experiences, so that searching for and installing a theme is equally rewarding and consistent no matter where you start. Initial thread. Anyone who is up for this, please, chime in.

    • Mel Choyce 2:37 pm on August 15, 2013 Permalink | Log in to Reply

      Content Editing User Experience (CEUX)

      This group will be focused around streamlining and improving the overall content editing experience in WordPress. We’ll be exploring better methods for curating and formatting content within the post and page editors. We have a preliminary set of mockups that we’ll be expanding and iterating on as we start.

      Currently involved in this group are @wonderboymusic, @saracannon, @DavidHickox, and to a lesser extent @joen will be contributing feedback and ideas. We’ll also be communicating closely with the Page + Menu team. @jenmylo has graciously agreed to advise this group. We’ll be working out a time and place for meetings shortly.

      The content blocks plugin has been set up here.

    • jacob.dubail 3:47 pm on August 15, 2013 Permalink | Log in to Reply

      I was bummed that I missed the last 3.8 meeting. Hoping it’s not too late to get involved. See ya’ll online in a couple hours.

    • Siobhan 5:19 pm on August 15, 2013 Permalink | Log in to Reply

      Admin Help

      This group will focus on creating useful help for WordPress users within the admin. We’ll start by conducting research into the problems that users are having, and research into the tools available to us. We’re also looking into how other platforms implement admin help. Once we have identified the problem we will select the right tools and get to work with mockups then plugin. We have put together some specs for the project, started work on user testing, and looking at tools.

      So far involved in the group are: me, @trishasalas, @jazz3quence, the docs team, and we will be getting input from the accessibility team. Other people who expressed an interested are @japh, @ipstenu, @dllh, @JerrySarcastic, @kimparsell We’ve been using make/docs for discussions so far (under the admin help tag), and will set a regular time for meetings soon.

    • George Stephanis 6:08 pm on August 15, 2013 Permalink | Log in to Reply

      Omnisearch!

      jetpack.me/support/omnisearch

      • George Stephanis 6:26 pm on August 15, 2013 Permalink | Log in to Reply

        DNS has been sketchy, so wanted to get a slug in first.

        History:

        Back when working on 3.5, @lessbloat worked up a new Welcome Screen that we worked on. In the trac ticket, #21368-core, @rhc3 mentioned his Hopscotch plugin that indexed the page’s links to provide suggestions and autocomplete for when someone was having a hard time tracking down what they wanted to do in the menu. It also included hooks to let third parties offer results as well. Some of this functionality was later duplicated by Japh Thompson of Envato, as a part of WP Butler.

        The search functionality wound up getting sacked, but I’ve had the idea of a ‘search-everything’ field in my mind ever since then.

        I built it out, wound up rolling it into Jetpack as a central core, to quickly iterate and make available but it’s built extensibly so any plugin can provide results. I think it’s a terrific UX win, and would like to test it and offer it for inclusion into core.

        • Japh 10:24 pm on August 15, 2013 Permalink | Log in to Reply

          I’d like to be involved with this (obviously, as I built WP Butler to serve a similar function)
          :)

    • MartyThornley 6:10 pm on August 15, 2013 Permalink | Log in to Reply

      I started a quick plugin as a proof of concept ( very early ) for rethinking the user and site signup and login process, especially concerning multisite. The idea is to consolidate and streamline it all. Also, to make things easier, make the urls more friendly – with /signup, /signin, /signout. https://github.com/MartyThornley/better-signups

    • @ubernaut 6:14 pm on August 15, 2013 Permalink | Log in to Reply

      here’s an idea which may be too crazy and it’s very basic so far no mock ups or anything but basically it to as much as possible do away with the distinction between front end and back end. Inspiration of this idea belong to Matt’s 2013 Stat of the Word speech and the problem of blog abandonment also some belongs to the existence of p2 as well.

      i have found that when teaching people that are new to wp that dichotomy between front and back end (which makes perfect sense to me btw) is a tumbling block and doing away with it may be very beneficial for learning curve.

      Obviously there are some task and admin stuff that would still need to exist but i think it could be very limited fro many user roles.

      • Avryl 12:45 am on August 16, 2013 Permalink | Log in to Reply

        @ubernaut I’d really like to help with this in any aspect. Who’s currently working on this? Are the people here still interested?

        • @ubernaut 5:23 pm on August 16, 2013 Permalink | Log in to Reply

          Great! Well trishasalas also expressed interest and George Stephanis also agreed to help me break down my idea to see exactly what it would take.

          Right now i’m just taking a day or two to think out the different aspects of how i invasion the all to work. mainly the idea i think in my head at least at this point is basically bring all the tools normally only accessible in the admin area to the front end via sort of context sensitive modal overlays.

          i guess i wanted to throw together a few simple mockups together so people could see what i’m thinking. I’m going to try to get a thread started so it will be easier to collect our thoughts on the will update here with a link once i have that going.

      • paaljoachim 2:54 pm on August 19, 2013 Permalink | Log in to Reply

        Frontend editing is an area that really needed to make things easier in learning about how to use WordPress. I helped a friend of mine who uses wix.com and it uses the frontend to edit the page. Wix is more basic but it has two important features: Easy for the user to select a skin/theme/template and from there they use the frontend to edit the skin. There is a video showing some of this on their web site. Incorporating backend features into the frontend is as see it a must. I look forward to helping in whichever way that I can.

        • @ubernaut 10:23 pm on August 19, 2013 Permalink | Log in to Reply

          • paaljoachim 9:54 am on August 20, 2013 Permalink | Log in to Reply

            Hey ubernaut. I see your screenshots and my mind began thinking. I have posted the below on your web site as well:

            Thinking out loud about the process…
            WordPress installed.
            The first thing one sees is the default theme front page. A box up in the right corner to login. The user logs in. The dashboard bar shows at the top. Since it is the first login a link below the login box is seen: “tour the interface.” User clicks and a short video is seen.

            Showing:

            • How to select a theme from the front end. Perhaps a link all the way to the right of the Dashboard top bar with the name of “Choose Theme”. Click the link and see a drop down of small thumbnails and at the bottom of the drop down a see additional themes option. As the user moves the cursor over the thumbnails they are automatically bigger to the side of the drop down showing 2-3 fairly large screenshots with some key info below the screenshots. The user selects a theme and the front end automatically adjusts to show the theme selected.
            • Hover over elements on the page an outline is seen and one can click inside and an edit bar is seen.
            • Drag elements around to replace.
            • Turn on grid to align elements.
            • Click directly on an menu link to move to the page.
            • At the top Dashboard bar click the +New (OR use the Template button next to it to use an existing saved page) to create a post/page/category.

            A blank page is seen and blocks are seen on the right side (depending on if it is a post/page/category). Main elements – Header, menu, sidebar, content, footer.
            Elements (widgets, shortcodes, block elements all in one).
            One drags the various elements to create the page. Click the save button top right to the left of the login area. Beside it is the copy page button on hover it will say save as template.
            Create a new page – and at the top right – save, copy, use template button.

            A lot of these things can be very similar on the backend and frontend.

    • Helen Hou-Sandi 6:23 pm on August 15, 2013 Permalink | Log in to Reply

      New overall admin style, by way of MP6. I will serve as interim lead while MT is on sabbatical.

    • lessbloat 6:31 pm on August 15, 2013 Permalink | Log in to Reply

      Dashboard

      I plan to play around with some ideas for ways to update the dashboard. Perhaps simplify it a bit. Look at ways to possibly make it more easily extensible/customizable.

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