Notice of Password Deactivation

Hello everyone, some of you will have the following email in your inbox:

Your password on WordPress.org has been deactivated, and you need to reset it to log in again.

We recently discovered your login credentials in a list of compromised emails and passwords published by a group of security researchers. This list was not generated as the result of any exploit on WordPress.org, but rather someone gaining access to the email & password combination you also used on another service.

To reset your password and get access to your account, please follow these steps:
1. Go to login.wordpress.org
2. Click on the link “Lost your password?”
3. Enter your WordPress.org username:
4. Click the “Get New Password” button

It is very important that your password be unique. Using the same password on different web sites increases the risk of your account being hacked.

If you have any further questions or trouble resetting your password, please reply to this message to get help from our support team. We will never ask you to supply your account password via email.

At this point we don’t have a reason to believe any accounts have been compromised, but out of an abundance of caution passwords are proactively disabled just to make sure.

If you have any questions don’t hesitate to post them in the comments.

[EDIT]: Updated the list typo to now go in order.

WordCamp.org ticket scrub agenda for August 29th

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

Specific tickets

Other items

  • Continue going through the list of WordCamp-related good-first-bug tickets, review their status, and adjust status/keywords as necessary.

If you would like to add a ticket or other item to the agenda, feel free to comment on this post. See you in the chat!

#agenda #ticket-scrub #wordcamp

+make.wordpress.org/community

#1109-meta, #1751-meta

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.

#recap #ticket-scrub #wordcamp

#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!

#recap #ticket-scrub #wordcamp

#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