This new update allows people to edit it on GitHub, once approved it will get published onto the official site
Yep, that’s planned for the future.
Really happy to see this! Documentation is super important to me. I’ve submitted a number of requests in the past and had to wait for a long time for them to get triaged and added (sometimes even raw code samples I’ve submitted have been used in the Creator Docs), but now I can contribute directly! I’m very excited to contribute, though my primary area is Engine API so I’ll be waiting for those to be available.
If you just want to view the Creator Documentations, simply go to Documentation - Roblox Creator Hub. This simply allows the community to make modifications and improvements to the documentations without having to wait for Roblox to acknowledge them and make the modifications. Ultimately Roblox still controls the flow, they can choose to accept or deny the modifications (or “Pull Requests”), so unless an accident happens, malicious attempts at modifying the documentation won’t just appear like an edit on a Wikipedia page or whatnot would.
Yeah, check my edit though. I had a misconception as to what was going on.
That’s disappointing, though I’m not terribly surprised. As a followup then, would it be something that Roblox would be open to hosting in the future?
I understand it isn’t the intent, but every one in a while we have people coming into open source spaces asking about things like Roblox’s mesh format, and it’d be good to be able to direct them towards an official Roblox site, even if it was community authored.
Also, how low-level will be allowed to make documentation? Internal details like FFlags aren’t clearly documented anywhere despite being important for more experienced developers to know about for various reasons, ranging from bug reporting to testing. Would an explanation of them be welcomed or is that too internal-oriented? What about things like security contexts for scripts, which are poorly documented despite appearing in a few user-facing errors?
Is there really any point in that? If a pull request is bad, it’s bad. If the AI pull request is good, it just is. I’m sure Roblox is prepared for a bunch of junk pull requests and issues, since it’s Roblox.
Swag I’ve been really liking the direction you guys have been going with the major documentation revamp over the last few years, this is a fantastic step forward.
Amazing, now even the docs are UGC
Good update, open sourcing FTW!
Thank you, this is a great change for everyone. No longer will we have to file documentation bug reports for simple mistakes, and be able to submit our own suggestions and contribute. Almost like how the old developer wiki was, in a more structured form, and that’s fantastic.
Would love to contribute to this by adding translations to Spanish! Hope support for that arrives sometime soon.
Just made my first PR! Quite a lot of spelling/grammatical errors, will do my part to fix as many as I can spot!
Big W from Roblox here, really glad to see their support towards the open source community especially recently and this will definitely go a long way in improving developer experience
Any and all contributions to open source resources are good things to have. This is a shocking post that I wouldn’t expect from ROBLOX, but it’s a pleasant thing to see regardless.
Great to see Roblox heading towards more transparency, especially in these last few updates.
I have a feeling the documents will get the attention they’ve been needing!
Hey Dekkonot, I think we’re at least somewhat on the same page here. The goal is indeed to find a way for community content to live closer to the documentation while still having a clear delineation between the two, “official” vs. “community-contributed, but probably great.” That separation presents some challenges around how to make sure the best content bubbles to the top, search, and the authoring experience, so we’re trying to talk in terms of goals rather than specific outcomes.
For pull requests, I can imagine situations in which we don’t want to make guarantees around something and therefore don’t accept documentation that describes its behavior or makeup. Likewise, we might not want content around something deprecated or soon-to-be deprecated, recommendations that ignore what we consider best practices, etc. I’m not close enough to the situations you’ve described to pass judgment on them without seeing the proposed content, but my suspicion is that we’d be hesitant to add that information without a lot and back-and-forth.
Out of curiosity, how long would it take for these changes to go live on the official Documentation after they’re accepted & merged? Not too familiar with the whole Github PR process so my apologies if I’m missing something here.
This is great news. I’ve stumbled upon many articles that were outdates or had some typos/errors in code that were easily corrected. I will look for those and make an effort to help clarify.
Hey roman, most PRs that get merged on GitHub should go live within a few business days.