O2 Plugin Request: The Final Word

For a little while on the Community Team we have been discussing how useful it would be to have a ‘top comment’ feature on O2 that would allow us to sum up a thread with a single comment. This would be similar to the ‘accepted answer’ function that you see on Stack Exchange and other support forums where one reply is highlighted and shown at the top of the comment thread. It’s great for long discussion threads and anything that requires a final decision (as a lot of our discussions on the Community P2 do).

In order to make this happen, I built a plugin called The Final Word (Plugin Directory / GitHub) that works with O2 to provide this functionality. I have opened a ticket for including this plugin that contains some screenshots of what this would look like.

The features of this plugin include:

  • Marking a chosen comment as the ‘top comment’
  • The top comment is displayed at the top of the comment list with a ‘view in context’ anchor link
  • The top comment is also highlighted in context in the thread
  • Only one comment can be selected as the top comment
  • The top comment flag can be removed
  • Only users who are able to edit the post can select a top comment
  • Includes basic styling for top comments

It’s worth noting that there is nothing in the plugin that will conflict with any existing features on Make and it barely adds any additional technical overhead, so if it is only used by a handful of teams, then the other teams won’t be negatively affected.

Assuming this is accepted and can be added to the Make blogs, the only additional code that we might need to add would be some additional CSS for the top comment styling. I purposefully built the CSS included the plugin to be very generic, so it may need some slight tweaking for the Make network. I would test this out locally, but the Meta Environment has not yet been updated to include O2, so I can’t do this effectively.

Thanks to @ocean90 for an initial code review, as well as @pento for some general pointers with regards to extending O2.

Also pinging @coreymckrill and @iandunn about this.

Recap of WordCamp.org ticket scrub on August 15th

@sergeybiryukov and I held down the fort for this week’s ticket scrub.

The next WordCamp.org Ticket Scrub meeting will be in two weeks, 2017-08-29 19:00 UTC, in #meta-wordcamp.

Here is a summary of this week’s discussion:

#2571-meta, #2886-meta

These are both minor code updates that already have patches submitted by @sergeybiryukov. The first one is ready for @coreymckrill to commit. We decided to have @sergeybiryukov adjust the second one a bit to remove title attributes from some HTML tags, since those are no longer recommended for accessibility reasons.

#1097-meta, #2973-meta

These are both related to adjusting the list table view of camp attendees to allow for sorting by last name. @sergeybiryukov volunteered to look into writing a patch.

#1109-meta

This ticket relates to copying custom menus over when cloning a WordCamp site. It already has a patch, but @coreymckrill was unsure if this was really a desired behavior. While the navigation menu would theoretically look the same as the finished site that has been cloned, the downside is that it may create menu items for pages that don’t actually exist in the new site yet, and may not even be needed.

@coreymckrill said he would follow up on the ticket to clarify the intent and usefulness of the change.

#1183-meta

This ticket is about adding some extra meta data for WordCamps that include a Contributor Day. A couple of different approaches are suggested in the ticket, but no patch has been submitted yet. @coreymckrill said he would follow up to see if any of the ticket participants would still be interested in working on a patch.

#1226-meta

Part of this ticket has been completed, because the Edit Flow plugin has now been installed on the WordCamp.org network. The other part, to make some adjustments so that all of Edit Flow’s modules are turned off by default on new sites, still needs some discussion and a patch. @coreymckrill said he would start a new ticket for that, and close this old ticket.

#1097-meta, #1109-meta, #1183-meta, #1226-meta, #2571-meta, #2886-meta, #2973-meta

X-post: Community Conduct Project – Kick off meeting scheduled for 17:00 UTC on the 5th September 2017

X-comment from +make.wordpress.org/updates: Comment on Community Conduct Project – Kick off meeting scheduled for 17:00 UTC on the 5th September 2017

WordCamp.org ticket scrub agenda for August 15th

