The new time threw me and I ended up starting the meeting a half hour early. Apologies to anyone who may have arrived *on time* who ended up missing the first half hour of the meeting.
This week there were some significant contributions from @mdbitz for the help overviews, @trishasalas for the tooltip styling and @brainfork and @mdbitz for new tooltips. We also have some documentation now for adding new tooltips. Most things are now functionally in place and we’re just trying to fill in the gaps.
GitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ repo contributors
I didn’t realize this was possible until @trishasalas pointed it out, but I added some folks on as contributors to the project repo on GitHub. This essentially gives them commit/merge access but it also means I can assign tickets directly to specific people/contributors. If you are interested in jumping in and would like to be added as a contributor, let me know, but I think I got everyone who’s been submitting pull requests thus far. (Pull request can still be submitted normally, the only real difference is I’m not the only one able to merge them in and/or able to push commits to the repo.)
Tooltips on mobile?
I’ve opened a ticket to discuss how to (and whether we should) handle tooltips on mobile devices. My feeling is that the value of the tooltips is discovering them accidentally when you are trying to do something and mousing around the screen. User interaction on touch devices doesn’t work the same, and any kind of interaction that would generate a tooltip that I can think of would involve more intentional interaction with the interface, which defeats the purpose to me. I’m open to other ideas, though, if anyone has them. https://github.com/jazzsequence/WordPress-Admin-Help/issues/32
The plugins pages should have tooltips on them now (including the subpages), so we’re going to start working through the list of admin pages to add tooltips to. Now that we have documentation on how to add them, I would like everybody on the team (and anyone else interested) to try taking an admin page and start adding tooltips. We’ll use the spreadsheet to mark what’s been done and what needs to be done as well as allow people to claim pages so we aren’t stepping on each others’ toes. This will also draw more attention to the documentation we have, and whether it needs to be updated (and to what extent it should be updated). The more people we have working on these, the faster we’ll be done, and this is the biggest chunk of work in front of us right now.
On that note, we’re going to be looking into adding tooltips to the admin sidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme.. One thing I was thinking about from testing was how a lot of people would move their mouse around the screen looking for things to pop out at them to guide them to their task. A tooltip that appeared over “Appearance”, for example, could explain that that’s where you go to change the look and feel of your site which might otherwise be (and was) ambiguous to some users.
There are a number of issues we’re currently working on fixes for, but there’s probably a lot more we aren’t aware of. If you are testing the plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and are having some issue that hasn’t been reported already, please create a ticket for us on Github so we can look at it. Make sure you check the closed tickets as well as there may be some tickets that got closed for one reason or another.
I’ve created a number of tags to filter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. different types of tickets. This list is growing, but hopefully can give a casual observer a frame of reference in terms of what we might need help on and in what context:
needs testing means we need another pair of eyes on it to confirm that it is a) is happening for more than just the person reporting the issue and b) under what circumstances the issue can be reproduced. This status may also be used later for issues that have been fixed but need confirmation that the fix is working. These tickets are things where anyone is welcome to jump in and try to reproduce the issue and report back with their experience. The more information we have on these, the better.
question means the issue is open to the floor for feedback regarding how something can/should be handled. these may or may not be technical. anyone is welcome to put in their 2 cents.
priority-* refers to the priority of the ticket
wontfix means that, for whatever reason, this isn’t something that can be fixed. One example of a wontfix ticket is the $WP_Screen errors that appear with WP_DEBUG turned on. This was the only way we could pull in the existing help content without hacking core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. (and therefore is a non-issue if/when this gets merged into core). (If anyone has a better way to handle this, feel free to let us know.)
enhancements are tickets that will add some new functionality. unless assigned to someone, these are open to anyone who wants to jump in and comment or take ownership of that particular proposed functionality.
One issue that seems to resurfaced is that the add new tooltip on the plugins page is empty. I saw this early on but it seemed to fix itself and other people weren’t been able to reproduce it. It’s come back again for another tester, so we really need more testers to confirm to help us isolate this and try to figure out what’s up. Any assistance peeps can give is greatly appreciated.
How to contribute
The biggest things we’re looking for at this point in terms of contributing (if you aren’t comfortable working on adding in new tooltips) is testers trying to break stuff and people writing documentation. If you’d like to add documentation but not add in the tooltip or overview itself, you can create a ticket, paste your documentation in, and we can assign it to someone to add it to the plugin.