I have professors and instructors I’ve chatted with that are willing to provide materials, but, unfortunately, that won’t immediately enable us to pump out more documentation over a short amount of time, I think. Depending on the person submitting the material there are probably some legal considerations that need to happen for taking someone else’s work and bringing it into our documentation, we’d need to work with a developer here at Epic to verify the information. This part takes the most time because everyone has their own priority tasks that they are working on, so sometimes scheduling can slow that process down, unfortunately. Once our dev has approved and effectively signed off on the content, we are able to fit it into our documentation’s styles and standards so that everything fits well together.
Essentially, I see this as being helpful in getting us some form of pre-documentation to start from (which the dev typically provides, like with new feature and sometimes we write the pre-doc ourselves during a research phase with guidance from our devs) but that doesn’t immediately negate the other steps in our process just because we were given help on one step in that process. This is why the Wiki was a good place to let the community add new tutorials and information. The community could generate and post content faster than it could go through our process as official documentation.
That probably doesn’t help with the frustration of not getting the information you want right way from an official source. However, as a point to helping us get clear actionable requests, It really helps when we are given the following:
- For Requests, what’s the topic and why is it important? If it’s a how-to or tutorial style request, what’s the goal of the tutorial? Does the request require additional information to be documented for this to make sense? If no, what other resources need to be linked to understand or tie into what is being shown.
- For other documentation that’s overview or reference style, what’s the feature to be documented, what is missing that isn’t already covered, is it just out of date, etc.
We get a lot of blanket topics that are just like the title of this thread. Not that this title alone is bad, but without specifics of what is wrong, out of date, missing information, etc, we can’t follow up with actionable things to do to make it better (See an example of an actionable request above with Jim’s post). Even if we do set up actionable steps to resolve it, we have to assign it a priority and sometimes our priorities don’t line up with what the community or person making the request would like. Unfortunately, everything can’t be a priority 1 or even 2 simply due to the time it takes to research, understand, talk with devs, write, get approval signoff, do an editorial pass. and finally publish content. We try our damnedest to make it all happen, though!
I’ll end on a positive note because I’m super proud of our team and the fact that we do this now. So if you remember even just a year ago (probably 4.17 or 4.16 and prior, on release of a new engine version, we didn’t always have a lot of day 1 documentation for all the cool new features. Compare that to 4.21 where we are now consistently releasing 80% of those new / updated feature documentation on day 1! In between releases, we try to get to our backlog and focus on all these requests and other docs that we’ve wanted to do.
With all that in mind, if anyone is interested in some form of collaboration, you can always reach out to us and start a conversation. It’s not something that we’ll go about soliciting different universities or community members, I think, but we’re open to at least exploring possibilities.
