Difference between revisions of "Get involved"

From D Wiki
Jump to: navigation, search
(See also)
(See also: add links to contribution guides)
(45 intermediate revisions by 17 users not shown)
Line 1: Line 1:
 
== File a bug report ==
 
== File a bug report ==
  
The simplest way to participate is to file bug reports at the [http://d.puremagic.com/issues/enter_bug.cgi?product=D bug tracker]. You can also [http://d.puremagic.com/issues/query.cgi search] the bug list for issues that you can help fix.
+
The simplest way to participate is to [https://issues.dlang.org/enter_bug.cgi?product=D file bug reports] at the [http://issues.dlang.org/ 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).
 +
 
 +
Ideally, bug reports should be accompanied by a [http://sscce.org/ small, self-contained example] which demonstrates the problem, and makes it easy to reproduce it. If you find it difficult to manually extract a small example from your source code, [https://github.com/CyberShadow/DustMite DustMite] can help with automatically extracting one. See [https://github.com/CyberShadow/DustMite/wiki the project wiki] for more information.
 +
 
 +
If a piece of code worked in an older version of a compiler but no longer works in a newer version, please file a regression (by setting the "Severity" field to "Regression"). Regression bugs are examined before all others. You can use [https://github.com/CyberShadow/Digger Digger] to find the pull request that introduced the change which broke your code. [https://github.com/CyberShadow/DustMite/wiki/Reducing-a-regression-between-two-D-versions DustMite can also be helpful] in creating a minimal example.
 +
 
 +
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 ==
 
== Discuss in the forums ==
  
You can also join in the discussion at the D forums, which can be accessed via the [http://forum.dlang.org/ web interface], the [http://lists.puremagic.com/mailman/listinfo mailing list interface], or the [nntp://news.digitalmars.com NNTP server].
+
You can also join in the discussion at the [http://forum.dlang.org/ D forums], which can be accessed via the [http://forum.dlang.org/ web interface], the [http://lists.puremagic.com/mailman/listinfo mailing list interface], or the [news://news.digitalmars.com 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.
+
The main D forum is for general discussion on the D language, feature requests and discussions, etc.. Newcomers should start with the [http://forum.dlang.org/group/digitalmars.D.learn D.learn] forum, which is intended for learners to ask more basic questions about programming in D.
  
== Contributing to the source code ==
+
== Alpha-test the development version of D ==
  
The source code for the D compiler, D runtime library, and Phobos, the standard library, are all available at [https://github.com/D-Programming-Language GitHub].
+
If you're feeling adventurous, or crave the bleeding-edge features of D, you may want to learn [[Building DMD|how to build git master]].
  
To contribute:
+
== Contribute to the source code  ==
# Fork the project you wish to contribute to;
+
 
# Clone your fork of the project locally;
+
=== Fix Bugzilla issues ===
# Create a topic branch and make your changes there (generally, you should not make changes directly to the master branch). Test your changes, make sure it doesn't break anything, etc..
+
 
# Push your new branch to your fork on GitHub.
+
The source code for the D website, compiler, runtime library, and Phobos (the standard library), are all available on [https://github.com/dlang GitHub]. Contributions to the source code are done via [[Pull Requests|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 the D Language Foundation.
# Navigate to that branch on GitHub, and click on "Pull request" to submit a pull request.
+
 
# The D maintainers will review the pull request and merge it as appropriate, or, if they have some comments or feedback, will provide feedback on the pull request page. You can then update your changes according to their input, and push your new changes to GitHub. The new changes will automatically be put into your pull request.
+
To find something to work on, you can [http://d.puremagic.com/issues/query.cgi search] the bug list for issues that you can help fix, or on one [https://issues.dlang.org/buglist.cgi?columnlist=votes%2Cbug_severity%2Cpriority%2Cop_sys%2Cassigned_to_realname%2Cbug_status%2Cshort_desc&field0-0-0=votes&order=votes%20DESC&resolution=--- that has been voted for a lot] or [https://issues.dlang.org/buglist.cgi?keywords=preapproved&resolution=--- preapproved].
 +
 
 +
There is a pre-filtered list of [https://issues.dlang.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=VERIFIED&component=dlang.org&component=dmd&component=druntime&component=installer&component=phobos&component=tools&component=visuald&keywords=trivial%2C%20&keywords_type=allwords&list_id=213785&product=D&query_format=advanced&resolution=---&version=D2 trivial] issues which might be good starting points for beginners.
 +
Help to maintain this pre-filtered list of trivial issues is welcome as well.
 +
 
 +
=== Simple tasks for Phobos ===
 +
 
 +
The [[Vision/2016H2|high-level vision document]] lists many projects that one can start to change the status quo.
 +
However, as most of them might require a lot of time or expertise, here are a couple of ideas from the high-level vision that have been semi-automated and could be a good start to get involved:
 +
 
 +
* Improve code coverage [https://codecov.io/gh/dlang/phobos CodeCov report]
 +
* Make sure every function in Phobos has an example [https://github.com/wilzbach/style-checkers/blob/master/has_public_example.d script],[https://github.com/dlang/phobos/pull/4973 example]
 +
* Make sure every function in Phobos has Params: and Returns: [https://github.com/Hackerpilot/Dscanner/pull/390 script]
 +
* Review `@safe` usage in Phobos (or `@system` -> `@safe`) [http://dlang.org/safed.html guide], [https://github.com/dlang/phobos/pull/4690 example]
 +
* Enable more Dscanner plugins/automation for Phobos [https://github.com/dlang/phobos/blob/master/.dscanner.ini config]
 +
 
 +
=== Contribute to the documentation and dlang.org ===
 +
 
 +
To contribute to the documentation, start by reading [https://github.com/dlang/dlang.org/blob/master/CONTRIBUTING.md How to Fork and Build dlang.org]. Additional information on improving the documentation can be found in [http://www.digitalmars.com/d/archives/digitalmars/D/Phobos_Documentation_-_call_to_action_258777.html this thread] started by Walter Bright.
 +
 
 +
== 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 [https://github.com/dlang/dmd/pulls DMD], [https://github.com/dlang/phobos/pulls Phobos], [https://github.com/dlang/druntime/pulls DRuntime] and the [https://github.com/dlang/dlang.org/pulls 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 [http://dlang.org/dstyle.html D style]
 +
* API inconvenient for use cases the author didn't think of
 +
* Missing/inadequate unittests
 +
* Unittests should be annotated @safe. If @safe is not possible, it [https://forum.dlang.org/post/nkn25t$btk$1@digitalmars.com shall] be @system.
 +
* Poor code coverage (install the [https://github.com/codecov/browser-extension CodeCov browser extension] or check `dmd -cov -unittest -main std/filename.d`)
 +
* More/better code examples in documentation. Look at answers in [http://forum.dlang.org/group/digitalmars.D.learn D.learn] and [http://stackoverflow.com/questions/tagged/d stack overflow] for ideas.
 +
* Missing overflow checks when calculating storage sizes
 +
 
 +
Please avoid:
 +
 
 +
* Drifting off topic, i.e. anything other than the PR being reviewed.
 +
 
 +
To run the unittests of a single file on posix:
 +
<syntaxhighlight lang=bash>
 +
make -f posix.mak DMD=../dmd/src/dmd std/*.test
 +
</syntaxhighlight>
 +
Adding "-cov" to the "%.test" target inside posix.mak will generate a coverage analysis.
 +
 
 +
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."
 +
 
 +
== Google Summer of Code ideas ==
 +
 
 +
Some of the past ideas may still be interesting:
 +
 
 +
* [https://wiki.dlang.org/GSOC_2016_Ideas 2016]
 +
* [https://wiki.dlang.org/GSOC_2015_Ideas 2015]
 +
* [https://wiki.dlang.org/GSOC_2014_Ideas 2014]
 +
* [https://wiki.dlang.org/GSOC_2013_Ideas 2013]
 +
* [https://www.prowiki.org/wiki4d/wiki.cgi?GSOC_2012_Ideas 2012]
 +
* [https://www.prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas 2011]
 +
 
 +
== Other D-related projects ==
 +
 
 +
* [https://github.com/dlang-tour Help with a translation of the Dlang Tour to your language]
 +
* [http://wiki.dlang.org/LDC_project_ideas LDC project ideas]
 +
* [http://wiki.dlang.org/GDC/ProjectIdeas GDC project ideas]
 +
* [http://stackoverflow.com/documentation/d Extend the Stackoverflow D documentation]
 +
 
 +
== How to better promote your own D projects ==
 +
 
 +
<blockquote>
 +
I hate the movie "Field of Dreams" where they push the idiotic idea of "Build it and they will come." No, they won't. There's a blizzard of stuff competing for their attention out there, why should they invest the time looking at your stuff? You need to tell them why!
 +
 
 +
Here's the frustrating typical pattern I've seen here for years:
 +
 
 +
# spend hundreds if not thousands of hours developing something really cool
 +
# spend 2 minutes posting a link to the repository on D.announce
 +
# someone posts it to reddit. Ignore it
 +
# get frustrated that nobody looks at it
 +
# get bitter and quit
 +
 
 +
Here's the pattern that works a lot better:
 +
 
 +
# spend hundreds if not thousands of hours developing something really cool
 +
# spend 10 minutes writing the announcement to D.announce. Be sure to include:
 +
#: who, what, where, when, why, and how
 +
# someone posts it to reddit
 +
# post the who, what, where, when, why and how on reddit AS SOON AS POSSIBLE after the reddit link appears. Stuff on reddit has a VERY SHORT shelf life. If it doesn't get action within a couple hours, it fades into oblivion. Identify yourself as the author, say AMA. The first one to post a comment tends to spark and set the tone for the discussion.
 +
# check back on reddit once an hour or so for the next day, answer questions
 +
# *****
 +
# profit!
 +
 
 +
Walter Bright
 +
</blockquote>
 +
 
 +
== Contribute to this wiki ==
 +
 
 +
* [http://wiki.dlang.org/Coming_From D as a second language] sections should be completed
 +
* add more examples of how to shift idiom to speak fluent D
 +
* flesh out the Python page
 +
* review empty sections
 +
* update C and C++ transition guides
 +
 
 +
<blockquote>
 +
One note about Walter's older C/C++ transition articles. They have good information on transition technicalities (e.g. "how do I do this thing in D that I used to do in C++?") but not a lot about the changes in coding style - making object copying not arbitrarily expensive, choosing struct vs. class, preferring pipelines and lazy to eager computation, etc. From what I see some folks come from C++, write their first D program in a stilted C++ idiom, and are left with the impression that the work is not worth the trouble.
 +
 
 +
Andrei
 +
</blockquote>
  
 
== See also ==
 
== See also ==
  
* [[Helping D Progress]]
+
* [[Starting as a Contributor]]
* [[Pull Requests]], [[Submitting Patches]]
+
* [[Contributing to Phobos]]
* [[Contributing To The D Compiler]]
+
* [[Bugzilla]]
* [[Unit Testing Phobos modules]]
+
* [[Pull Requests]], [[Review process]], [http://dlang.org/dstyle.html Phobos style guidelines]
* [[Discussion and Ideas]]
+
* [[Building DMD]], [[Build DMD for Android]]
* [[Official Documentation Comments]]
+
* [[DMD Source Guide]]
 +
* [[Release Process]]
 
* [[History Of Development Model For D]]
 
* [[History Of Development Model For D]]
 
* [[Phobos]]
 
* [[Phobos]]
* [[Tango]]
 
* [[Libraries]]
 
 
* [[Git Commit Tester]]
 
* [[Git Commit Tester]]
 
* [[Using Git on Windows]]
 
* [[Using Git on Windows]]
 +
* [[Container Ideas]]
 +
 +
[[Category: Contribution Guidelines]]

Revision as of 15:11, 28 February 2017

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).

Ideally, bug reports should be accompanied by a small, self-contained example which demonstrates the problem, and makes it easy to reproduce it. If you find it difficult to manually extract a small example from your source code, DustMite can help with automatically extracting one. See the project wiki for more information.

If a piece of code worked in an older version of a compiler but no longer works in a newer version, please file a regression (by setting the "Severity" field to "Regression"). Regression bugs are examined before all others. You can use Digger to find the pull request that introduced the change which broke your code. DustMite can also be helpful in creating a minimal example.

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

Fix Bugzilla issues

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 the D Language Foundation.

To find something to work on, you can search the bug list for issues that you can help fix, or on one that has been voted for a lot or preapproved.

There is a pre-filtered list of trivial issues which might be good starting points for beginners. Help to maintain this pre-filtered list of trivial issues is welcome as well.

Simple tasks for Phobos

The high-level vision document lists many projects that one can start to change the status quo. However, as most of them might require a lot of time or expertise, here are a couple of ideas from the high-level vision that have been semi-automated and could be a good start to get involved:

  • Improve code coverage CodeCov report
  • Make sure every function in Phobos has an example script,example
  • Make sure every function in Phobos has Params: and Returns: script
  • Review `@safe` usage in Phobos (or `@system` -> `@safe`) guide, example
  • Enable more Dscanner plugins/automation for Phobos config

Contribute to the documentation and dlang.org

To contribute to the documentation, start by reading How to Fork and Build dlang.org. Additional information on improving the documentation can be found in this thread started by Walter Bright.

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
  • Unittests should be annotated @safe. If @safe is not possible, it shall be @system.
  • Poor code coverage (install the CodeCov browser extension or check `dmd -cov -unittest -main std/filename.d`)
  • More/better code examples in documentation. Look at answers in D.learn and stack overflow for ideas.
  • Missing overflow checks when calculating storage sizes

Please avoid:

  • Drifting off topic, i.e. anything other than the PR being reviewed.

To run the unittests of a single file on posix:

make -f posix.mak DMD=../dmd/src/dmd std/*.test

Adding "-cov" to the "%.test" target inside posix.mak will generate a coverage analysis.

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."

Google Summer of Code ideas

Some of the past ideas may still be interesting:

Other D-related projects

How to better promote your own D projects

I hate the movie "Field of Dreams" where they push the idiotic idea of "Build it and they will come." No, they won't. There's a blizzard of stuff competing for their attention out there, why should they invest the time looking at your stuff? You need to tell them why!

Here's the frustrating typical pattern I've seen here for years:

  1. spend hundreds if not thousands of hours developing something really cool
  2. spend 2 minutes posting a link to the repository on D.announce
  3. someone posts it to reddit. Ignore it
  4. get frustrated that nobody looks at it
  5. get bitter and quit

Here's the pattern that works a lot better:

  1. spend hundreds if not thousands of hours developing something really cool
  2. spend 10 minutes writing the announcement to D.announce. Be sure to include:
    who, what, where, when, why, and how
  3. someone posts it to reddit
  4. post the who, what, where, when, why and how on reddit AS SOON AS POSSIBLE after the reddit link appears. Stuff on reddit has a VERY SHORT shelf life. If it doesn't get action within a couple hours, it fades into oblivion. Identify yourself as the author, say AMA. The first one to post a comment tends to spark and set the tone for the discussion.
  5. check back on reddit once an hour or so for the next day, answer questions
  6. *****
  7. profit!

Walter Bright

Contribute to this wiki

  • D as a second language sections should be completed
  • add more examples of how to shift idiom to speak fluent D
  • flesh out the Python page
  • review empty sections
  • update C and C++ transition guides

One note about Walter's older C/C++ transition articles. They have good information on transition technicalities (e.g. "how do I do this thing in D that I used to do in C++?") but not a lot about the changes in coding style - making object copying not arbitrarily expensive, choosing struct vs. class, preferring pipelines and lazy to eager computation, etc. From what I see some folks come from C++, write their first D program in a stilted C++ idiom, and are left with the impression that the work is not worth the trouble.

Andrei

See also