Get involved

File a bug report

The simplest way to participate is to file bug reports at the bug tracker.

If you find any problems with the D language, please file a bug report. Problems that are not filed will not get fixed, because the developers wouldn't know the problem existed. If you're not sure if something is a bug or by design, please ask in the forums (see below).

Note that compiler internal errors (crashes, assertion failures, etc.) should always be filed. No matter how wrong your input is, the compiler should give an appropriate error message and abort compilation; it should never crash. Such crashes are always bugs.

Discuss in the forums

You can also join in the discussion at the D forums, which can be accessed via the web interface, the mailing list interface, or the NNTP server.

The main D forum is for general discussion on the D language, feature requests and discussions, etc.. Newcomers should start with the D.learn forum, which is intended for learners to ask more basic questions about programming in D.

Alpha-test the development version of D

If you're feeling adventurous, or crave the bleeding-edge features of D, you may want to learn how to build git master.

Contribute to the source code and documentation

The source code for the D website, compiler, runtime library, and Phobos (the standard library), are all available on GitHub. Contributions to the source code are done via pull requests. Please note that contributions to DMD source code will only be accepted if the author agrees to have the copyright of the code assigned to Digital Mars.

To find something to work on, you can search the bug list for issues that you can help fix, or view the most-voted-for issue list.

Review pull requests

The sheer amount of code being written for the D compiler, standard library and related project is often too great for the core developers to keep up. Even if you're not a "hardcore" D developer you can help lessen this load by reviewing the changes in pull requests at GitHub for DMD, Phobos, DRuntime and the D website.

Various "easy" things to look for:

• Missing or hard to understand comments
• Unintuitive documentation
• Unchecked edge cases in the code (missing assert, enforce, template constraints)
• Inconsistencies with the D style
• API inconvenient for use cases the author didn't think of
• Missing/inadequate unittests
• Poor code coverage (check with `dmd -cov -unittest -main std/filename.d)

Also, it is often helpful to review old pull requests (e.g. sort by least recently updated on GitHub). Commenting on an old pull request that seems OK but was for some reason forgotten may bring some attention to it. If you think a pull request is OK to be merged, write "LGTM" (looks good to merge) in your comment.

If a pull you're interested in has been languishing in the queue for a long time with no attention, commenting "ping" may help prod things along. Especially if the author needs to rebase the pull due to a merge conflict, autotester failure, or other such maintenance problem.

Citing Andrei Alexandrescu:

"If you see [Pull request] you care about, review it even if you don't have rights yet. A simple message such as "I reviewed this and LGTM, any holdup?" would be sufficient to attract attention."

See also

• Helping D Progress
• Bugzilla
• Pull Requests, Review process, Phobos style guidelines
• Building DMD
• DMD Source Guide
• Unit Testing Phobos modules
• Discussion and Ideas
• Release Process
• Official Documentation Comments
• History Of Development Model For D
• Phobos
• Tango
• Libraries
• Git Commit Tester
• Using Git on Windows
• Container Ideas