How that feature is "supposed" to work

I think it's great to ask questions to clarify how Vanilla works and what our rationale is for decisions we made. I will always want to be asked those questions, and I love answering them.

What I'd like us to do is reconsider how those questions are formulated, and perhaps where they are posed. The question "What's supposed to happen when X?" (aside from the simplest interactions) is increasingly difficult for both support and developers to answer because of the breadth of our product and the myriad combinations of interactions that can happen. It's what we call a "leading question" because there's obviously more context behind the question that you're unintentionally withholding, and it creates frustration on both sides.

A great formula for digging into fuzzy Vanilla functionality is:

  1. The current action + the current result.
  2. Your expected outcome / current understanding (If you have one).
  3. The user's story of what they are trying to accomplish and why.

This is a ton more work to lay out than a simple "What's supposed to happen?" question, I know. But our team, product, and customer list are now reaching sizes where no one person can be the single source of truth. We need to have enough information to make good new decisions independently, re-visit old intentions or decisions, or write/amend the necessary docs so it's clearer in the future.

I also suggest that we increase how much we post those questions here on our staff forum, and use chat to either highlight those discussions or get quick clarifications before starting them. Support chat can very quickly get overwhelmed by feature dissection, and overlapping questions can easily cause confusion.

As we transition to functioning more as teams and less as individuals, there's going to naturally be some friction as we figure out these hand-off points. Just remember the other person wants Vanilla to work awesomely as much as you do. :chuffed:

Comments

  • radist
    edited November 2017

    I just want to add, I really appreciate all the work that all of you do in success, @BrendanParm @shaunamcclemens, @ValR, @Katie and @BrigitteP! I want to make sure that this feedback is not interpreted as you doing a bad job, but as the developers and support trying to maximize the usefulness of the answers we give you.

    You are are most important and powerful link to our customers, especially as support moves to being almost entirely filtered through your inboxes. When the customers have a complaint, you are going to be the first to see it, and our only means to have it translated and considered. We respect that all of your day is trying to make Vanilla the best product to fit the customers current, and ever changing needs.

    We're hoping that putting this information up front actually makes your jobs and lives easier in the long run. It should shorten how long you need to hand-hold a question/task to completion, and take the simple management of where a task needs to go and why from your busy day. From my end, it means that when a task comes my way, I'm forced to not only find out how it should work, but consider if its broken, not documented correctly, or the wrong solution to a particular clients problem. All of those considerations happen with every ticket I read, and you'll be facilitating that process.

    I do want to make sure you guys are still learning about Vanilla generally, and feel like you have input into its progress. If you have problems with the staff forum, or github, as vectors for your input, please let me know. I'm happy to include solutions for that in our search for software, and adjust the process in ways that can work for all of us.