Recap of WordCamp.org ticket scrub on October 24th

We discussed these tickets:

  • #1794 – The approach discussed in the ticket sounds good and should move forward. @kenshino is working on a patch.
  • #2501 – We decided that it wasn’t a good idea to switch to an `npm` module, because that brings a lot of complexity around dependency maintenance and security. Instead, we can just fix the small issue that exists in the current code. If anyone is looking to learn React, this ticket would be a good start.
  • #3035 – The new taxonomy sounds good. @kau-boy is working on a patch.
  • #3199 – The patch here looks good and was committed after the meeting.
  • #2907 – This one is in good shape, and is ready for a security review. @sergeybiryukov is going to look into that.
  • #859 – The patch here looks good and was committed after the meeting.
  • #3190 – The patch here looks good and was committed after the meeting. It probably doesn’t solve the problem, though. It looks like the problem might be fixed by manually setting the `From` header.

The next WordCamp.org Ticket Scrub meeting will be in two weeks, 2017-11-07 19:00 UTC, in the #meta-wordcamp channel.

#recap #ticket-scrub #wordcamp

Recap of WordCamp.org ticket scrub on October 10th

Participants: @coreymckrill @grapplerulrich @kau-boy @sergeybiryukov

We focused on open tickets relating to WordCamp sessions and the schedule.

#3044-meta

We determined that this issue is a fairly obscure edge case, as it only affects WordCamp schedules when viewing them in iOS Safari while in Reader mode. A good solution to the issue was not immediately clear to the group. We decided to add a screenshot of the issue and downgrade its priority level for the time being.

#3111-meta

@Kau-Boy volunteered to take on this ticket, using an approach very similar to previous work done on the [sponsors] shortcode.

#3115-meta

This ticket was actually fixed with a patch for #1896-meta.

#3117-meta

We had some discussion about the best way to approach a solution for this ticket, but ultimately decided more information was needed first.

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

#recap #ticket-scrub #wordcamp

#1896-meta, #3044-meta, #3111-meta, #3115-meta, #3117-meta

Recap of WordCamp.org ticket scrub on September 26th

Participants: @coreymckrill @grapplerulrich @miss_jwo @kau-boy @ryelle @sergeybiryukov

We started off by discussing some strategies for managing WordCamp tickets in Meta Trac. Historically, when new tickets have been created, an admin such as @iandunn or @coreymckrill has reviewed the ticket and “accepted” it as a way of marking it as a valid issue. The side effect of this has been that they are then “assigned” to that ticket, even if they intend to leave it as a “good-first-bug” for someone else. A lack of clarity around the meaning of an “assigned” user on a ticket may cause some people to pass over tickets that are actually available to work on.

@coreymckrill proposed that instead of accepting a ticket, it should be left as “new”, but relevant keywords such as “needs-patch” and “good-first-bug” should still be added. Then when someone submits a patch or indicates that they want to work on a ticket, they can be assigned to it. This would have a couple of benefits:

  • Easier to see which tickets are not being worked on yet
  • Easier to follow up with a ticket assignee if nothing has happened on it for a while

The group had general agreement that this strategy would be worth trying. Unfortunately, there does not appear to be a way in Trac to unassign a ticket and return it to “new” status, so this will only apply to new tickets going forward.

#2851-meta

This is an issue that @miss_jwo has personally experienced. She volunteered to work on a patch, so @coreymckrill officially “assigned” it to her 🙂 A bit more research also needs to be done to determine the exact conditions that cause the issue.

#3116-meta

The discussion here revolved around whether adding a heading parameter to each of the WordCamp CPT shortcodes is the best solution, as opposed to something like a feature flag (i.e. “all sites created after a certain date will show an H3 heading level instead of an H2”). The group decided on sort of a hybrid approach:

  • Add a new heading parameter that defaults to H2 for back-combat
  • Update the content in post/page stubs for new WordCamp sites so that the shortcodes include the heading parameter with the desired H3 specified.

@kau-boy volunteered to work on this ticket.

#3156-meta

Several of us learned why adding a separate singular placeholder translation is necessary for some languages. @coreymckrill will commit the patch and follow up with the submitter about some minor code styling issues.

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

#recap #ticket-scrub #wordcamp

#2851-meta, #3116-meta, #3156-meta

Recap of WordCamp.org ticket scrub on August 29th

I will be AFK on 2017-09-12, so the next WordCamp.org Ticket Scrub meeting will be in four weeks, 2017-09-26 19:00 UTC, in #meta-wordcamp.

Here is a summary of this week’s discussion:

Participants: @coreymckrill @sergeybiryukov @xkon

#859-meta

The latest patch from @grapplerulrich is ready to commit. @coreymckrill will add a slight wording tweak to it to clarify the Coming Soon notification:

Coming Soon mode is enabled. Site subscribers will not receive email notifications about published posts.

#1109-meta

After the last scrub, @iandunn provided some clarification about the functionality in the current patch for this ticket:

If we don’t create menus at all, then the layout often breaks because the custom CSS assumes that they’re there. It wouldn’t make sense to add links to missing pages, though, and there aren’t any pages on the destination site yet, so it seemed like creating menus with just a Home link was the best we could do.

… I wonder if we could copy over the menu items for links that do exist on the destination site? A lot of pages like Location, Contact, etc are pre-populated, so they’ll exist. We could just skip the pages that don’t exist.

We decided it would be best to pursue the additional functionality suggested by Ian before committing, so that the menus wouldn’t just contain a “Home” link, which could be just as confusing as a broken layout.

@coreymckrill will update the ticket to see if the patch author wants to try making the update.

#1751-meta

The patches provided by @kau-boy look good. @coreymckrill will do an additional round of local testing and then commit them, and then @kau-boy can update the handbook with documentation on the new shortcode attributes.

#2907-meta

This one has an extensive patch from @xkon that has already been tested successfully on wptranslationday.org. Since it involves remote requests, it just needs a security review before we merge it into the plugin.

@xkon also mentioned a fork of Tagregator that they built that is completely PHP-based instead of having a React component:

Social Mentions

#2218-meta, #3075-meta

These two tickets will enable more flexibility for the meetings functionality on Meta sites, which will allow us to include this meeting (since it is biweekly instead of every week)!

#recap #ticket-scrub #wordcamp

#1109-meta, #1751-meta, #2218-meta, #2907-meta, #3075-meta

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

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