Does Spine need a Product Manager?

ciaps · 14 мар 2017

Hi community,

I use Spine since more than a year, and I am using Unity. I am not super happy with the state of things with the access to the information in Spine, and I'd like to hear your opinion. I will start with three critical situations that happened in the last week:

1) Spine 3.5 broke all my anims, as the setup pose was suddenly being mixed to the anim. I could manage to fix the anims by browsing and then ending up on this thread (Setup pose effecting skeleton when mixing interrupted); I had to trying all the alternative AnimationState.cs posted in there, and only one of them worked even though I had to try both of the amended AnimationState.cs files.

I would like to thank Pharan for providing this solution, but on the other hand I believe there is something wrong with the access to the information: for fixing this problem I had to browse forums for days, reading so many irrelevant comments, scouting for a potential answer, and all of this translates to time wasted.

2) Another example, is the Shaders topic: I'd like to try out normal maps, but every time I look for info, I get lost in multiple threads and it gets frustrating, as I am not a full time animator and I cannot be on top of every single topic, so that it becomes impossible to decode all the info in a reasonable amount of time.

3) Thirdly, the "Spawn hierarchy" feature of the Skeleton Utility. I have been striving to find the difference between the options "follow/override", and I have to guess I get it right from a few lines written here and there in the forums. Still, I am missing the info on what is the difference with using BoneFollower, rather than spawning one bone as follow. What are the pros and cons of each approach? In a similar way, what are the pros of using the SpriteAttacher instead of simply adding a Sprite as a child GameObject to a spawned BoneFollower?

Do you think that there could be a better way of handling knowledge transfer? Maybe a better experimental documentation, or an improved way to organize information? I have the feeling that Spine is handled by a bunch of really great guys, but I am outside of their "inner circle", so every time they are talking (on the forums), they throw a bunch of new and obvious concepts to them, but for me, as external developer that has to catch up, it is really hard to keep the pace and sort things out.

I think that you need something that in software development is usually referred as "product manager", which is a person that -as full time job- collects all the info in one place, prioritizes the issues, handle the communication with the users, provides timelines and keeps a record of what is working, official, experimental, upcoming and broken.

I feel that for being up to date with Spine, I have to do ALL of the following:

Read the documentation
Read the git md files (such as https://github.com/pharan/spine-unity-docs/blob/master/SkeletonRenderSeparator.md)
Watch the YouTube videos
Read the comments in the Example scenes of the Unity runtimes
Browse the forums being aware of the date of posting of each post

I hope this feedback will help improving the access to the information to regular people like me, as I think Spine is a fantastic product and you guys are doing a terrific job in helping out the community, but maybe things could work even better with some structure.

ciaps · 14 мар 2017

Mario · 15 мар 2017

Thanks for the honest feedback. We rely on write ups like this to improve. I understand your frustration, and we do definitely see a lot of potential to improve the state of things. Let me reply to your 3 points directly.

1) This is an issue with communicating changes on our end. The dissemination of the changes in AnimationState have indeed been lackluster. We've heard this feedback and have since introduced a CHANGELOG for all runtimes, you can find it here: spine-runtimes/CHANGELOG.md at 3.6-beta. Once we merge this branch with master, we'll also link to it from the main entry page of our documentation. It also doesn't help that we did not do a blog post on the 3.5 release detailing the changes. Going forward, this will not happen again.

2) This is a documentation issue on our end. For a common use case like custom shaders, skinning, etc., the documentation itself should contain the required information, at the very least the samples should show how to do it. We have an update of all runtime documentation in our roadmap that should cover all common scenarios in a runtime specific way. Given the amount of runtimes we have, I hope it's understandable that updating all of them will take some time.

3) Discussing the pros & cons of an approach is highly specific to your context, something documentation can not cover. This is where the forum comes in. As opposed to 1. and 2., I believe we excel at support on the forum. While we obviously appreciate you searching the forums for an answer to your question, there's nothing wrong with simply posting your question.

To summarize, we plan on doing the following going forward:

1) Communicate changes between versions on the blog and document the changes in the CHANGELOG in the runtimes repository.
2) Expand the documentation for runtimes heavily, including runtime specific documentation, as well as recipe based documentation for common tasks like skins, animation mixing, custom shaders and so on.
3) Continue being super responsive on the forum.

In terms of information sources for Spine users, we have the following:

