We are excited to announce that we recently added the Engine API reference content to the open-source documentation repository! If you’re reading the Engine API documentation today, you should now see an Edit button on each page that takes you to the appropriate YAML file. YAML has stricter formatting requirements than Markdown, but we have tests in place to help identify any problems and get your contributions incorporated.
Adding the Engine API content has been a frequent request from creators, so we’re incredibly excited to have it available. We’re hoping to get code samples open-sourced in the coming months. Still, this release goes a long way towards fulfilling our vision of a more open, more collaborative, more community-focused set of documentation.
We’ve merged a couple hundred pull requests already—some of them truly extraordinary—and can’t wait to keep working with everyone on making the documentation even better. We hope to see you all on GitHub!
Contributing
If you’ve used GitHub before, the process should feel very familiar. If you’re new to GitHub, we’ve documented how to contribute in the README.md.
Licenses
The repository uses two open-source licenses:
Prose is available under the Creative Commons Attribution 4.0 International License, so you can remix and adapt it to your work as long as you provide proper attribution.
Code samples are available under the MIT License so you can freely incorporate them into your experiences.
What’s next?
Next year, we’re looking forward to adding new ways for creators to share their knowledge and passion with the community. Some amazing content just doesn’t have a home within the documentation, so we want to build a better place to showcase tutorials, guides, technical deep dives—anything, really—in a more casual, more immediate way. More information on that in the coming months.
This is great! Hopefully a lot of errors or pages with little or not any information get the love they deserve for the people who need to read up on those things!!
Happy for this one! I did a bit of contributing in the past to some of the guides content, but engine API documentation is the area that I was most waiting for to become open source so I could contribute. There is a lot more work to be done on the engine API documentation than guides content, I feel.
I think I’ll make some issues I’ve had with this (not much, contributing has been fun)
Is there a common design kit that can be used for making diagrams, my bit32 contribution uses something thrown together in Studio, but this could probably be more useful in the long run
A Guilded server could be useful for people who contribute a lot of stuff, so we have quicker feedback than having to go through PRs (looks at katrist)
Contributing has been an amazing experience and, if you’ve got knowledge to share, I encourage you to write something up! It could help hundreds or even thousands of people in the future. Seeing that “Merged” notification is great.
As one of the former volunteer editors of wiki.roblox.com I’m thrilled to see community contributions restored. I’ve waited over 5 years to finally see this come to fruition and I’m excited to start contributing to all the niche engine bits I can find.
It would be nice to have documentation on the structure of the YAML files so that I know what each field does, what’s required, what’s optional in which context, etc. Descriptions appear to be templates, so it would help to know what features are available there as well.
I’d like to confirm, are #feature-requests:documentation-features and #bug-reports:documentation-issues the best places to request for changes that cannot be made through pull requests? For example, I’d like to suggest that the type_a and type_b fields of the math_operations section be included in the section’s header. Or, I’d like to report about how the color column on the BrickColor page doesn’t render properly. I can’t make pull requests for these, because they involve whatever tooling is used to render the documentation data rather than the data itself.
I made a report about the BrickColor issue a few weeks ago. Webpage rendering definitely needs documentation so we can know whether or not certain HTML patterns are supported. There’s no way to test it or preview what it will look like.
Absolutely, totally fair. The proper “this is exactly how it’ll look on the website” preview isn’t practical at this time, but I’ll get something into README.md or STYLE.md with guidelines around the various fields.
Huge W for the platform, I look forward to seeing more examples added to a lot of sections in the API that currently have none, I just hope there is rigorous error/fact checking before anything is approved to be merged. Because if a person needs to look up a certain subject in the documentation, they probably don’t know that section well enough to tell if the information is correct or not.
