Developer support log
Notes on changes that would reduce support requests from the final sprint of 2015 (Ryan's shift):
- Editing locales: self-serve or train support to search source.
- Export data: self-serve entire forum & user info (name, email).
- Docs clarity: Smarty permission, etc - use docs to answer the original question.
- Warnings: settings for levels & time in Dashboard.
- Self-edit some configs: Connect Sync is 1 example.
Let's start consistently adding summaries to this after our biweekly sprints end, @beckyvb & @ryan. And re-mentioning previous ones that were an issue again. We don't need an exhaustive list, but maybe 3-5 good points on how to make things better in the big picture.
Comments
-
I'd like to learn to search source even if we plan to make locales self serve. I think it was explained to me once before, but a little meeting on it next monreal week would be helpful.
0 -
Brace yourselves.
Week One
- Day One: ~25 tasks (15-20 backlog from previous support sprint)
Issues closed: 40
- Core: 15
- Addons: 3
- Groups: 2
- Client: 14
- VanillaStats: 1
- Data: 6
We saw an influx of issues as a result of the VIP deploy (customizations needing updating, category woes, etc.)
Week Two
- Day One: 6 tasks, (2 punted from previous week)
- Issues closed: 35
- Core: 14
- Addons: 3
- jsConnect: 1
- Subcommunity: 1
- Groups: 1
- Client: 4
- VanillaStats: 1
- Data: 10
Notes
- 14 GitHub issues filed!
- Need a way for any developer to sync Transifex updates to the locales repo. (working on this!)
Need a way to globally address
Vanilla.Categories.DoHeadings/Vanilla.Categories.MaxDisplayDepthVanilla.Categories.DoHeadingsneeds to be removed and category adjustments made, where enabled.Vanilla.Categories.MaxDisplayDepthlikely needs to be incremented where Vanilla.Categories.DoHeadings was present
Unless critical, maybe have a defined scheduling limitations (e.g. starting Thursday, new issues can't have a due date that's Friday of the same week).
- I'd like to get back to having a parent task the CSMs own, with subtasks the developers own. I think this would help avoid having to re-open tasks, allow the dev to clear things out of their queue without waiting for client feedback and still give a central discussion location the CSMs can use to track/document progress.
- Highlights (these were agonizing to troubleshoot)
- Category caching causing invalid sorting
- JSON delivery method silently failing when binary IP data was slipped in
Any questions? Fire away!
2 -
- The categories heading/depth issue needs a detailed issue filed and sprinted if one hasn't been yet.
- We'll formalize a Thurs lunch hand-off in week 2 of sprints.
- Our only hand-off between developers should be that 1.5 day overlap. If more than that is carrying over, I want to know why and look at the tickets.
- I'd like to start digging into the "Data" category of support issues. These are ripe for automated tooling if we can prioritize how to deal with them.
- I'd like to see clients/VIP repo issues primarily dealt with by the services team wherever possible. If an R&D dev needs to go in there, they should at least be training someone on the services team on what they did and why.
0 -
I've generated a report of my TW activity as a support person, and it turns out that trying to parse it for stats is aggravating. Stats are fun, so I'll be more diligent next time I'm a support dev to document as I go.
Other than that, here are some things that I learned:
No matter the size of the bug. If there's a a bug fix that you cherry pick to the release branch, don't just deploy it to the cluster that reported it. Deploy it everywhere. Same applies for master branches and public clusters. This should be the case for the support dev and any other dev. There were a few tasks that came through and it was just a matter of deploying the fix to the appropriate cluster. Not deploying a fix everywhere is extra work for support, extra dev work (to investigate the issue) and annoying to clients. Perhaps a jarvis command to facilitate this would be useful.
Stemming from this, if there's a bug you fixed in master and it's fairly localized, cherry-pick it into the release branch and deploy everywhere.
There are still category-organization issues getting into the support queue. I get it. It's a big part of Vanilla, there's no documentation on it, and nobody wants to destroy a client's forum by reordering their categories improperly. I think we need to document the category organization better and maybe have a meeting with support and devs to make sure everybody is clear about previous issues with categories and how reorganize them using the new way.
Tags are confusing. Why do non-editable tags show up in the dashboard? I understand that plugins use Tagging to achieve their ends, but it's not congruous with how clients understand tagging.
Limitations of Sphinx: Sphinx doesn't pick up moving discussions to a new category. We'll need to reset the index (see Tim) for the discussions to appear in Sphinx.
Finally, I want to start a conversation about my philosophy when we get a support task for something the client has broken in their settings. (i.e., Pockets, Customize Theme, etc.) I usually tell the CSM what the fix is, but I don't fix it myself. I hope that CSMs don't then fix it themselves, but pass on to the client what the fix is. This educates and empowers the client to fix their own settings and also makes it clear to the client that while we were able to find the issue, it's not an issue that we created. It looks better on us. Of course there are exceptions, but as a general rule I think this is wise.
1 -
Stats
Issues resolved by group
- Questions / Unverified: 10
- Bug/Waiting: 3
- Exports / Import / Data Fix: 19
- Product Triage: 5
- Other: 3
10 github issues filed for future sprints
11 PR merged to fix urgent/simple bugs related to the support tasks(Ryan also did 2-3 issues and multiple PR to solve the cookie problem)
Notes
Multisite hub/sitenode is not documented at all. You really have to dig in to understand how it is working so when you get a bug about it you lose a LOT of time.
Adobe for instance propagate configuration to its nodes using the "NodeConfig" option in the config.
This is not something that can be configured using any UI and it can override any configuration on a node.The SSO documentation is getting better and better but we are not there yet. There are so many little things not explained in there.. The process of englobing user synchronization should be clearer.
I really like the new system where CSM have a task we have our own task with the CSM's task referenced in it.
0 -
Stats
Issues resolved by group
Questions / Unverified: 15
Bug/Waiting: 3
Exports / Import / Data Fix: 15
Product Triage: 6
Other: 85 PR merged to fix urgent/simple bugs related to the support tasks
Notes
A whole lot of issue were coming from 311 or VIPs that we deployed. (Zenimax, MFP)
Polycount and MFP decided to go on a bug hunts... They filed ~11 issues in the second week.MFP also had a big misunderstanding of how the troll plugin works.
By searching in teamwork I not only found that we addressed that same problem in the past with them but it seems that many clients do not understand that the troll plugin do not block discussions from being viewed. It only hides them from the lists. Even the CSM had trouble understanding that concept/0 -
2017-01-16 Support Sprint
Issues by List
- Appearance & Theme: 4
- Bugs/Waiting: 2
- Exports / Import / Data Fix: 18
- Inbox: 1
- Product Triage: 5
- Questions / Unverified: 32
- Security Investigations: 1
- SSO: 5
Issues by Cluster
- CL211 (Stage 1, Primary): 3
- CL213 (Stage 3 , Multi Stage): 1
- CL311 (Standard 1, Primary): 8
- CL411 (Priority 1, Primary): 13
- CL412 (Priority 2, Primary): 24
- CL521 (Zenimax): 1
- CL524 (Adobe): 6
- CL528 (Edmunds): 1
- CL529 (Hobsons): 3
- CL530 (My Fitness Pal): 4
- CL531 (EA Multi Site): 1
- CL536 (MMORPG): 1
- CL549 (Kabam): 1
- CL550 (Cox Media): 1
Notes
These figures are comprised of the 68 issues I closed over the past two weeks. They do not include the half dozen I reviewed and handed off to services or the couple I let slip into the next support sprint.
From what I can tell, there wasn't any single thing that caused the surge. It was a very diverse collection of issues. Very few, if any, seemed to come from deploys.
I harp on this a lot, but I'd really like to get back to the CSMs having a task and the support person having a subtask off it. I don't think I had any tasks this sprint that were setup like that. The CSMs could decide when the top-level task is done and close it. The support person can do their part and close their portion of the task. If multiple people are needed to act on a task, multiple subtasks can be created. If the task needs to be re-visited, you can add another subtask. You wouldn't need to re-open the primary issue. Re-opening the primary issue throws off issue tracking, because it alters the completion date. If I complete an issue in the first week and the issue is re-opened in the second week because the client had follow-up questions, the "completed" date would then be moved to the second week. There'd be a loss of time and completed issues in the first week. When CSMs or support create a task, they'd just need to assign themselves to it and can create an identically-named subtask that goes to the support dev.
Lots of spooky things happening this sprint for currently-unknown reasons: users losing their conversations (pooldemo), couple of users being banned with no trace of why (plex), views failing to be found that are definitely present (Zendesk plug-in)
2
