VBA-Docs is the source that Microsoft Learn renders the VBA reference from

The contribution path is a pull request with a tag, and issues are closed

The state of the project is stated in the first paragraph, and it is the thing any contributor needs to know before anything else. The repository description says it is no longer accepting new issues, and that to request changes you create a branch, make changes, create a PR and tag @OfficeDev/opcontent. The project page says the same thing in longer form: there are no resources to respond to new issues, and pull requests are welcomed that include documentation fixes, code samples or improved comments, with the instruction to create a branch, make the changes and open a PR to merge the change to master. The tag requirement is the unusual part. Merging is not automatic on approval, it requires the @OfficeDev/opcontent tag, which is a content review role rather than a code review role. So the queue for a documentation change is a human reading your prose, which is the right queue for this kind of repository and also the reason a large change will take longer than a code fix would.

Questions about VBA code belong on Microsoft Q&A, not in the issue tracker

The project page is explicit that asking questions is a different activity from improving the documentation, and it routes that traffic elsewhere. There is a new forum on Microsoft Q&A for VBA questions, and to ask the developer community questions about your VBA code you are pointed at the Microsoft Q&A office-vba-dev forum. The repository also points people with questions about contributing to the documentation at a `contributing.md` file in the root, and the published articles for the repository are available at the Office VBA Reference on Microsoft Learn. The distinction the project draws is sensible. An issue asking why a method throws a particular error is a question about the VBA language and its runtime, and answering it in the documentation repository would mix two very different kinds of content, one of which has a clear owner outside this repository. A pull request that corrects a description of a parameter is unambiguously a documentation change, and that is what this repository is set up to receive.

The directory layout is the VBA object model, one directory per application

The repository root is organised around the shape of the VBA API itself, and the directory names are the fastest way to understand what lives where. There are top-level directories for `access/`, `excel/`, `outlook/`, `powerpoint/`, `publisher/`, `visio/` and `word/`, each holding the reference pages for that application's object model, plus `api/` and `articles/` for the general API articles, `F1/` for help topics, `Language/` for the language reference, `Library-Reference/` for the type library pages and `Office-Mac/` for the Mac differences. There are also support directories, with `images/` for illustrations, `includes/` for partials included by other pages, `breadcrumb/` for navigation metadata and `project/` for the Open Publishing project configuration. A contributor who knows the application they are documenting can go straight to the right folder, and the per-application split means a change to Excel's object model cannot accidentally touch Word's, which is the kind of separation that matters in a repository this size.

The Open Publishing config and docfx.json are how a markdown file becomes a page

The publishing pipeline is described by its configuration files, and they are visible in the root. There is `.openpublishing.publish.config.json` and `.openpublishing.redirection.json`, the latter holding the mapping used when a URL changes so that old links keep working, and there is a `docfx.json` which is the DocFX configuration for the documentation set. The presence of a redirection file is the detail worth noticing. Documentation sites live for years and their URLs get renamed, and without a redirection map every rename silently breaks inbound links from other articles and from search engines. The `includes/` directory works the same way in the other direction, holding shared partials so that a standard block of text, a note about a cross-platform difference or a common table, is written once and included in every page that needs it. That is a small piece of infrastructure that is invisible to a reader and that determines whether the corpus stays consistent as it grows.

Licensing is split between the content and the code samples

Two licence files sit at the root, and the split between them is the interesting part. There is a `LICENSE` file, and the repository is licensed under CC-BY-4.0, which is the right choice for reference documentation that other people want to quote, translate and reuse. There is a separate `LICENSE-CODE` file, which is the standard Microsoft pattern for a documentation repository: the prose is content and the code samples are code, and they are licensed differently so that a sample can be pasted into a project without dragging content terms along with it. A `ThirdPartyNotices` file records the third party components involved. For a contributor this is a practical matter rather than a legal one, because a sample that is a fragment of somebody's real project may carry obligations that do not belong in a documentation repository, and knowing which file covers which kind of contribution is the first question to ask before opening a pull request that adds a code sample.

The security and conduct files are part of the same repository

The root also carries a `SECURITY.md` and the project has adopted the Microsoft Open Source Code of Conduct, with the Code of Conduct FAQ and a contact address given for questions or comments. Placing the security policy inside the documentation repository is a convention in Microsoft's documentation projects rather than a peculiarity of this one, and it works because the repository is where a reader lands when something looks wrong with a published page. A wrong parameter name is not a vulnerability, but a wrong security-relevant instruction can be, and a policy file next to the content tells a reader where to say so. The governance documents also define who can act on a report and how, which matters for a project with a content-review role, since the person who merges a page is not the person who triages a report.

The Microsoft 365 Developer Program is the other path the readme points to

There is a third resource the project page promotes, and it is aimed at developers rather than documentation contributors. Join the Microsoft 365 Developer Program to get resources and information to help you build solutions for the Microsoft 365 platform, including recommendations tailored to your areas of interest. The project page also notes that you might qualify for a free developer subscription that is renewable for 90 days and comes configured with sample data, with the details in the linked FAQ under who qualifies for a Microsoft 365 E5 developer subscription. That is a different proposition from editing the reference, and it is worth separating the two, because a developer building against the VBA reference and a developer improving it are using the platform in opposite directions. The project page is not long, and it covers three audiences, which is why it is worth reading in full before deciding which of the three you belong to.

Where a documentation source repository is the wrong place to work

Two limits are worth naming. The first is that this repository cannot answer a question, by its own statement, and the issue tracker is closed. That means a developer who arrives expecting help gets none, and the documentation sits in the middle of a support flow that this project deliberately does not handle. The second is the publishing model. The content is only the official reference because a pipeline takes it from this repository to Microsoft Learn, and that pipeline, the `docfx.json` and the Open Publishing configuration, is a build that Microsoft runs. A contributor can change a page and open a pull request, but cannot publish, cannot see the result locally without reproducing the pipeline, and cannot restructure the site. The alternative to weigh against is the set of per-application and community documentation sites, which are editable by anyone and therefore answer questions faster, at the cost of being unofficial and often going stale. The difference in approach is review versus reach. This route produces the reference that every other source quotes, and it is slow and gated, and for a question about your own code neither of these repositories is the right destination anyway.

Editorial conclusion

VBA-Docs is the place to go if you want a change to the official Office VBA reference to appear, because the published articles come from this repository and the Open Publishing pipeline takes the markdown from here to the documentation site. It is a poor fit if you want a place to ask a VBA question, since the repository states that there are no resources to respond to new issues and points at the Microsoft Q&A office-vba-dev forum for that, and a poor fit if you want to file a bug against the VBA runtime itself, which is a different repository. Before you open a pull request, read `contributing.md`, and note that a pull request must be tagged @OfficeDev/opcontent to be merged, that the last push to the repository was on 2026-10-16, and that the documentation is published under CC-BY-4.0.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-4.0
3. MicrosoftDocs/VBA-Docs on GitHub
4. Project website
5. README