This is the agenda for our bi-weekly WordCamp.org ticket scrub, which will happen 2017-08-15 19:00 UTC in #meta-wordcamp.

  • The main goal for this meeting is to continue going through the list of WordCamp-related good-first-bug tickets, review their status, and adjust status/keywords as necessary.

If you have some thoughts beforehand or would like something related to be part of the agenda, feel free to share your ideas in the comments for this post. See you in the chat!

#agenda #ticket-scrub #wordcamp

+make.wordpress.org/community

Recap of WordCamp.org Ticket Scrub for the week of July 31st

Great attendance for our first-ever WordCamp.org ticket scrub!

The next WordCamp.org Ticket Scrub meeting will be in two weeks, 2017-08-15 19:00 UTC, in #meta-wordcamp.

Here is a summary of this week’s discussion:

#2907-meta

This patch makes some significant changes to the Instagram source in the Tagregator plugin to accommodate changes to the Instagram API. The current patch submitted by @xkon uses raw cURL commands, which is not ideal for compatibility. The suggested change was to try using `wp_remote_get` or `wp_remote_post` instead. @ryelle volunteered to help test this and other Tagregator patches. (#2100-meta, #3003-meta)

#2934-meta

This ticket has a patch from @rmarks that partially addresses the issue. @coreymckrill said he would try to get that patch committed, and suggested fixes for other parts of the issue should go in a separate patch.

#859-meta

We discussed the patch for this ticket recently submitted by @grappleulrich. One aspect of the patch was to prevent users from publishing posts while Coming Soon mode is enabled, so that site subscribers wouldn’t get an email notification of a new post that might be incomplete and that they wouldn’t actually be able to access. As a group, we agreed that disabling the Publish button would actually be confusing and that there are times when you might want to publish a post while still in Coming Soon mode. Instead, we decided to change the approach so that email notifications are disabled in Coming Soon mode, and there is a warning near the Publish button to notify users that their post won’t be emailed to subscribers if they publish while still in Coming Soon mode.

#574-meta

This is an old ticket with an old patch. We agreed that the feature described would still be useful, but the patch probably needs to be updated before it will be compatible with the current version of CampTix. @coreymckrill said he would move the ticket over to the CampTix GitHub repo.

If you were unable to attend this meeting but have feedback, please share your thoughts in the comments on this post. In case there’s a need for further discussion we will ensure to make time for it in the next meeting. See you next time!

#2100-meta, #2907-meta, #2934-meta, #3003-meta

WordCamp.org Ticket Scrub for the week of July 31st

This is the agenda for our first bi-weekly WordCamp.org ticket scrub, which will happen at 2017-08-01 19:00 UTC in #meta-wordcamp.

  • The main goal for this first meeting is to start going through the list of WordCamp-related good-first-bug tickets, review their status, and adjust status/keywords as necessary.

If you have some thoughts beforehand or would like something related to be part of the agenda, feel free to share your ideas in the comments for this post. See you in the chat!

cc @sergeybiryukov @grapplerulrich @ryelle

#agenda #ticket-scrub #wordcamp

+make.wordpress.org/community

Experiment: WordCamp.org bug scrubs

There are a lot of open WordCamp-related tickets in Meta Trac that don’t get much attention. Some of them even have patches ready to go. The problem is that each ticket requires discussion and testing before it can be resolved, and we don’t currently have the bandwidth to keep up with it all.

Here’s what I think an ideal ticket workflow looks like:

  1. Ticket is opened
  2. Ticket issue is confirmed and the ticket is accepted
  3. Patch(es) added to the ticket
  4. Patch code is reviewed
  5. Patch is tested against issue’s reproduction steps
  6. Patch is confirmed and committed
  7. Ticket is closed

When multiple people collaborate on tickets, getting through these steps is much faster. I’d like to propose that we try having scheduled meetings in the meta-wordcamp Slack channel to work through tickets together. We could model this after Core bug scrubs, and with at least 3-5 people attending, we might be able to make progress on several tickets each time.

I’d like to try doing them every two weeks. My preference would be *every other Tuesday at* 17:00 UTC, but I’m open to other time slots if they can accommodate more people.

Leave a comment here if you’re interested in participating, and whether that time and date would work for you.

cc @grapplerulrich @sergey @miss_jwo @brashrebel @iandunn @shadyvb

+make.wordpress.org/community

X-posting Proposal: WordPress Community Conduct…

X-posting Proposal: WordPress Community Conduct Project
Please read + comment on the original post.

Proposal: WordPress Community Conduct Project

Finalizing Meta topics for the Community Summit

I just popped in here and realized that there isn’t a post yet for discussing Meta’s community summit topics. I’ll couch off of @hlashbrooke‘s post to get things started.

The Community Summit is going to be hosted in Paris just a few days before WordCamp Europe, on 13 & 14 June 2017. We are at the stage now where all contribution teams are being asked to finalize their topics for the Summit. The deadline for final topics is 9 June 2017.

The currently proposed topics for all teams are listed here, and these are the ones for the Meta Team:

  • Translation of documentation on WordPress.org, including developer hub and (the future) help hub – (Polyglots, Docs, Support)
  • Participate in other team’s discussions to see how the Meta team can help them

Are there any additional topics that you feel are important for us to discuss at the Summit?

While answering that question, please bear the following from the Summit announcement post in mind:

The main purpose of the summit is to move the project forward before and after the event, with the event being a milestone in a larger set of work.

With this main goal in mind, we’ll touch base with all team reps to figure out which of the topics proposed can be handled beforehand, and come up with topics that would be:

1) of importance to the project as a whole
2) would benefit from cross-team collaboration
3) will leave us in a better position than when we started

