@frarf Yes workflow is a major pain point, there is another thread about this were I shared a couple of workflow tools that can help out until native workflow is improved more [#72]( Workflow Case Study - Show us your pain! page-2#post-5266593).
- Not really I guess I got too illustrative with those arguments, I was basically trying to show the problem of expectation about stability, using “communication” about them as way to sorts these expectation.
- Yes, but that’s not the core of the problem, communication was an illustration.
So I’ll try another take, ie think like a developper, that’s one thing people have been reproching unity to do, to not make game, hence not understanding what are the stakes are.
The problem is that the language used is imprecise, bleeding edge and stability mean different thing in different context, so let’s outline these context when making a game. Basically when making a game and evaluating features the most important thing is workflow, or “don’t waste my time or create risk” ie getting stuff done as painlessly as possible, the way unity handle features is hella risky for a dev, it create uncertainty.
What stability really mean is that I can project myself ahead and see my game done, as such there is 3 phases:
-
Evaluation: I’m going to test something to see if it’s worth it and if I can risk a whole project on it, ie is it useful? I’m evaluating the promise it give, stability of code or api don’t matter much, HOWEVER stability of features (or promise features) is important, because I’m betting for them to still be there or be ready when the game ships. That’s experimental, we are experiment to see if it will worked out and make a decision based on outcomes, or bail out when no cost has been spent.
-
Investment: We made a decision to use the features. Since making stuff take some time, I can anticipate and go through the pain of investing in a features that isn’t ready and is unstable, HOWEVER I do expect features to be on the locked down, I expect bugs to get fix, and I can help finding them, I expect workflow to get better other time, and no threatening change to happen that would jeopardize the project, I expect communication to flow such as it makes the features better and more adapted to use cases. That’s the bleeding edge.
-
Risk aversion: I want something that works out of the box and is battle tested, in order to have as few surprise as possible, it solve a problem well, have great painless workflow, and help get stuff done, it’s well documented so when we hit a bump it doesn’t stop the project, and basically allow us to plan ahead with great precision. Most major bugs have been solved, and it’s on maintenance. The features is complete, and basically upgrade are quality of life stuff. This is all about feeling safe, it should just solve problem.
These phases basically correspond to the alpha, beta and released. People might have different tolerance between 2 and 3, and most risk averse would rather skip 2. IMHO numbered released should be most 2 and 3, locked features and only improvement, with clear deadline about finishing the features.
The problem is that unity has become massively threatening to this publique, out of the blue depreciation, giving up entire features, unkept promise deadline that kept being pushed, sudden change of method or sudden obfuscations. All these problem create stress on project management.
However, it’s not say there is no any merit in a wild west approach, like I have outlined, the communication and access should be different in that case. Some project of unity handle this with the github repo, these are clearly separated and understood as not ready. There is 3 publiques for that part, the tinkerer, the “student”, and the NIH. They are all on the over side of “bleeding edge” and generally don’t mind instability but hate obfuscation. They aren’t doing risky project.
A. The tinkerer is someone who will always test new things and contrast methods, he doesn’t have a project in mind necessarily, or the project is build organically by testing the features, he is going to deconstruct and propose endless alternatives and make blog post and theory about a technique. They look for problem to be solved and a pallet of solutions.
B. The student is interested is learning how the sausage is made, he look at stuff to remake it and gain an understanding, will probably make a tweet showing the result, or write a blog post to explain how it’s done to layman. He can help spread awareness about the features and explain what’s great about it.
C. The NIH (not invented here) will just took a peak at teh code, and redo all of it or part of it on is own. He is never satisfied with the offering, and will make some adjustment or add elements, will probably do another repo to share his implementation or sell it on the asset store. He help make alternatives and cover the niche that can’t be filled. The NIH can be doing legit project, redoing a features provide the safety net and control they couldn’t have otherwise, it protect them from incoherent changes. However sudden obfuscation takes away their responsibility and make them mad.
The problem is that unity conflate the two publique in analysis, so they provide Chaotic LTS for “the bleeding edge” and is surprise some people want stability even in alpha and beta, but then equate stability more as in code rather than proper workflow. Ie Unity don’t make games as an organization, and therefore cannot conceptualized the real stakes and proper solution.
5 Likes
What is your understanding of the Unity tech releases (eg 19.1, 19.2…) vs Unity LTS releases?
- Tech releases add new features every release. Some others may be deprecated. Things may change reasonably between each release.
- LTS are “frozen” Tech releases that don’t add new features and receive fixes and platform upgrades only.
When you see a new Unity release, what is your expectation of quality?
I should be able to install it over my previous Unity release (Tech or LTS), upgrade my projects by following some upgrade notes, and continue working normally.
I don’t expect crashes, show-stopper bugs, serious known issues (!). If the issue is known, DON’T release the new version until it’s fixed!
I can expect that things may change between releases, and some times without backwards compatibility. That’s understandable. That’s what the conditional compilation defines are for (#if UNITY_2018_2_OR_NEWER). you can write your code being aware of the Unity version (therefore the precise features and API available) its being used at.
Currently that’s impossible with Packages. There’s no way to know even if some package is installed or not, so there’s no way to write code that could survive different project setups.
Do you expect different levels of quality or completeness based on the release distinction?
No. I expect both Tech and LTS releases to be completed, tested and documented.
Uncompleted / untested / work-in-progress versions can’t be released as Tech. I understand that’s what the alpha and beta channels are for. A beta version can’t be promoted to Tech until it’s feature completed, tested, documented, and all the known bugs and issues are fixed.
I can perfectly understand Tech release dates being pushed forward while all known issues are being fixed. Hell, I’d even understand not having a settled release date at all. People wanting / needing to use a specific feature as-is can get the version from the Beta channel anytime.
However, I feel there’s too much pressure put on Unity versions to be released at specific dates: GDC, Unite, keynotes, etc. That makes some version to be thrown at us as a Tech release with a huge list of known issues behind it (which is subtlety moved to the bottom of the Release Notes, btw).
What is the primary motivation for you to use the LTS vs the non-LTS version of Unity?
Stability. It may not have all the bleeding edge features, but it allows me to spend my time making games instead of fighting with the engine.
When we say something is in Preview, what does that mean to you? Why do you feel that way?
I feel it like a nightly build. Like if you give me access to your own development repo. Devs are working on it and everything may change / break / malfunction anytime. My own experience is lighting being entirely broken in a HDRP project as result of a minor upgrade in the package.
Does the expectation of quality change when you see something in Preview?
Yes. As said, it feels like a nightly build to me. I don’t expect any quality at all.
What drives you towards using something in Preview?
In the best scenario I may take a look at how it works or its requirements so I could start adopting design decisions in my projects that could make easier to integrate it in the future, once it’s released as stable.
Otherwise I may have a peek at some upcoming feature, maybe taking some nice pics or recording some video… But I won’t spend too much time on it, nor won’t do anything serious with it.
What keeps you away from using something in Preview?
It’s a nightly build! Everything may change, break, explode, or become completely unusable from a version to another. How could I use it for anything but some personal amusement?
What bothers me most is that lately every new Unity feature is thrown at us as soon as a nice video can be recorded of it. These features are pushed to us like they’re production-ready and we’re encouraged to use them, but in the best case these Preview features are 2-3 years away from being actually stable and usable in production.
Feel free to ask if I can be of further assistance.
7 Likes
This. This right here. The amount of issues that are known to unity yet the version gets released anyway is insane. It should remain in beta until all issues are resolved. Even if users keep finding new ones. ESPECIALLY if users keep finding new ones. Just pushing it out and saying itll be solved in a further patch release, minor version or major version is NOT proper software project management and will yield worse problems down the line.
Case and point: Where we stand today. We wouldnt be here had this not been happneing repeatedly for the last 18 months.
7 Likes
I expect the next marketing tagline to be “robustness by default”
4 Likes
Performance, robustness, stability and future SRP compatibilty by default.
2 Likes
I mean, if we’re asking the impossible, I’d like an ostrich.
3 Likes
@smcclelland Please find below responses to your questions and a few extra followup points/issues.
Core product questions:
1. What is your understanding of the Unity tech releases (eg 19.1, 19.2…) vs Unity LTS releases?
I understand that LTS releases will have 2 years of ongoing patches to improve stability over time. The TECH releases are incremental “major feature” update releases. I understand that these will be feature complete, but that patch releases will only be available until the next TECH release lands. I risk having to upgrade to a less-stable-but-newer TECH release of Unity to receive a fix for an issue I’ve encountered as fixes for the now-current TECH release of Unity will not be backported to a prior TECH release.
I see TECH releases as “feature previews”.
2. When you see a new Unity release, what is your expectation of quality?
When I see a NON-ALPHA or NON-BETA release of Unity, I EXPECT a very high level of quality. I expect that the baseline performance be at or above the previous major release. I do not expect to encounter many crash bugs, if any.
Recent versions of Unity have lead me to ASSUME that the quality will be far lower than what I expect.
3. Do you expect different levels of quality or completeness based on the release distinction?
No. I expect the same level of quality and completeness for all official releases of Unity, regardless of TECH or LTS distinction. I assume that an LTS will be of slightly higher quality, only because it’s the same exact thing as a .3 TECH release with a few patches already applied.
The ONLY time I expect different levels of completeness is when I’m playing with an Alpha release.
The ONLY time I expect different levels of quality is when I’m playing with an Alpha or Beta release.
4. What is the primary motivation for you to use the LTS vs the non-LTS version of Unity?
I understand that the LTS version of Unity will actually get bug fixes. If I file a bug report for a TECH release, the fix may arrive, but it may arrive in a newer TECH release than the one I’m on. If I’m on LTS, there is an expectation that bugs will be addressed with a follow-up patch (at least within the 2 year cycle).
Package specific questions:
1. When we say something is in Preview, what does that mean to you? Why do you feel that way?
There are two parts to this story.
- Before I started using packages. My understanding of the “Preview” tag was that the features were ready for public consumption; that they would have passed a “Unity Quality” check. Further, I understood that they might see changes based on user feedback, but that this would likely be rare. This would be compared with a feature referred to as “Experimental”: such features should be avoided unless you simply want to see what kinds of things Unity was working on for future versions and/or wanted to provide feedback to help direct that feature’s development as you saw yourself as a core user of said feature.
- After I started using packages. I understand that Preview packages shall not be trusted for more than, say, a game jam. They are some Unity Engineer’s (or Team’s) pet project and will have major version increases at random times with bug fixes really only applying to the bleeding edge version (which may not be compatible with your version of Unity). The “Preview” label actually means “Experimental On Steroids”.
As to why I feel this way, a lot of it has to do with trying to understand what version of a package is compatible with a particular version of Unity. The experience of going to the documentation site and having to scan multiple version Changelog pages for some inkling of understanding of compatibility and seeing no clearly documented rhyme or reason for a major or even minor version increment left me feeling like there is zero care given to semver versioning and a blatant disregard for potential downstream affects on possible package users.
Steer clear of “Preview” packages at all costs unless you need the feature only temporarily.
2. Does the expectation of quality change when you see something in Preview? What drives you towards using something in Preview? What keeps you away from using something in Preview?
As there are multiple questions in this question, I’ll break them out to respond individually:
-
Does the expectation of quality change when you see something in Preview?
It changes, yes, but only marginally. I expect the occasional bug, but I expect it only when I recognize that the thing I’m attempting to do may be a bit “odd” or “unexpected”. Script errors/warnings, bugs with targeted integrated systems/packages, etc. should not happen. If that is the case, then this package should not have been released. The “Preview” label should not be an excuse. -
What drives you towards using something in Preview?
When there is a feature that I need now. As I mentioned above, I will install Preview packages if they supply a feature that I need in the short term. One really huge example is the Unity Recorder. This is a pretty amazing package that recently helped us record footage of a demo we’re building at 120FPS@4K. It worked flawlessly. That said, it hasn’t received an update since December 1st, 2019 and is left in the “Preview” state. Every version of Unity Recorder 2.0.x was marked as “Preview”. The latest version is 2.1.0 and it is also marked as “Preview”. I would never add such a package to a project where it was integral to the operation of the project itself as I have zero confidence around what the package maintainers intend to do with the package or when they’ll decide to bless a specific version. In the case of Unity Recorder, this is simply an external feature that I can install, use, and then remove. -
What keeps you away from using something in Preview?
Generally three things: -
The understanding that this package is probably going to be a mess.
-
That I have no clear idea what version of Unity this package is compatible with.
-
That I have absolutely no idea of release cadence or timeline. Is this package ever going to leave Preview? When? Will the version of Unity I’m using be supported when it does? There are no answers to these questions.
Bonus Content
On Features-As-Packages
I have to admit that I was pretty excited to hear about the Packages initiative for Unity. My original understanding of the idea here was that we would have an extremely small “Unity Kernel” installation into which we could install only the features that we wanted. Don’t need physics in your game? Great! Don’t include the package. Using a different audio engine? Sure! Skip on the AudioSource system.
However, I also expected that each release of that “Unity Kernel” would have a fixed version of each of the associated packages/features. What this would look like with the Unity TECH/LTS versioning system and, say, the URP package, is the following:
- Unity 2018.4 LTS: The compatible version of URP is 2018.4.x. It will continue to get bugfixes for the same duration as the 2018.4 LTS “Unity Kernel”.
- Unity 2019.1: The compatible version of URP is 2019.1.x. It will only receive bugfixes while the 2019.1 TECH “Unity Kernel” version does.
- Unity 2019.4 LTS: The compatible version of URP is 2019.4.x. It will continue to get bugfixes for the same duration as the 2019.4 LTS “Unity Kernel”.
As a bonus, I might further have the ability to install versions of packages that aren’t specifically “in line” with my version of “Unity Kernel” but that I would be operating on my own (unless “Verified” to also work on certain previous versions). In this manner, I could conceivably update some packages to a newer version while understanding that what I’m doing may involve taking on some risk on my part. (This would look like installing a package with version 2019.2.x into a project running in “Unity Kernel” 2019.1.x.)
It remains my hope that something like what I described above can shake out of all of this current mess that we seem to be in…
On Package Versioning Issues
There’s a serious issue with package version and change communication right now. The Changelogs between various versions of a package (particularly the SRPs) are inconsistent and show different information. Take, for example, this set of steps:
- I have just read one of @jbooth_1 's posts about compatibility issues between URP 7.1.8 and 7.2.1. I would like to see what changed in the package.
- I toss “universal render pipeline” into Google and see that the very first hit is a link to documentation for com.unity.render-pipelines.universal@latest. Perfect.
- That link actually took me to the page for version @8.0. I now see that version 8 is out.
- To see what has changed, I click the “Changelog” link at the top. I start looking for changes between 7.1.8 and 7.2.1. But… wait! Neither of those versions are listed?! What the hell is happening here? I see 7.0.0, 7.0.1, and 7.1.1. It then jumps to 8.0.0. After poking around the page for a bit, I notice that there’s a version dropdown in the top-left corner. I click it and see options for 7.0, 7.1, and 7.2.
- I click the link for 7.2, which takes me a different Changelog. I now see versions 7.0.1, 7.1.1 thru 7.1.8, 7.2.0, and 7.2.1.
Why weren’t those versions all listed in the same Changelog? What is going on here? It’s already impossible to get any idea as to what package version is expected to be compatible with which version of Unity… now it seems we need to also jump through hoops to actually see what enhancements have been made over time… (For the record, it appears that this is due to Unity maintaining separate release branches in GitHub for the render pipelines [7.x.x; 8.x.x].)
Usability-wise, this is… less than ideal.
I hope this is helpful.
10 Likes
Wouldn’t change a comma. The changelog thing is so ridiculous it makes me question how it got into production. Is the most backwards way of making a changelog I can think of.
3 Likes
As a sidenote, I’d like to point out that the 8.0 and 8.0.1 changelogs concern version which “came out” (are to come out) on may, 25th…
1 Like
My company is developing VR experiences which are used to prevent accidents at workplaces and which are used in the medical section. Because of long term support questions for hospitals etc, we’re bound to LTS versions.
To me, LTS version should contain 2 kind of changes:
a) bug fixes
b) performance improvements
Any bug that is found in an LTS version should be fixed. I don’t want to see any “cannot fix in LTS, you need to switch to a later version” kind of excuse. This kind of “advice” is bad business behavior.
I wonder if Unity has any kind of ISO certification. The way bugs, requests and customers are handled wouldn’t pass ANY software development ISO certification. We’re currently going through the process of ISO 13485 certification (QMS/Quality management system) which means that we have to be sure that any third party software that is used to produce software for a medical device is up to a certain standard (i.e. ISO 9001 or ISO 90003 + ISO 12207 (“software lifecycle processes”)).
Taking a look at how the entire 2019 cycle has been managed, I highly doubt that Unity as certified in any of those processes…
8 Likes
And this despite the fact I reported the incorrect date on the github commit where the original error was made
1 Like
Battling packages and the editor stability and compatability issues and lack of documentation issues and trying to work out why X doesnt work and Y now does work and trying to find a single minute to actually work on your game/product, is the current unity end user experience.
Thats about as concise as I can summarize it.
7 Likes
What is your understanding of the Unity tech releases (eg 19.1, 19.2…) vs Unity LTS releases?
Tech releases are basically feature previews. They’re useful to start developing features on for our next release and then we can upgrade to the LTS before delivery. This only works for features included in a Tech release that are actually out of preview of course.
When you see a new Unity release, what is your expectation of quality?
The upgrade should be as painless as possible, but more importantly it shouldn’t break anything. Case in point, since upgrading to 2019.3.3 (in anticipation of the next LTS release) it turns out our VR implementation’s framerate has turned into a slide show.
I realise that with the many different configurations you can now make of Unity + packages it’s easy to miss one in your testing cycles, but we have the exact same issue further down the line and a much harder time tracing the causes. A new version should be tested with all packages and all packages should be updated to work with it. Or if they can’t for whatever reason, they should be marked as “not verified with X” and that should be in the release information of the Tech or LTS version.
Do you expect different levels of quality or completeness based on the release distinction?
I expect all releases to be stable and high enough quality to be used to create a game and release it commercially. For me the difference lies in the LTS receiving fixes for the more obscure bugs that are only found after long term use, or that come up with changes to drivers or similar.
What is the primary motivation for you to use the LTS vs the non-LTS version of Unity?
We offer long term support to our customers so need our product to be built on a long term supported version of Unity.
When we say something is in Preview, what does that mean to you? Why do you feel that way?
It’s an alpha version and I can’t rely on it at all, because the API’s of the ones that I have tried have shifted before the Verified versions roll around.
Does the expectation of quality change when you see something in Preview? What drives you towards using something in Preview? What keeps you away from using something in Preview?
Preview means it’s a work in progress and the final version will have different functionality and a different API. I mostly use preview packages to try out new functions and give feedback on them.
1 Like
-
What is your understanding of the Unity tech releases (eg 19.1, 19.2…) vs Unity LTS releases?
-
Each TECH release contains new features and bug/annoyance fixes, which are stabilized up to until the next TECH release, when they are dropped as a rock. Due to deprecations, feature breakage, possibility of new bugs and performance regressions on new TECH releases, upgrading from one version to another during project development is a risky business as it’s not possible to estimate how much effort it will take, or even if it’s viable at all (if your game rely on a feature that got removed, or a major rewrite is necessary due to significant API changes).
-
The last TECH release will get promoted to LTS at some point and will get platform SDK updates, and some bug fixes for two years: even during LTS period, there are bugs which are only fixed on newer TECH releases and are never “backported” into LTS.
-
Based on the above, I view the TECH releases as having limited usability for shipping games on. Their stability is a gamble: there’s no telling which project-affecting bugs will still be unfixed when the next TECH version is suddenly released and the old version is dropped like a rock.
-
For mobile games the TECH releases are unusable since Apple and Google now have tight requirements on keeping your platform SDK updated, forcing your game into upgrading to a newer Unity version every year, unless you have deep enough pockets to buy a source license.
-
When you see a new Unity release, what is your expectation of quality?
-
I would expect a new non-beta release to be fully usable for shipping, with maybe a few bugs that should get ironed in two or three patches. But…
-
Right now I consider any non-beta Unity release to be unusable until it gets half a dozen patches or so. Based on the kinds of bugs that get reported on the forums, and the occasional staff response, it seems to me that the internal testing these releases go through is insufficient and not reflective of how Unity is used in production, and they depend heavily on adventurous developers who actually use the thing all the way to actually hit the bugs.
-
A new LTS is different, of course, as that’s actually a TECH release that got through more battle testing.
-
Do you expect different levels of quality or completeness based on the release distinction?
-
Yes. If something is labeled LTS, it should have a minimum guarantee of stability. However, the TECH releases are promoted as “the new Unity version” and thus should not be blowing up on people’s faces after they leave beta.
-
What is the primary motivation for you to use the LTS vs the non-LTS version of Unity?
-
Being able to work on a year-long project without being forced to upgrade Unity mid-development due to a crippling bug or an unsupported platform SDK. Upgrading a project to a newer Unity is always risky business: 3rd party assets may-or-may-not work, APIs may-or-may-not change, features may-or-may-not disappear entirely, things that used to be fast are now slow. For us who actually make games on Unity, that costs money. The last time I had to upgrade a Unity project it took one developer two whole months.
And more package specific questions we would like feedback on:
-
When we say something is in Preview, what does that mean to you? Why do you feel that way?
-
That stability and performance are not guaranteed, it’s not rigorously tested, APIs could change massively between releases, and that the package could be abandoned at any moment.
-
I feel that way because that’s how it played out with many of the preview packages.
-
Does the expectation of quality change when you see something in Preview? What drives you towards using something in Preview? What keeps you away from using something in Preview?
-
Yes, I assume it’s not to be trusted for production.
-
I avoid using preview packages unless it’s for non-critical Editor-only tasks that are unlikely to harm packaged builds.
-
What keeps me away from preview packages is that there’s no guarantee they have been battle tested on multiple platforms for performance and stability (or even work on multiple platforms at all), that their APIs won’t be overhauled and require me to rewrite all me code over and over again.
IMO, the new-SRP-features-on-2019 is a special case: there was a large miscommunication during the 2019 cycle about which SRP features were being worked on, which would make into 2019 and which wouldn’t, causing the impression of broken promises.
Also, the fact that something like spotlight shadows requiring “core editor changes” is troubling in regards to the stated goal of the SRP: to expose rendering to the C# side and allow users to code whichever render pipelines their projects require. If something like this requires modifying the editor C++ code, then it means the “S” in “SRP” is not doing it’s job correctly.
Reading more of this thread and, as I see it, there are two big problems here:
- New stuff being released incomplete.
- Lousy communication & marketing making it incredibly unclear all that is incomplete.
I’ve been in a similar position before and I’ll give this one to marketing for free: if you have no big shiny features or partnerships to announce at the next Unite, but instead just spend the entire keynote building a game live on stage your userbase will love it. Because that would show us that you’ve managed to stabilize the product and that the features in it are actually complete and work.
Unity doesn’t need big new things. What it needs is for the things it has to be polished to a high shine. Your editor’s GUI has been overhauled to make changing it easier, keep going and improve the workflows in it. Improve the package manager so it’s clear what I have installed and what I can install, what needs updating, WHAT THAT UPDATE WILL DO, etc, etc.
And finally, for the love of all that’s sacred, invest in getting your documentation sorted. I do not want to have to dig through the forums for links to google docs to get the upgrade notes ever again!
4 Likes
Above all: triple or quadruple your docs team.
I know it already tripled a year or two ago, but it was not even close to enough. Things are so out of hand with docs that its stopped being a running community joke how bad they are, and has seriously started to get to people.
How many times over how many years are you going to hear your customers complain about this, many of which are paying customers (or would progress to become paying customers if simple things like docs were taken care of and showed investing in the engine instead of just investing in random aquisitions all over the place) before actually doing something about the docs?
Hiring a few more people at this point will not cut it, you need to literally multiply the teams current size by a serious factor - and then be very vocal about it so the community knows you have finally invested in something the community actually consitently asks for.
Nothing out of beta should be undocumented. Beta should be when you make your docs. You should never be previewing something for public use if it is completely undocumented. Docs should evolve with the product, not be hastily made months or years after it is finished.
3 Likes
THIS! A twitter thread should not be the best source of information for ECS when you’re touting it everywhere as the best new feature and are actively rewriting parts of your own engine to use it!
To be fair, I had a long conversation with the new head of documentation at Unite Copenhagen last year. He said they are working on it, but are dealing with a massive group of developers with different workflows and multiple legacy systems for documenting in that all need unifying. So please give this team more love and more priority!
Agreed, the docs team are trying hard and doing a good job. Effort or skill is not to blame, they are simply under-resourced.
I guess in old unity where everything followed the old way of doing things it was okay to be this lazy as the community had the knowledge to fill in the gaps. But now with everything being new (DOTS, SRP, Packages etc) its becoming super apparent how lacking the docs are, and I think that old mentality has to change.
Docs should be the number 1 priority team for hiring and growing for unity for the next year, it would do amazing things both in the short term (customer satisfaction and some backtracking of the confusion+rage being felt by many) and in the long term (ensuring unity doesnt get back into this situation as it continues to grow with the ever increasing rate of aquistions and new features piling in).
OR even better if you cant afford to grow docs team at the rate needed: allow users to make edits / suggestions to the docs. We literally have been shouting about specific docs for ages and have no way to change or update them ourselves. Turn it into a wiki and have the docs team manage the submissions, thereby increasing the amount of knowledable users who can provide info and allowing docs team breathing room to focus on what goes in and what doesnt, managing docs etc instead of playing this insane game of never-ending catchup.
3 Likes