[These forums] Encourage DIY

I would really like to see a change in the response pattern from staff here:
From: "We'll file a ticket for this request. (And implied...) Devs might look at this ... sometime in the near to far future, or only if it's approved. If it's not approved we won't tell you, sorry. If it is approved we won't close this forum request, sorry."
To: "We'll file a ticket for this request. Until we can look at this internally, here's how you might be able to do this yourself."

I understand that it takes a lot more effort to look into code than to file a ticket. But filing a ticket doesn't provide us with a solution when we came here looking for solutions. A ticket is a sort of "empty response". It's acknowledgement of a concern that still leaves the concern open for us to resolve on our own.

OK, if we need to resolve this on our own, could you assign a dev to just look at the code on our behalf, so that a near-term suggestion can be made to get us through the current challenge? With that hint posted to the ticket, a dev actually assigned to the task (if that happens) might be able to look at the suggestion as a clue about where to make a more permanent change.

Or ... does anyone have a better suggestion to accomplish the same goal, which is for us members to get more near-term solutions?

Thanks.

  • Fabio Fava

    Pretty cool suggestion. Sometimes we really feel like "helpless", and of course, when things happen we need fast (if not imediate) solutions. So imediate solution is the key. That said:

    As a "general behaviour", I've always got pretty much awesome solutions from WPMU DEV Support Chat. Sometimes, just having a chat helped me to find a solution by myself, and then I could provide the Support Staff solutions that helped others with that same issues.

    One I can remember is the "Defender Regenerate Salt Keys". After every update, you should go to that Security Tweak and change the auto-regeneration period to another, and then changing it back to your preferred period. Without this, it didn't work. I'm not sure if this issue was already fixed, but this workaround is so simple that it should be shared, avoiding many unnecessary support tickets.

    Cheers.

  • Nastia

    Hello Tony G

    Hope you're doing well!

    I apologize for the inconvenience and I'm sorry to hear that you're not satisfied how our Features & Feedback forums work. I agree that if you've asked for a new feature for any of our plugin we do not answer right away if this feature will get on the development list. To provide more transparency to our features list, we created a Product Roadmap page where you can see which features are under devlopment.

    Our Features & Feedback forums constantly being monitored by support staff and by our executive management team and we do not ignore any of your requests. If a feature you've requested is not included on this page, I am afraid it didn't make it, yet, into the development list. But there is a high chance for it to make it in, and it depends on how many requests a feature will have from other members. We will not deny any feature request and will not close a feature request's thread because there is always a chance that feature can be added to the plugin.

    Sometimes a new feature may need a lot of time till it will be developed and tested through, in this case, if you're looking for an immediate solution to develop this feature by yourself, please do not hesitate and ask if you're don't know where to start. Let us know in the thread that you're looking for a certain plugin's PHP hook or need a guidance what files you need to check to develop a new feature. We will flag our devlopers in the thread and will ask them to provide you some feedback (please note that we do not support custom development ) Our ground rule for custom development is time and complexity-based.

    If you have any more suggestions, please let us know!

    Kind regards,
    Nastia

  • Jaxom

    Hi Tony G
    I am not sure I understand your actual question.

    I understand that it takes a lot more effort to look into code than to file a ticket. But filing a ticket doesn't provide us with a solution when we came here looking for solutions. A ticket is a sort of "empty response". It's acknowledgement of a concern that still leaves the concern open for us to resolve on our own.

    The support, especially the new live chat, is second to none. I have always found the support staff go out of there way to assist in solving an issue you are having even with code issues from other plugins.

    In regards to feature requests I have also always found WPMU's community lead improvements and upgrades to be a fantastic way to get the great functionality we get with WPMU plugins and new things like the DOTW are just making the community leading approach even better.
    Yes some ideas don't actually make it to the final plugin but again that is generally because not enough members wanted it and why invest time just for a small few who would like a specific function (Still Waiting for the built in espresso maker)

    Maybe you could be a bit more specific, is this an issue with support or feature requests?

    Jaxom

  • Tony G

    To be clear, I'm a former Product Manager for a software company. Before that I was a QA Manager and before that I spent many years in Support departments in various roles. Now I manage projects for my clients, creating support tickets for every request and then I shift into developer mode to process the tickets. I'm completely familiar with the process of issue reporting, tracking, prioritization, rejection, processing, testing, and deployment, and the time and effort required for each stage.

    So let's look at how some of this is handled here. How do we follow the progress of a request?

    To start, I'm not sure whether the correct way to say this is that DEV uses this support software as a chat forum, or that they use forum software as a support ticketing system. Either way it's ineffective. Whomever started that just made a mistake in implementation. A tracker is a tracker. A forum is a forum. We can comment on tickets in a tracker. The tracker can reference the forum. But using the forum for tracking issues doesn't work for anyone here.

    1) DEV never updates forum posts to advise that an item has been discussed, accepted, prioritized, rejected, or processed.
    2) We never get an ID associated with a report. This is the function of an issue tracking system. So we don't have a clean way of checking on the status of a request. All we have is a record that we've made a forum posting.
    3) Postings here are never linked and closed as duplicates, another tracking system function. Every post gets a very cordial "great idea, let's see what others think" ... as though the idea is new and unrelated to some number of other similar requests.
    4) DEV posts a change log of things they've changed but there's never a reference back to close off tickets. So we have no way to qualify or quantify their responsiveness. We post requests, they post changes ... there is no visible connection between these processes.

    Please don't perceive/translate "the process is chaotic" into "the people aren't doing a good job". I also appreciate everyone on staff. I'm citing a lack of commonly accepted processes, resulting in public chaos. It's a suggestion that processes for support management exist and are commonly used for good reasons which are very evident here. This isn't about the quality of people, it's about what processes the people are charged with following. And this is not in any way related to some request not being processed or crying about some feature not being added. This is a general note about the entire process. I'm being pro-active, not re-active to some event.

    But rather than just citing issues, I usually prefer to offer suggestions to fix a problem with the least amount of interruption. Knowing what goes into support efforts with a diversity of products and a limited number of people, it would be insane to suggest a mass change here. So my topical suggestion "Encourage DIY" is a focus on one specific consequence of the chaos and a recommendation about how it can be turned around. The suggestion is for staff to not stop with "good idea", or with checking to see if a request has already been filed. The suggestion for all staff to do what a few here actually do, which is to offer code which helps people to solve their issues now, without making people wait until some time in the future when core changes might be made.

    Fabio Fava confirmed the value of this: A fix couldn't be implemented for Defender "right now" so a work-around was devised. Awesome! Where was that published? Was there a forum post that was closed after the plugin was changed? How will anyone else know what the problem and solution are, or when we no longer need a workaround, unless this is in public as an open ticket and then later closed? Why isn't there a silly dashboard/RSS update to let us know a Defender issue has an easy remedy until a code change is implemented?

    People should come to expect that their issues "may" be resolved with some code implemented now. We should educate people to understand that with FOSS, sometimes a small DIY code change can eliminate months of pain due to waiting for some patch that may never come. Such a process can help to eliminate some requests for changes that are reasonably rejected. That reduces the workload on support, management, and development, and leaves more time to process changes that actually do belong in the core. We all win when people have the knowledge and ability to make changes on their own.

    As a by-product, consider a popular request that people want but which doesn't seem to be in-line with company desires for a product. With code and knowledge posted in these forums, (and some miraculous way to search for it which is the topic of another one of my "lost into the black hole" notes here), people can find solutions here so that they don't need to bother Support. Again, we all win.

    And if you need to translate that into dollars and cents ... immediate solutions result in very happy clients. You won't lose clients with more immediate resolutions to challenges - whether direct from staff or with a bit of searching on these pages. Client retention means more and better revenue. This isn't an expense, it's an investment without new expenses, simply with a change of process.

  • Dimitris

    Hello there Tony,

    hope you're doing good today! :slight_smile:

    I really appreciate the feedback here, I've already shared that with our executive management team.
    As for providing more code snippets/instructions, this comes down to the scope of support we provide. If issue requires too much time, most probably due to complexity, and it's not a confirmed bug, then we forward to Features&Feedback section.
    We also use Asana as a tracker, rather than forums themselves, at least for requests that make sense to us, so we carry on our internal conversations in there.
    We also have in our to-do list to fine-tune search capability in forums, which will results to better track similar threads.

    Warm regards,
    Dimitris

    • Tony G

      Dimitris that's an excellent response, thank you. This has turned into a two-part thread, part one is on information about task progress, and part two is the DIY part about work-arounds outside of the task process.

      On part 1:

      As for providing more code snippets/instructions, this comes down to the scope of support we provide. If issue requires too much time, most probably due to complexity, and it's not a confirmed bug, then we forward to Features&Feedback section.

      Complete agreement there. Yes, "scope" must determine how far one goes in this area. Support staff can't take too much time to research details and code, they need to move on. Ash and others have done a great job of providing code when possible. I'm just encouraging more balance in this area - look or ask internally to see if a work-around can be found. This won't happen in chat, it's a background task. But offer code whenever possible.

      On Part 2:
      And I trusted that you have "something" internally - thank you for sharing usage of Asana. Consider this: Asana has an API and supports integrations, just like WordPress. Add a custom field to Asana tasks with the ID of a related forum thread. Occasionally update tasks with "public-suitable" notes and a @_forum reference to trigger a forum notification, versus a notification to a staff member. Create a REST client that checks for recent notes that contain @_forum. Use the custom field to get the forum slug. Use the WP REST API (or CLI) to post an automated note into the forum to advise interested members of the change.
      ...OR...
      Use the existing Zapier integration to post such updates to a log or RSS feed. Be sure to include the forum slug. We can read and parse the log/feed as desired. That completely eliminates the custom Asana integration And the WP integration.

      Dove-tailing the two... Let's say a developer looks at a task and thinks "it will take too long to really make this change, but we can work out a quick work-around". With the task open and the code in front of them, they can post just another note into Asana, and that information will then get to the people who are interested. The task can be put on the back-burner for later - but that's OK because interested members have their resolution. Live chat staff can also cite this same information. From here, it's member's choice about how to approach the problem: in the FOSS spirit they can implement the DIY solution, or with the cathedral and bazaar process they can wait for a product change. But now the burden is off of DEV to process that ticket for a while because a solution has already been provided. Again, everyone wins.

      Thank you for sharing these notes with management - that's the kind of confirmation I'm looking for, regardless of their decisions about how to, or not, pursue concerns.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.