1) To get news about changes in both the editor and runtime, the blog will be the #1 information source, linking to the runtime CHANGELOG.
2) To get documentation for both the editor and runtime, the documentation page at Spine: Documentation will be the main entry point. In addition to the textual documentation, the runtime repository contains examples for common use cases for each specific runtime.
3) To get help for issues specific to your context, the forum is the right place. If the issue turns out to be a bug or otherwise technical problem in the runtimes, we setup an issue on GitHub with a bi-directional link to the forum (that's how we handle it already).

Thanks again for your feedback.

ciaps · 21 мар 2017

Dear badlogic,

Sorry for the delay in my response, I have been very busy. Thank you very much for your extensive reply, it makes sense to be aware of what sources are to be considered priorities, so I'll keep an eye on those first.

Still, I would like to propose something else: what about having one person that "owns" the communication with the community? The solution you proposed, in fact, does not solve the issue of me knowing when I'll be having the runtimes for 3.5/3.6 working as smooth as before, and it is not a best practice that the users can talk directly to the developers every time they have an issue: even though it is awesome that the devs reply directly on the forums, in "corporate" world this behavior is not suggested as pushes the dev out of focus and generates unstructured and scattered documentation which is then very hard to put together. The main contact point should be a dedicated subject.

So this "owner" would actively act as a buffer between the users and the devs/support guys, in order to understand and anticipate the issues. This owner would make a list of all open issues and collect the temporary solutions to them, with pros and cons; the owner would also keep a roadmap (short-term, mid-term, long-term) so that the user can plan accordingly. The roadmap involves the concept of prioritization (what should be done first), and ideally the users can vote on what issue should be treated first through surveys.

The User-facing roadmap is different than the product backlog (https://waffle.io/EsotericSoftware/spine), as they serve two different purposes: the latter is a developers' tool, the former is stakeholder oriented. There lies the difference between developers' tasks and users' features, and it is exactly the line I was drawing with my first post: as a user I am not able to understand the waffles and their priority and how they translate to features.

Example where a PM would have been useful: I remember the "SetToSetupPose" behavior, for which there have been dozens of posts of people asking why the anims appeared to have a different behavior in the Spine editor and in Unity. In the end you had to write a dedicated page in the documentation, which is the right thing to do when you see a recurring issue, but this happened after at least one year since I experienced the "issue" myself. If there was a responsible subject whose job was to discover and collect the feedback, you could have optimized the workflow and not have to answer to the same question multiple times.

Finally, I would like to repeat myself saying that you guys are doing a fantastic job in supporting the community, and I do not want my words to sound too harsh behind a keyboard: I think it is only a matter or workflow, not a matter of intention or commitment.

Best !

Mario · 21 мар 2017

No worries, I don't think your feedback is harsh in any way, I appreciate it!

Making a list of all open issues is essentially what our issue tracker is for. We generally bi-directionally link between the forum thread that spawned the issue and the issue on the tracker. The forum post features the general discussion about the issue, including temporary workarounds. Of course, as you pointed out, going through a multi-page thread on the forum isn't something users want to do. What we can do is to put the current best work-around/pros/cons directly in the issue and update it as new information comes in. I'm not sure adding yet another information source (wiki/FAQ) is the way to go here, as then the problem becomes findig that information source.

As for a user-facing roadmap, I'm afraid the Waffle is the best we can do at the moment. Different users have different granularity requirements in terms of how issues should be described for them. Having worked in big enterprise for the past 15 years, my experience tells me there's no two stakeholders that think about ones product the same. E.g. one user may be interested in high level features, such as a new graph editor, another user may be waiting on a specific performance improvement in a runtime that's blocking their project.

As such, we chose to be as detailed as possible. In terms of priority, the Waffle details what features in both the editor and the runtimes will end up in what release. The filter in the top right corner allows to select which milestones you want to view. You can also filter by enhancements (features) and bugs for both parts of the product.

Priorities also vastly differ between users. Given the large number of customers we have, and their different priorities, voting mechanisms generally aren't the best solution. Instead, we gather requirements from customer feedback and then internally prioritize which features get added first.

Your "SetToSetupPose" example, especially the fact that it took a year to find its way into the documentation, is exactly the kind of problem we want to avoid going forward using the methods I outlined in my previous post.

I've tried to contrast our methodology with that of other companies in the same space (DCC software, e.g. Adobe, Autodesk, etc.). I do believe that in comparison, we are doing very well (which of course does not mean there's always room for improvement). Could you point me to a product in our space that you think we could learn from?

ciaps · 22 мар 2017

Hi there!

I think the best example would be Unity itself:

they have a user-facing roadmap with clear indication of what is delivered when, and in which version (beta or official). toghether with a voting system for new feature requests: https://unity3d.com/unity/roadmap.

and they have a one-stop learning centre where they have updated tutorials and scripting APIs per version https://unity3d.com/learn/tutorials, https://docs.unity3d.com/Manual/index.html. Cool thing is that the tutorial pages embed the YouTube videos, so that they are put in a context.

Obviously behind Unity there is a muuuch bigger organization, I do not expect things to be at the same level, but you asked me, so I answered!

Mario · 23 мар 2017

Ok, it looks we aren't too far off.

For the roadmap, the Waffle is the equivalent. The Unity roadmap items are actually surprisingly low-level as well (mixed with some high-level features), so I think our roadmap item granularity is OK. We don't have a fancy per-version overview like Unity, but that can be "simulated" by selecting a milestone in the Waffle filter settings (milestone -> version). As for voting, I've outlined above why we currently do not do that.

As for the one-stop learning centre, Unity's overview layout is better, but we too have a high-level entry point, with detail pages Spine: Documentation. We also embed YouTube videos within detail pages, e.g. Images - Spine User Guide: Video

We'll try to improve