Participants: @coreymckrill @grapplerulrich @miss_jwo @kau-boy @ryelle @sergeybiryukov
We started off by discussing some strategies for managing WordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. tickets in Meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. Trac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/.. 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.
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.
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.
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