Announcing the new WordPress Plugin Directory

The Meta team is very happy to announce the launch of the all-new WordPress Plugin Directory!

First announced as an Open Beta at WordCamp Europe 2016 , this latest evolution features a range of improvements, both internal and tangible:

  • A new back-end based on WordPress, to replace the old bbPress engine.
  • Refactored API code, also open source.
  • A complete visual redesign and open-source theme.
  • A completely open-source codebase.
  • A vastly improved search engine.

Developers and testers running early versions of WordPress 4.8 have already been using the new API for a while now, and many in the #meta community have been testing and contributing to the new directory’s development.

For those of you seeing the new directory for the first time, here are some of its features in detail that will interest both plugin developers and users:

The search engine has been totally replaced. Searches now return the most relevant results based on a combination of many factors including version compatibility, recency, and popularity, in conjunction with text relevancy. This means that obsolete and unsupported plugins – while still available – are less prominent in search results than those in active development and use.

Search results in the old directory, left, and the new directory, right.

The most important information about each plugin is shown up front, rather than on separate tabs. The description, screenshots, and FAQs are all visible together, with a simple scroll, without flipping to a separate tab. Important metadata like versions and ratings are shown in a sidebar, much like before, but we’ve simplified the page with a 2-column layout, removing extraneous navigation from the old 3rd column.

Plugin details in the old directory, left, and the new page, right.

We have also revised accessibility across the new design, with improved text sizes and contrast, and better markup for screen readers. The new design is responsive and works well on mobile and desktop devices with a wide range of sizes.

Behind the scenes, the entire back end of the web site and API has been replaced with an open source WordPress plugin. The old directory was built on bbPress with a collection of ageing, closed-source plugins. It was antiquated and difficult to maintain. The new directory uses the best practices of modern WordPress development; and, since it’s entirely open source, can be maintained and improved by a much wider community.

It’s been a long road, so it’s very exciting to finally launch the new Plugin Directory. Thanks to everyone who has contributed their time and energy to the project, especially @obenland, @mapk, @dd32, and @gibrown, whose enthusiastic efforts made everything look easy.

The new directory has been built with future maintainability and iterative enhancement in mind. We’re looking forward to hearing feedback from the whole WordPress community, and making regular improvements and additions. Bug reports and specific enhancement requests can be made in Trac. The best place for questions and general discussion is the #meta channel on Slack.