When I go through a page of the documentation, I usually find one or two typos, however, it’d be quite cumbersome to come to the forums each time, and report each issue, so I just scroll over it. Is there a plan of proposing documentation changes on-the-fly by the community, or at least a page-specific feedback button, so that these issues can be reported quickly, just right there?
(Just for reference, one example is in the Smart Pointer Library now, “When a Unique Pointer is goes out of scope”).
Thanks for your feedback! Yes, we’re planning to implement something along the lines of what you suggest. Unfortunately, we need to work through some tool changes before getting to anything useful or cool. I know it’s not rocket science, but transitioning from legacy tools can be a tough road to hoe. Ideally, we’ll get to both page-level feedback and direct editing by trusted community members … well, that’s my optimistic opinion on this Friday afternoon. I’m keeping my fingers crossed!
I want to bump this topic because I’m interested in working on the documentation myself and I’m wonder if the thought of using a Git repository would be possible. The implementation of the system itself shouldn’t be hard – You all have control over what gets pulled into the official repository that gets displayed online, and it allows the community to help you. I’m currently going through the FPS Tutorial (Programming Guides > First Person Shooter Tutorial) and there’s small things that have changed that make me worry about how old the documentation is. The creation of a project with Basic Code no longer creates “FPSProjectGameMode.cpp”, it’s “FPSProjectGameModeBase.cpp” now. As a developer, I’m looking at this and wondering if the name change means there is an entire restructuring that has happened that makes this tutorial out of date. And even if everything works exactly the same, acknowledging the changes (through proper renaming) is a simple way to prevent doubt in the quality of the system.
I’d like to convert the tutorials into Markdown as a way of giving Epic a data file that they could utilize, but also as a way to allow community revisions. In either case, I’m still going to be going through the tutorial, so I will be marking the changes. I can make a post about those changes, but honestly just being able to send you a pull request would be so much easier.
@cthecheese Thanks for the feedback! You make some good points, and we recognize that several tutorials are a ‘bit’ stale. We are working on a plan to refresh some of that content.
Hopefully, we’ll get to the point where we can enable folks like you to efficiently help update content that you’re interested in. Unfortunately, GitHub isn’t an option right now, as we’re using a customized version of Markdown that isn’t GitHub friendly. However, this may change in the future. For now, we’d be happy to take any feedback here in the forum.
Jim is totally correct that the source files we use for docs are in a customized Markdown that doesn’t play nicely with GitHub’s built-in markdown support.
But if you’re really willing, you can find them in the UE4 GitHub repo and make PRs against them just like any other UE4 source code file. You’ll find them under Engine/Documentation/Source. There are two snags:
one is that we don’t have a really good guide for external contributors for working in our custom format, what metadata to apply to the files, how to structure custom object types, etc. But if you’re mostly updating existing stuff, that might not be a big issue.
the other one is that the branch that we do most of our doc work in doesn’t get published to GitHub. So what you’ll see on GitHub is unlikely to be fully up to date with what you see on the public docs site. However, that’s something that we can adjust when we apply your PR. And anyway, if you’re looking at older tutorials, it’s likely that they haven’t changed much recently. I believe the “master” branch on GH should be the one that has the most recent copy-up from our docs branch.
thank you for volunteering your time to help improve the docs!
Creating new branch and PR for single typos still sounds like a bit overkill, but better than nothing, thanks for the info, will use this method in the future!
On the master branch the most recent update was 2 months ago, and most of the updates are from 4 months ago… is that right? I thought they are updated more frequently (or the changes of the last 4 months are not propagated to GitHub yet?).
Awesome! It’s helpful that y’all use Markdown. If you don’t mind me asking, do you guys have information about how you are viewing your markdown and managing the customization of it? I have a bigger project that I’m working on which will be using a modified version of Markdown as well. It seems like MD might continue to impact the internet for quite a while so I’m wondering what we’re all going to do about handling the various ways MD can be customized.
Sorry if this got a little off topic, my point is that I’d love to help as much as I can, so while I’m crawling through the documentation I hope I’ll come out with something y’all can find useful.
