WordPress.org

Make WordPress Core

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • George Stephanis 3:16 pm on January 27, 2016 Permalink |
    Tags: ,   

    The Two-Factor Plugin is currently on a brief hiatus, while we work on splitting off it’s Application Passwords feature into a smaller, solo feature plugin.

    https://github.com/georgestephanis/application-passwords/

    Application Passwords was initially a sub-feature of Two-Factor Authentication, but due to the fact that we had very little confidence in Two-Factor being ready for the 4.5 cycle, we spun off a nearly-complete sub-feature that may mesh very well with the existing REST API.

    Application Passwords lets each user choose to generate “Application Passwords” — randomly generated 16-character alphanumeric codes, that are only displayed to the user once, upon creation. These passwords can be revoked either individually or all at once, and track usage, so in the admin UI you can view the most recent IP and Date that the password in question was used.

    The passwords are only valid for non-interactive prompts. That is, for use with our XML-RPC and REST APIs. They can not be used on `wp-login.php` or to access the admin panel. The idea is that each application you connect to your WordPress account — a mobile app, if this then that, Microsoft Word, or some sort of local blogging software, they all have their own password that can be revoked if the device is lost or no longer in usage, all without dispensing full access to your account.

    For folks building a quick one-off script that needs to tie into WordPress, this is far simpler than using the obscure oAuth version that Core has to use because we can’t guarantee HTTPS, and far more secure than the existing “use your account password for api calls” standalone plugin, that many folks would likely choose to default to otherwise.

    Screen Shot

    Code reviews, issues, and pull requests are very welcome.

     
    • Mikel King 3:53 pm on January 27, 2016 Permalink | Log in to Reply

      Awesome thanks for this!

    • Laurens Offereins 4:29 pm on January 27, 2016 Permalink | Log in to Reply

      Interesting. Am I wrong to say this is like GitHub’s access tokens? Would this be useful for, let’s say, making user-specific RSS feeds, allowing private posts in the feed? I’ve for long wanted a unified interface for creating user-specific access keys.

      • George Stephanis 8:33 pm on January 27, 2016 Permalink | Log in to Reply

        Hrm, well, RSS feeds don’t ordinarily require authentication, but I guess you could use it as authentication on a JSON API endpoint that gives similar data and tailor it to a user.

    • Scott Kingsley Clark 5:56 pm on January 27, 2016 Permalink | Log in to Reply

      I love this feature, looking forward to it!

  • Adam Silverstein 8:14 am on January 27, 2016 Permalink |
    Tags:   

    Feature Plugin chat notes for Jan 26 

    Agenda

    • Review the feature plugins for status updates from leads
    • Open floor for feature plugin proposal

    Feature Plugin Updates

    • Background Image Cropper: @celloexpressions asked for feedback for the Background Image Cropper. Current thinking is this is better explored as a standard enhancement for core. See #32403.
    • Customizer: @westonruter left status on the blog post for the Customize Pane Resizer, Customize Device preview (along with @celloexpressions), Selective Refresh, and Transactions. Please comment there if you’re interested in helping out where needed (especially requested for the Pane Resizer).
    • Fields API: @sc0ttkclark updated: term add/edit is in: props @technosailor. Team has been working on simplifying the code required for each screen implementing the Fields API. Scott posted an update on make/core and reports getting lots of feedback (especially from @helen, @drew, @technosailor & @celloexpressions)
    • Shiny Updates:  @obenland updated – Lots of progress in the last week. @ipstenu helped tremendously in getting it multisite compliant. Team decided to not pursue shiny activations/deactivations for a whole set of reasons, mostly around redirects on subsequent page loads, and fatal error protection.
      Currently working on enabling theme updates without having to open the modal, and revamping update-core.php.  An update will be posted to the make/core blog soon. The team needs more feedback and testing! Testers can get the current plugin from the wordpress.org repository.
    • WP-API: @danielbachhuber updated – released beta 11 yesterday. The team is meeting in person (minus @rachelbaker) this week at A Day of REST. Summary: in the home stretch, but there’s a ton more work to do. Friday’s contributor day (at the Day of REST) will hopefully get other people diving in and contributing to the final push.

    Open Floor

    The full logs are available on Slack.

     
    • jrf 10:52 am on January 27, 2016 Permalink | Log in to Reply

      I’d love to continue the discussion on Plugin Dependency management within WP.
      We’d very much would like to invite everyone to give their opinion on the direction we’re thinking of taking though this survey: http://goo.gl/forms/Fq1gbY9vCW

      We’d really appreciate getting as many opinions as possible about this. Thanks!

      • Felix Arntz 11:50 am on January 27, 2016 Permalink | Log in to Reply

        I just took the survey, I have a few comments on the approach.

        I certainly like that multisite will be supported, this is definitely a requirement anyway. 🙂

        About the dependency management: although I personally would prefer a JSON file, I think the theme/plugin header way is more the WordPress way, and a lot easier. People new to WordPress and even to development should be encouraged to start creating plugins/themes – external libraries/library plugins make this a lot easier, but I’m afraid a JSON file is too complex. Maybe both methods should be supported: while only the JSON approach would support the full functionality of dependency management, the file header would still allow to at least require plugins listed on wordpress.org with a minimal version number (there’s not really room in there to do more complex things). If someone needs external plugins or something like that, that should only be possible using JSON.

        The other thing is, in my opinion the recommendations feature should not be part of the feature plugin. Standard dependency management does not handle recommendations either, and I think this goes into kind of an advertising direction which I wouldn’t like to have in WordPress Core.

        I’m looking forward to this project and I’m happy you make these efforts to create a feature plugin. I think the full power of this feature however could only be leveraged if the wordpress.org plugins API would be adjusted as well to contain dependency information as this would allow notifications prior to installing which I think is even more elegant than notifications before activating (also due to the problems that this would bring on multisite). Anyway, first things first! 🙂

    • Ryan Boren 3:33 pm on January 27, 2016 Permalink | Log in to Reply

      Beta testing is much easier when feature plugins are kept up-to-date in the plugin repo. This allows using the built-in WP update mechanism to follow development. Our beta testing onboarding, such as it is, relies on feature plugins being updated regularly.

      A survey of https://wordpress.org/plugins/browse/beta/ and https://make.wordpress.org/core/features-as-plugins/:

      • Background Image Cropper: Last updated one month ago in the plugin repo. The features as plugins entry is bare.
      • Customize pane resizer: This is listed in neither browse/beta nor features-as-plugins.
      • Customize Preview Responsiveness (aka Customize Device Preview): The Customizer UI Experiments plugin was last updated two months ago. This is called three different things.
      • Customize Partial/Selective refresh: The plugin hasn’t been updated for 6 months.
      • Customizer transactions: I don’t see this in browse/beta or features-as-plugins.
      • Fields API: This is not listed in browse/beta. Does it even exist in the plugin directory?
      • Shiny Updates: This is in browse/beta and kept up-to-date. As such, I’ve been testing it.
      • WP API: This is in browse/beta and kept up-to-date. It is pretty much the only feature plugin to post on make/core regularly and do calls for testing.

      Court beta audiences. Update plugins in the plugin dir, preferably nightly. Keep features-as-plugins up-to-date. Publish calls for testing to make/core. Here’s a call for testing template and checklist. http://simp.ly/publish/XrHJDL

    • Ryan Boren 8:04 pm on January 27, 2016 Permalink | Log in to Reply

      If you have the beta tester plugin, feature plugins can be installed from Plugins > Add New > Beta Testing. Details here: https://make.wordpress.org/core/handbook/testing/beta/

  • John Blackbourn 12:38 am on January 26, 2016 Permalink |
    Tags: ,   

    HTTPS discussion meeting this Wednesday 

    In recent releases of WordPress there have been various improvements made to support for sites running on HTTPS. While support is currently very good, it’s still too easy to end up with mixed content on a site (HTTP content embedded within an HTTPS page), and especially so when migrating an existing site from HTTP to HTTPS.

    There will be a discussion meeting in the #core-http Slack channel on Wednesday, January 27, 2016 at 2000 UTC. This is one hour before the regular weekly meeting in #core. I’d like to discuss three topics:

    1. Implementing an (opt-in) method of forcing a site to use HTTPS.
      • What should this cover? (Embedded content, enqueued scripts/styles, links, redirects)
      • How should it be implemented? (eg. filter/constant/automatic)
    2. Defaulting to HTTPS for new installs when it’s available.
      • Only applies when setting up a site over HTTP and it’s available over HTTPS.
      • Need to communicate clearly to the user what this implies, with option to toggle.
    3. Aiding in switching an existing site from HTTP to HTTPS.
      • Migrating existing embedded content.
      • Should this be a feature plugin?

    If you’re interested in helping out with any of the above, or with HTTPS improvements in general, join us on Wednesday.

    Further reading: the https tag on Core Trac.

     
  • Daniel Bachhuber 12:00 am on January 26, 2016 Permalink |  

    WP REST API: Version 2.0 Beta 11 

    Just days before the first conference dedicated to the REST API, we bring you: 2.0 Beta 11 “Give me a white wine spritzer!”. Download it from the plugin repository or from GitHub.

    Here are some highlightsbreaking changes from the changelog:

    • Moves Post->Term relations to the Post Resource. Previously, a client would fetch a Post’s Tags with GET /wp/v2/posts/<id>/tags. In Beta 11, an array of term ids is included on the Post resource. The collection of terms for a Post can be fetched with GET /wp/v2/tags?post=<id>. The WP_REST_Posts_Terms_Controller class no longer exists.
    • Changes featured_image attribute on Posts to featured_media. While featuring other attachment types isn’t yet officially supported, this makes it easier for us to introduce the possibility in the future.
    • Uses discrete schema title for categories and tags. If you’ve used register_rest_field( 'term' ), you’ll need to change 'term' to 'tag' and/or 'category'.
    • Makes many filters dynamic based on the controller type. If you were using the rest_prepare_term filter, you’ll need to change it to rest_prepare_post_tag or rest_prepare_category. If you were using rest_post_query or rest_terms_query, you’ll need update your use to rest_page_query, etc. If you were using rest_post_trashable, rest_insert_post or rest_delete_post, they are now dynamic based on the post type slug.

    As always, we have a detailed changelog as well as the full set of changes if you’re interested.

     
  • Aaron Jorbin 9:13 pm on January 24, 2016 Permalink |  

    Accessibility Coding Standards now in draft and seeking comments. 

    The WordPress Accessibility Team has created draft Accessibility Coding Standards for the core handbook.  These standards will remain in draft format for at least the next two weeks while everyone has an opportunity to review and comment.  If there are significant changes made based on the comments, additional posts here will be made announcing them and seeking further comments.

    Please review the draft standards and leave your comments on this post.

     
  • Mike Schroder 8:32 am on January 23, 2016 Permalink |
    Tags:   

    Feature Plugin Meeting on Tuesday, Jan 26 

    As mentioned in this week’s dev chat, we’ll be holding a Feature Plugin meeting on Tuesday, January 26, 2016 at 2100 UTC (the usual dev chat time).

    If you are a lead for an officially recognized feature plugin, please either plan to attend if you’d like feedback, or if you can’t attend, leave a status in a comment on this post — we’ll be going through each of them during the meeting.

    These meetings are a great time to request feedback, show interest in a merge in 4.5, or propose a new feature plugin idea.

    For background, you can see more details on the feature plugin process in the core handbook, and a list of current feature plugins.

     
    • Weston Ruter 5:47 pm on January 26, 2016 Permalink | Log in to Reply

      I’ll provide an update here since I’m traveling today.

      The Customize Pane Resizer plugin (#32296) needs support, both finalizing the behavior of the resizer and preparing the core patch from the feature plugin.

      The Customize Device Preview plugin (#31195) has an updated patch from @celloexpressions. It got a +1 from @melchoyce and I’ll try to review the code later this week. I believe Nick is also going to put up a Make Core post on the feature for merge proposal feedback.

      My focus continues to be selective/partial refresh (#27355). This is something which I have identified as being a dependency for transactions (#30937). I am considering pushing out transactions to 4.6 so that themes can implement selective refresh first and not experience the flash-of-reloading-content issue for settings they don’t implement selective refresh. Also, transactions will ideally utilize the REST API, and since the REST API is under active development now, I’m wary to push too hard on transactions.

      Another ideal dependency for transactions is Customize Setting Validation (#34893). I think this feature plugin is in good shape and there is a core patch. The biggest need here is for the notification area (#35210) to be implemented according to the design worked up. A patch with the markup and styling is needed.

      As for adding page stubs within the Customizer (#34923), there is a mock for how this can work. There is a dependency here on having that notification area to prompt the user to edit the page stubs created. There will be some complexities to get the pre-saved page to appear in the nav menu and also to be able to navigate to this page. I will have a good chunk of time to work on this since it is a dependency for a client project, but I am concerned that it will miss the merge window.

      That’s all for now.

  • Chris Christoff (chriscct7) 8:36 am on January 22, 2016 Permalink |
    Tags: ,   

    Call for Trac Tickets and Recap of 1/15/2016 Bug Scrub 

    On Friday January 15 at 17:00 UTC  we held the second regularly scheduled bug scrub of the WordPress 4.5 release cycle. As a reminder, for the 4.5 release, trac bug scrubs will be held weekly each Friday at 17:00 UTC. Bug scrubs are held in the #core channel of WordPress Slack.

    Unfortunately, as I am unable to make today’s meeting, and was unable over the last few days to find a replacement, today’s meeting is cancelled. I hope to see you all at the next meeting, which will be next Friday at 17:00 UTC. Regardless, please feel free to use the time to triage tickets!

    The Slack archive for last week’s meeting begins here: https://wordpress.slack.com/archives/core/p1452877403010570
    During the bug scrub, the following tickets were covered:

    #32318 , #32920 , #12955 , #25669 , #27056 , #28441 , #29660 , #34839 , #35100 , #13910 , #30352 , #2702 , #33045 , #33283 , #13459 , and #18877

    Next week, the bug scrub will run approximately 1 hour. Participants need not be present for the full duration, and everyone is welcome to attend.

    We’ll start with a list of pre-submitted tickets, before going to an open floor. As time permits, the remainder will be filled with a mix of tickets in the 4.5 milestone, and abandoned tickets, taken from report 43 (Ancient Tickets) on Trac.

    If you would like to submit a ticket for consideration for the bug scrub, please comment below with the ticket number. If you have extensive knowledge of the ticket, accompanying text which provides  a brief description of each ticket, its current status, and what needs to happen for the ticket would be appreciated. Bug scrubs are a great way to get extra eyes on tickets, feedback on patches, or suggestions on future routes.

    During the WordPress 4.4 cycle, Trac experienced a net loss of approximately 600 tickets. The goal for the 4.5 release is to get to 2,500 tickets open on Trac. The current count is 3,347, which is 847 tickets from this goal.

     
  • Adam Silverstein 9:48 pm on January 20, 2016 Permalink |
    Tags: , ,   

    Core Dev Chat Notes for Jan 20 

    Announcements

    Focus Status Updates

    • Customizer: @westonruter, @celloexpressions
      • Good progress has happened for selective refresh, with good feedback and an architectural direction #27355.
      • A responsive preview feature has been getting good feedback and is nearing a committable patch #31195.
      • Update make/core post coming soon.
    • HTTPS Improvements: @johnbillion
      • Nothing specific to report about the HTTPS work, there will be a meeting next week about ‘force ssl’ which he will post about in make/core tomorrow morning for those who want to get involved.
    • Image Improvements: @joemcgill
      • Improving Imagick compression settings #33642 is still a priority.
      • Looking into options for #28474 (better animated GIF handling).
      • Longer term effort: what can be done to improve some of the core API for working with images
    • Multisite/WP_Site: @jeremyfelt
      • Several things assigned to the 4.5 milestone
      • A reorg of filters for network allowed themes went in today.
      • Working at the latest <code>WP_Site</code> patch now with the intent of putting it in today or tomorrow.
      • Office hours on Tuesdays at 21:00 UTC in #core-multisite; bring your bugs.
    • Post New: @michaelarestad
      • @karmatosed is going to be leading a team focused on improving the Revisions UI
      • @hugobaeta is going to be leading the Toolbar Remix team
      • @michaelarestad working on improving the Publishing UX and Metaboxes
      • @michaelarestad made a Sketch template for wp-admin that’s accurate and will be published later this week.
      • Update posts coming soon
      • Join the effort: comment on the original post and join the Slack #design channel.
    • Editor: @azaozz, @iseulde

    Open Floor

    • @ipstenu brought up #35429; @michaelarestad going to review from UX perspective, discussion
    • @azaozz brought up inline link dialog autocomplete, extend suggest.js or use another library (typeahead, select2)? what is the use case? discussion in #core-editor. @sheri offered to help with user testing to determine the best UX.
    • Meeting ended, ticket conversation continued…

    View the full logs on Slack.

     
  • Eric Binnion 3:20 pm on January 20, 2016 Permalink |
    Tags: ,   

    Week in Core, Jan. 12-19 2016 

    Welcome back to the latest issue of Week in Core, covering changes from January 12th – January 19th, 2016, changesets [36269][36350]. Here are the highlights:

    • 81 commits
    • 38 contributors with props
    • 127 tickets created
    • 19 tickets reopened
    • 100 tickets closed

    Ticket numbers based on trac timeline for the period above.

    Note: If you want to help write the next WordPress Core Weekly summary, check out the schedule over at make/docs and get in touch in the #core-weekly-update Slack channel.

    Code Updates

    Accessibility

    • After [36333] correctly use esc_attr() instead of esc_attr__(). [36334] #35313
    • Remove title attributes from the Posts list table. [36333] #35313, Media Library list table. [36331] #35136 & the Comments screen. [36298] #35304
    • Improve focus handling on the Taxonomies Quick Edit. Moves focus back to a proper place when saving or closing the form. [36304] #35460
    • Improve focus handling and audible feedback on the Posts Quick-Bulk Edit. Avoids a focus loss when saving or closing the form moving focus back to a proper place. Uses wp.a11y.speak() to dispatch successful edits and error messages to screen readers. [36303] #34756

    Administration

    • CSS: Reference the original location of the CSS rule being overridden. [36342] #35229
    • CSS: Stop using wp-admin.min.css and instead queue the individual stylesheets up through load-styles.php. We still generate the wp-admin.* files for compabitility purposes, however they only include the @import() lines. [36341] #35229
    • List Tables: Use the $GLOBALS array when unsetting the global post and comment in WP_Comments_List_Table::single_row(). [36339] #35506
    • Allow searching for 0 throughout the admin. [36302] #31025
    • Add a “Drag boxes here” message to empty dashboard meta boxes so it’s clear to users that it’s possible to drag meta boxes into empty spaces. [36295] #26399
    • Support searching for '0' in WP_Query. [36278] #31025

    Build/Test Tools

    • Build/Test Tools: Move PHP factory classes into their own files. [36347] #35492\
    • Build Tools: Append the timestamp to $wp_version instead of only the current date. [36315] #28722

    Canonical

    • After [36280] remove the unit tests which are no longer supported for 4.4. This also removes the is_feed() code to avoid confusion – only pages & embeds will be redirected. [36281] #35344
    • Restore the is_404() check in wp_old_slug_redirect() which was removed in [34659]. This reverts part of [34659] due to excessive canonical problems it’s caused in 4.4.x. [36280] #35344, #21602

    Comments

    • Ignore false values of ‘search’ in WP_Comment_Query. [36345] #35513
    • Remove unused $default_comments_page variable in get_comment_link(). [36343] #34073, #35511
    • Correct description of comment_author property in WP_Comment class. The comment_author property is the comment author’s name, not an ID. [36332] #35464
    • Respect all post-related filters in WP_Comment_Query. [36326] #35478
    • Use TEXT column type in fallback for wp_get_comment_column_max_length(). [36325] #10377
    • Respect custom pagination params when using wp_list_comments() in a query loop. [36324] #35402
    • Remove unneeded $req variable in comments_template(). [36322] #35473
    • Add a new pre_wp_update_comment_count_now filter. [36318] #35060
    • Use assertEqualSets() in comment_author test. The previous assertion was too specific, resulting in race conditions. [36279] #35377
    • Use the post-filter WHERE clause when querying for comment descendants. [36277] #35192
    • Always respect $comments array passed to wp_list_comments(). [36276] #35175, #35356
    • Ignore hierarchy in pagination calculation when comment threading is disabled. [36275] #8071, #35419
    • Restrict the maximum characters for input fields within the comments template. [36272] #10377

    Customizer

    Embeds

    • Allow embedding static front pages and pages having a child page with an embed slug. This makes embed a special slug that can’t be used for new pages/posts. When https://example.com/foo/embed/ is an existing page, embeds fall back to https://example.com/foo/?embed=true. Adds unit tests. [36307] #34971

    Filesystem API

    Formatting

    • Emoji: adjust $wpsmiliestrans. Swap simple-smile.png with SLIGHTLY SMILING FACE and frownie.png with SLIGHTLY FROWNING FACE [36336] #31710

    HTTP API

    • Add response status code aliases on WP_Http for convenience. These provide a more descriptive way to set response codes elsewhere, so it’s readable and less chance for the wrong response code to be used such as 401 vs 403. [36294] #35426
    • Add missing HTTP status code descriptions (specifically 308 and 421.) [36274]
    • Add support for 451 http status code (Unavailable For Legal Reasons.) Though this is technically still in the proposal stage, there is support from the core team and precedent in #16914 [36273] #16914, #35333

    I18n

    • Introduce tests for WP_Locale. [36292] #34688
    • Correct an argument description and return value for wp_dropdown_languages(). [36290] #35294

    JavaScript

    • In wp.Backbone.Subviews, extract subviews with proper Underscore.js functions. [36305] #34350
    • jQuery: Replace use of deprecated methods and events. [36288], [36287], and [36286] for #35380,
    • External Libraries: Update jQuery to 1.12.0 and jQuery Migrate to 1.3.0. [36285] #35380

    Media

    • Update some attach/detach strings in the columns view. [36328] #33237

    Multisite

    • Add initial tests for the allowed_themes filter. [36350] #28436

    Network and Sites

    • Clarify the docblock for get_current_site() so it’s clear that it returns the current network object, not anything to do with the current site. As a further exercise, the reader is invited to fix the nomenclature surrounding blogs, sites, and networks in WordPress. [36293] #35414

    Performance

    • Share post fixture in WP_Comment_Query tests. [36346] #30017
    • Script Loader: Add Etag: $wp_version header in load-scripts.php and load-styles.php. This improves performance since browsers won’t re-download the scripts and styles when there was no change in $wp_version. [36312] #28722

    Plugins

    • Prevent a warning when searching in the plugins list table. [36301] #35461
    • Make sure the ‘Beta testing’ tab is first in the plugin installer. This makes feature plugins more discoverable for people running development builds. [36297] #29631
    • In _get_plugin_data_markup_translate() remove the fallback to the “default” textdomain for Akismet. Akismet has its own language files since WordPress 3.9. [36283] #35436

    Posts, Post Types

    Taxonomy

    • Don’t double-escape the ‘name’ param in get_terms(). [36348] #35493
    • Populate term cache with proper clone of term objects. [36323] #35462
    • Fix unit tests after [36308]. [36309] #34988
    • Introduce wp-admin/term.php for editing single terms. [36308] #34988
    • Correct the accetped types for the taxonomy element in the arguments passed to wp_dropdown_categories(). [36289] #35446

    Themes

    • Show template loading error to users with switch_themes cap. [36344] #21931
    • Only users with proper capability should see theme errors. [36338] #21931
    • Show an error message to logged-in users if a template file isn’t loaded. [36335] #21931
    • Clear floated theme cards on Themes page. Also maintains visual separation for Broken Themes table on searches that return no results. [36270] #26646

    Upgrade/Install

    • Add a locking mechanism to avoid two concurrent updates of WordPress occuring. [36349] #34878

    Users

    • Always return $current_user in wp_get_current_user(), never a boolean. [36313] #19615
    • Deprecate the get_currentuserinfo() pluggable function. [36311] #19615
    • Decode special characters in password and email change notification emails. [36306] #35283

    Props

    Thanks to @5um17, @adamsilverstein, @afercia, @andizer, @berengerzyla, @boonebgorges, @chriscct7, @danielbachhuber, @dd32, @DrewAPicture, @ericlewis, @firebird75, @grapplerulrich, @iseulde, @ivankristianto, @jeremyfelt, @jmdodd, @joehoyle, @johnbillion, @jrf, @kraftbj, @Latz, @meitar, @MikeHansenMe, @obenland, @ocean90, @peterwilsoncc, @rachelbaker, @realloc, @rmccue, @scribu, @sebastianpisula, @sergejmueller, @SergeyBiryukov, @swissspidy, @valendesigns, @westonruter, and @xavortm for their contributions this week!

     
  • Mike Schroder 7:33 am on January 20, 2016 Permalink |
    Tags: ,   

    Weekly Dev Chat Agenda for Jan 20 

    Agenda for weekly dev meeting on January 20 at 21:00 UTC:

    Focus Leads, please have status ready.

    If you have anything to propose to add to the agenda, or have a project that you’d like added to the weekly status checks, please leave a comment below.

    See you in the chat!

     
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