From 951939d1b35ebfd1ac1f1a96ca02cbff0c056b63 Mon Sep 17 00:00:00 2001 From: Seth Tisue Date: Mon, 13 Jul 2015 18:56:11 -0400 Subject: contributor guide: add a morsel salvaged from GitHub wiki --- CONTRIBUTING.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 54334aea48..e6e0e0b923 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -47,6 +47,7 @@ A new language feature requires a SIP (Scala Improvement Process) proposal. For #### Summary 1. We require regression tests for bug fixes. New features and enhancements must be supported by a respectable test suite. + - Consider including comments in the test files that indicates what you're testing and why. Expected outcome, what happened before the fix, what happens now, that sort of thing. 2. Documentation. Yep! Also required :-) 3. Please follow these standard code standards, though in moderation (scouts quickly learn to let sleeping dogs lie): - Not violate [DRY](http://programmer.97things.oreilly.com/wiki/index.php/Don%27t_Repeat_Yourself). -- cgit v1.2.3 From e93ca409ae0d7cd6489c66f696ad564c77bcb6a2 Mon Sep 17 00:00:00 2001 From: Seth Tisue Date: Mon, 13 Jul 2015 18:57:45 -0400 Subject: drop in pull request policy from old wiki --- CONTRIBUTING.md | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e6e0e0b923..d7705512a3 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -54,3 +54,68 @@ A new language feature requires a SIP (Scala Improvement Process) proposal. For - [Boy Scout Rule](http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule) should be applied. Please also have a look at our [Pull Request Policy](https://github.com/scala/scala/wiki/Pull-Request-Policy), as well as the [Scala Hacker Guide](http://www.scala-lang.org/contribute/hacker-guide.html) by @xeno-by. + + +# Pull Request Policy + +taken from https://github.com/scala/scala/wiki/Pull-Request-Policy +before it was put out of its misery + +Hi there, pull request submitter! + +Your pull request should: + - (... have been discussed on scala-internals) + - merge cleanly + - consist of commits with messages that clearly state which problem this commit resolves and how + - it should be stated in the active, present tense + - its subject should be 60 characters or less + - [conventions](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) + - for a bug fix, the title must look like "SI-NNNN - don't crash when moon is in wrong phase" + - overall, think of the first line of the commit as a description of the action performed by the commit on the code base, so use the present tense -- that also makes them easy to reuse in release notes + - backports should be tagged as [backport], it's also nice to mention this when a commit purely refactors and is not intended to change behaviour + - when working on maintenance branches (e.g., 2.10.x), include [nomerge] if this commit should not be merged forward into the next release branch + - come with tests (included in the same commit as the functional change), or explain in detail why it cannot be tested (discuss this on scala-internals first). The tests itself should: + - be minimal, deterministic, stable (unaffected by irrelevant changes), easy to understand and review + - have minimal dependencies: a compiler bug should not depend on, e.g. the Scala library + - typically fail before your fix is applied (so we see that you are fixing a legitimate bug) and should obviously pass after your fix + - come with appropriate documentation + - for example, any API additions should include Scaladoc + - each commit must pass the test suite (checked automatically by the build bot by running approximately `ant test-opt`) + - a commit is considered a unit of useful change and must thus pass the test suite + (this way we stand a chance running git bisect later) + - be assigned to one or more reviewers (if you're not sure, see the list below or contact scala-internals) + - to assign a reviewer, add a "review by @reviewer" to your PR description. NOTE: it's best not to @mention in commit messages, as github pings you every time a commit with your @name on it shuffles through the system (even in other repos, on merges,...) + - get the green light from the reviewer ("LGTM" -- looks good to me) + - review feedback may be addressed by pushing new commits to the request, + if these commits stand on their own + +Once all these conditions are met, and we agree with the change +(we are available on scala-internals to discuss this beforehand), +we will merge your changes. + +Please note: you are responsible for meeting these criteria (reminding your reviewer, for example). + +### Pull request bot mechanics +* The build bot automatically builds commits as they appear in a PR. Click on the little x next to a commit sha to go to the overview of the PR validation job. To diagnose a failure, consult the console output of the job that failed. + * 'PLS REBUILD ALL' will force the bot to rebuild (only necessary when a spurious failure occurred -- i.e., you expect a different validation outcome without changing the commit shas that make up the PR) + +### List of reviewers by area: + +* library: @phaller (Philipp Haller), @axel22 (Aleksander Prokopec -- concurrent & collection) +* specialisation: @axel22 (Aleksander Prokopec), @vladureche (Vlad Ureche), @dragos (Iulian Dragos) +* named / default args, annotations, plugins: @lrytz (Lukas Rytz) +* macros, reflection, manifests, string interpolation: @xeno-by (Eugene Burmako), @cvogt (Christopher Vogt) +* type checker, inference: @odersky (Martin Odersky), @adriaanm (Adriaan Moors) +* Language specification, value classes: @odersky (Martin Odersky) +* new pattern matcher, implicit search: @adriaanm (Adriaan Moors) +* partest, Continuations Plugin: @phaller (Philipp Haller) +* error handling, lazy vals: @hubertp (Hubert Plociniczak) +* backend: @magarciaEPFL (Miguel Garcia), @gkossakowski (Grzegorz Kossakowski), @dragos (Iulian Dragos) +* repl, compiler performance: @retronym (Jason Zaugg) +* swing: @ingoem (Ingo Maier) +* scaladoc: @dickwall (Dick Wall) +* optimizer: @vladureche (Vlad Ureche), @magarciaEPFL (Miguel Garcia) +* build: @jsuereth (Josh Suereth) +* random compiler bugs: @lrytz, @adriaanm, @hubertp +* documentation: @heathermiller (Heather Miller), @dickwall (Dick Wall) +* cps: @TiarkRompf (Tiark Rompf) -- cgit v1.2.3 From 197845620cb827209272bb02e6740feac9f73a48 Mon Sep 17 00:00:00 2001 From: Seth Tisue Date: Wed, 15 Jul 2015 09:53:35 -0400 Subject: merge in text from pull request policy from old wiki --- CONTRIBUTING.md | 168 +++++++++++++++++++++++++++++++------------------------- README.md | 22 +++++++- 2 files changed, 114 insertions(+), 76 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index d7705512a3..1ea7e5513b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -38,84 +38,104 @@ Please make sure the JIRA ticket's fix version corresponds to the upcoming miles #### Enhancement or New Feature -For longer-running development, likely required for this category of code contributions, we suggest you include "topic" or "wip" in your branch name, to indicate that this is work in progress, and that others should be prepared to rebase if they branch off your branch. +For longer-running development, likely required for this category of code contributions, we suggest you include "topic/" or "wip/" in your branch name, to indicate that this is work in progress, and that others should be prepared to rebase if they branch off your branch. Any language change (including bug fixes) must be accompanied by the relevant updates to the spec, which lives in the same repository for this reason. A new language feature requires a SIP (Scala Improvement Process) proposal. For more details on submitting SIPs, see [how to submit a SIP](http://docs.scala-lang.org/sips/sip-submission.html). -#### Summary - -1. We require regression tests for bug fixes. New features and enhancements must be supported by a respectable test suite. - - Consider including comments in the test files that indicates what you're testing and why. Expected outcome, what happened before the fix, what happens now, that sort of thing. -2. Documentation. Yep! Also required :-) -3. Please follow these standard code standards, though in moderation (scouts quickly learn to let sleeping dogs lie): - - Not violate [DRY](http://programmer.97things.oreilly.com/wiki/index.php/Don%27t_Repeat_Yourself). - - [Boy Scout Rule](http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule) should be applied. - -Please also have a look at our [Pull Request Policy](https://github.com/scala/scala/wiki/Pull-Request-Policy), as well as the [Scala Hacker Guide](http://www.scala-lang.org/contribute/hacker-guide.html) by @xeno-by. - - -# Pull Request Policy - -taken from https://github.com/scala/scala/wiki/Pull-Request-Policy -before it was put out of its misery - -Hi there, pull request submitter! - -Your pull request should: - - (... have been discussed on scala-internals) - - merge cleanly - - consist of commits with messages that clearly state which problem this commit resolves and how - - it should be stated in the active, present tense - - its subject should be 60 characters or less - - [conventions](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) - - for a bug fix, the title must look like "SI-NNNN - don't crash when moon is in wrong phase" - - overall, think of the first line of the commit as a description of the action performed by the commit on the code base, so use the present tense -- that also makes them easy to reuse in release notes - - backports should be tagged as [backport], it's also nice to mention this when a commit purely refactors and is not intended to change behaviour - - when working on maintenance branches (e.g., 2.10.x), include [nomerge] if this commit should not be merged forward into the next release branch - - come with tests (included in the same commit as the functional change), or explain in detail why it cannot be tested (discuss this on scala-internals first). The tests itself should: - - be minimal, deterministic, stable (unaffected by irrelevant changes), easy to understand and review - - have minimal dependencies: a compiler bug should not depend on, e.g. the Scala library - - typically fail before your fix is applied (so we see that you are fixing a legitimate bug) and should obviously pass after your fix - - come with appropriate documentation - - for example, any API additions should include Scaladoc - - each commit must pass the test suite (checked automatically by the build bot by running approximately `ant test-opt`) - - a commit is considered a unit of useful change and must thus pass the test suite - (this way we stand a chance running git bisect later) - - be assigned to one or more reviewers (if you're not sure, see the list below or contact scala-internals) - - to assign a reviewer, add a "review by @reviewer" to your PR description. NOTE: it's best not to @mention in commit messages, as github pings you every time a commit with your @name on it shuffles through the system (even in other repos, on merges,...) - - get the green light from the reviewer ("LGTM" -- looks good to me) - - review feedback may be addressed by pushing new commits to the request, - if these commits stand on their own - -Once all these conditions are met, and we agree with the change -(we are available on scala-internals to discuss this beforehand), -we will merge your changes. +## Guidelines -Please note: you are responsible for meeting these criteria (reminding your reviewer, for example). +Here is some advice on how to craft a pull request with the best possible +chance of being accepted. + +### Merging + +A pull request should merge cleanly. (If enough time passes after +your initial submission, we may ask you to rebase it onto the current +mainline code.) + +### Tests + +Bug fixes should include regression tests -- in the same commit as the fix. + +If testing isn't feasible, the commit message should explain why. +(Consider discussing on scala-internals first.) + +New features and enhancements must be supported by a respectable test suite. + +Consider including comments in the test files that indicate what you're testing and why. Expected outcome, what happened before the fix, what happens now, that sort of thing. + +Some characteristics of good tests: + +* be minimal, deterministic, stable (unaffected by irrelevant changes), easy to understand and review +* have minimal dependencies: a compiler bug test should not depend on, e.g., the Scala library +* typically fail before your fix is applied (so we see that you are fixing a legitimate bug) and should obviously pass after your fix + +### Documentation + +This is of course required for new features and enhancements. + +Any API additions should include Scaladoc. + +Don't forget to update the package-level doc (in the package object), if appropriate. + +### Coding standards + +Please follow these standard code standards, though in moderation (scouts quickly learn to let sleeping dogs lie): + +* Don't violate [DRY](http://programmer.97things.oreilly.com/wiki/index.php/Don%27t_Repeat_Yourself). +* Follow the [Boy Scout Rule](http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule). + +Please also have a look at the [Scala Hacker Guide](http://www.scala-lang.org/contribute/hacker-guide.html) by @xeno-by. + +### Clean commits, clean history -### Pull request bot mechanics -* The build bot automatically builds commits as they appear in a PR. Click on the little x next to a commit sha to go to the overview of the PR validation job. To diagnose a failure, consult the console output of the job that failed. - * 'PLS REBUILD ALL' will force the bot to rebuild (only necessary when a spurious failure occurred -- i.e., you expect a different validation outcome without changing the commit shas that make up the PR) - -### List of reviewers by area: - -* library: @phaller (Philipp Haller), @axel22 (Aleksander Prokopec -- concurrent & collection) -* specialisation: @axel22 (Aleksander Prokopec), @vladureche (Vlad Ureche), @dragos (Iulian Dragos) -* named / default args, annotations, plugins: @lrytz (Lukas Rytz) -* macros, reflection, manifests, string interpolation: @xeno-by (Eugene Burmako), @cvogt (Christopher Vogt) -* type checker, inference: @odersky (Martin Odersky), @adriaanm (Adriaan Moors) -* Language specification, value classes: @odersky (Martin Odersky) -* new pattern matcher, implicit search: @adriaanm (Adriaan Moors) -* partest, Continuations Plugin: @phaller (Philipp Haller) -* error handling, lazy vals: @hubertp (Hubert Plociniczak) -* backend: @magarciaEPFL (Miguel Garcia), @gkossakowski (Grzegorz Kossakowski), @dragos (Iulian Dragos) -* repl, compiler performance: @retronym (Jason Zaugg) -* swing: @ingoem (Ingo Maier) -* scaladoc: @dickwall (Dick Wall) -* optimizer: @vladureche (Vlad Ureche), @magarciaEPFL (Miguel Garcia) -* build: @jsuereth (Josh Suereth) -* random compiler bugs: @lrytz, @adriaanm, @hubertp -* documentation: @heathermiller (Heather Miller), @dickwall (Dick Wall) -* cps: @TiarkRompf (Tiark Rompf) +A pull request should consist of commits with messages that clearly state what problem the commit resolves and how. + +Commit logs should be stated in the active, present tense. + +A commit's subject should be 60 characters or less. Overall, think of +the first line of the commit as a description of the action performed +by the commit on the code base, so use the active voice and the +present tense. That also makes the commit subjects easy to reuse in +release notes. + +For a bugfix, the title must look like "SI-NNNN - don't crash when +moon is in wrong phase". + +If a commit purely refactors and is not intended to change behaviour, +say so. + +Backports should be tagged as "[backport]". + +When working on maintenance branches (e.g., 2.11.x), include "[nomerge]" +if this commit should not be merged forward into the next release +branch. + +Here are is standard advice on good commit messages: +http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html + +### Pass Scabot + +Our pull request bot, Scabot, automatically builds all the commits in a PR individually. (All, so we can `git bisect` later.) + +Click on the little x next to a commit sha to go to the overview of the PR validation job. To diagnose a failure, consult the console output of the job that failed. + +See the [scala-jenkins-infra repo](https://github.com/scala/scala-jenkins-infra) and [Scabot repo](https://github.com/) for full details on PR validation. One tip you should know is that commenting `/rebuild` on a PR asks validation to be run again on the same commits. This is only necessary when a spurious failure occurred. + +### Pass code review + +Your PR will need to be assigned to one or more reviewers. You can suggest reviewers yourself; if you're not sure, see the list in [README.md](README.md) or ask on scala-internals. + +To assign a reviewer, add a "review by @reviewer" to your PR description. + +NOTE: it's best not to @mention in commit messages, as github pings you every time a commit with your @name on it shuffles through the system (even in other repos, on merges,...). + +A reviewer gives the green light by commenting "LGTM" (looks good to me). + +A review feedback may be addressed by pushing new commits to the request, if these commits stand on their own. + +Once all these conditions are met, and we agree with the change (we are available on scala-internals to discuss this beforehand, before you put in the coding work!), we will merge your changes. + +Please note: you are responsible for meeting these criteria (reminding your reviewer, for example). diff --git a/README.md b/README.md index e722c88e41..e2174e8013 100644 --- a/README.md +++ b/README.md @@ -23,8 +23,26 @@ If you need some help with your PR at any time, please feel free to @-mention an | [`@xeno-by`](https://github.com/xeno-by) | macros and reflection | | [`@dickwall`](https://github.com/dickwall) | process & community | - -PS: If you have some spare time to help out around here, we would be delighted to add your name to this list! +additional reviewer suggestions: + +* library: @phaller (Philipp Haller), @axel22 (Aleksander Prokopec -- concurrent & collection) +* specialisation: @axel22 (Aleksander Prokopec), @vladureche (Vlad Ureche), @dragos (Iulian Dragos) +* named / default args, annotations, plugins: @lrytz (Lukas Rytz) +* macros, reflection, manifests, string interpolation: @xeno-by (Eugene Burmako), @cvogt (Christopher Vogt) +* type checker, inference: @odersky (Martin Odersky), @adriaanm (Adriaan Moors) +* language specification, value classes: @odersky (Martin Odersky) +* new pattern matcher, implicit search: @adriaanm (Adriaan Moors) +* partest: @phaller (Philipp Haller) +* error handling, lazy vals: @hubertp (Hubert Plociniczak) +* backend: @lrytz (Lukas Rytz), @retronym (Jason Zaugg), @dragos (Iulian Dragos) +* repl, compiler performance: @retronym (Jason Zaugg) +* scaladoc: @dickwall (Dick Wall), @vladureche (Vlad Ureche) +* optimizer: @vladureche (Vlad Ureche), @lrytz (Lukas Rytz) +* build: @jsuereth (Josh Suereth) +* random compiler bugs: @retronym, @lrytz, @adriaanm +* documentation: @heathermiller (Heather Miller), @dickwall (Dick Wall) + +P.S.: If you have some spare time to help out around here, we would be delighted to add your name to this list! # Handy Links - [A wealth of documentation](http://docs.scala-lang.org) -- cgit v1.2.3 From 80e98b03a1cf2cc332e65c80f0d0baf49621b3df Mon Sep 17 00:00:00 2001 From: Seth Tisue Date: Wed, 15 Jul 2015 22:16:19 -0400 Subject: tiny readme fix --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index e2174e8013..74a4ce97a8 100644 --- a/README.md +++ b/README.md @@ -169,7 +169,7 @@ to build the compiler. You can run `sbt test` to run unit (JUnit) tests. Use `sbt test/it:test` to run integration (partest) tests. We would like to migrate to sbt build as quickly as possible. If you would -like to help please contact scala-internals@ mailing list to discuss your +like to help please use the scala-internals mailing list to discuss your ideas and coordinate your effort with others. ### Tips and tricks -- cgit v1.2.3 From f9ca6863d46ede2b8ce4b7753c5c54120c0864ad Mon Sep 17 00:00:00 2001 From: Seth Tisue Date: Thu, 16 Jul 2015 08:08:42 -0400 Subject: readme/contributor's guide tweaks based on feedback from lrytz --- CONTRIBUTING.md | 9 --------- README.md | 12 +++++------- 2 files changed, 5 insertions(+), 16 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1ea7e5513b..9471830571 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -49,18 +49,11 @@ A new language feature requires a SIP (Scala Improvement Process) proposal. For Here is some advice on how to craft a pull request with the best possible chance of being accepted. -### Merging - -A pull request should merge cleanly. (If enough time passes after -your initial submission, we may ask you to rebase it onto the current -mainline code.) - ### Tests Bug fixes should include regression tests -- in the same commit as the fix. If testing isn't feasible, the commit message should explain why. -(Consider discussing on scala-internals first.) New features and enhancements must be supported by a respectable test suite. @@ -137,5 +130,3 @@ A reviewer gives the green light by commenting "LGTM" (looks good to me). A review feedback may be addressed by pushing new commits to the request, if these commits stand on their own. Once all these conditions are met, and we agree with the change (we are available on scala-internals to discuss this beforehand, before you put in the coding work!), we will merge your changes. - -Please note: you are responsible for meeting these criteria (reminding your reviewer, for example). diff --git a/README.md b/README.md index 74a4ce97a8..45138a281b 100644 --- a/README.md +++ b/README.md @@ -25,20 +25,18 @@ If you need some help with your PR at any time, please feel free to @-mention an additional reviewer suggestions: -* library: @phaller (Philipp Haller), @axel22 (Aleksander Prokopec -- concurrent & collection) +* library: @axel22 (Aleksander Prokopec -- concurrent & collection) * specialisation: @axel22 (Aleksander Prokopec), @vladureche (Vlad Ureche), @dragos (Iulian Dragos) * named / default args, annotations, plugins: @lrytz (Lukas Rytz) -* macros, reflection, manifests, string interpolation: @xeno-by (Eugene Burmako), @cvogt (Christopher Vogt) -* type checker, inference: @odersky (Martin Odersky), @adriaanm (Adriaan Moors) -* language specification, value classes: @odersky (Martin Odersky) +* macros, reflection, manifests, string interpolation: @xeno-by (Eugene Burmako) +* type checker, inference: @adriaanm (Adriaan Moors) +* language specification: @adriaanm (Adriaan Moors) * new pattern matcher, implicit search: @adriaanm (Adriaan Moors) -* partest: @phaller (Philipp Haller) -* error handling, lazy vals: @hubertp (Hubert Plociniczak) * backend: @lrytz (Lukas Rytz), @retronym (Jason Zaugg), @dragos (Iulian Dragos) * repl, compiler performance: @retronym (Jason Zaugg) * scaladoc: @dickwall (Dick Wall), @vladureche (Vlad Ureche) * optimizer: @vladureche (Vlad Ureche), @lrytz (Lukas Rytz) -* build: @jsuereth (Josh Suereth) +* build: @SethTisue * random compiler bugs: @retronym, @lrytz, @adriaanm * documentation: @heathermiller (Heather Miller), @dickwall (Dick Wall) -- cgit v1.2.3 From e136e4ad473623cc6b88652589e1a38c2ccbf440 Mon Sep 17 00:00:00 2001 From: Seth Tisue Date: Thu, 16 Jul 2015 08:14:57 -0400 Subject: tighten up CONTRIBUTING.md a little --- CONTRIBUTING.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 9471830571..e6557d78dd 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -57,13 +57,11 @@ If testing isn't feasible, the commit message should explain why. New features and enhancements must be supported by a respectable test suite. -Consider including comments in the test files that indicate what you're testing and why. Expected outcome, what happened before the fix, what happens now, that sort of thing. - Some characteristics of good tests: +* includes comments: what is being tested and why? * be minimal, deterministic, stable (unaffected by irrelevant changes), easy to understand and review * have minimal dependencies: a compiler bug test should not depend on, e.g., the Scala library -* typically fail before your fix is applied (so we see that you are fixing a legitimate bug) and should obviously pass after your fix ### Documentation @@ -71,7 +69,7 @@ This is of course required for new features and enhancements. Any API additions should include Scaladoc. -Don't forget to update the package-level doc (in the package object), if appropriate. +Consider updating the package-level doc (in the package object), if appropriate. ### Coding standards @@ -106,7 +104,7 @@ When working on maintenance branches (e.g., 2.11.x), include "[nomerge]" if this commit should not be merged forward into the next release branch. -Here are is standard advice on good commit messages: +Here is standard advice on good commit messages: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html ### Pass Scabot -- cgit v1.2.3 From ed5098dbc482f79140300acfab942dad2491a9b0 Mon Sep 17 00:00:00 2001 From: Seth Tisue Date: Mon, 27 Jul 2015 12:44:08 -0400 Subject: merge two reviewers lists in readme --- README.md | 32 +++++++++----------------------- 1 file changed, 9 insertions(+), 23 deletions(-) diff --git a/README.md b/README.md index 45138a281b..2655de43de 100644 --- a/README.md +++ b/README.md @@ -13,32 +13,18 @@ If you need some help with your PR at any time, please feel free to @-mention an | username | talk to me about... | --------------------------------------------------------------------------------------------------|----------------------------------------------------------------|---------------------------------------------------| - | [`@adriaanm`](https://github.com/adriaanm) | how we can help // type checker, pattern matcher, infrastructure | - | [`@SethTisue`](https://github.com/SethTisue) | back-end, library, improving the *welcome to Scala* experience | - | [`@retronym`](https://github.com/retronym) | Java 8 lambdas, tricky bug detective work | - | [`@Ichoran`](https://github.com/Ichoran) | the collections library, performance | + | [`@adriaanm`](https://github.com/adriaanm) | type checker, pattern matcher, infrastructure, language spec | + | [`@SethTisue`](https://github.com/SethTisue) | back-end, library, the welcome-to-Scala experience, build | + | [`@retronym`](https://github.com/retronym) | compiler performance, weird compiler bugs, Java 8 lambdas, REPL | + | [`@Ichoran`](https://github.com/Ichoran) | collections library, performance | | [`@lrytz`](https://github.com/lrytz) | optimizer, named & default arguments | - | [`@VladUreche`](https://github.com/VladUreche) | specialization & the scaladoc tool | + | [`@VladUreche`](https://github.com/VladUreche) | specialization, Scaladoc tool | | [`@densh`](https://github.com/densh) | quasiquotes, parser, string interpolators, macros in standard library | | [`@xeno-by`](https://github.com/xeno-by) | macros and reflection | - | [`@dickwall`](https://github.com/dickwall) | process & community | - -additional reviewer suggestions: - -* library: @axel22 (Aleksander Prokopec -- concurrent & collection) -* specialisation: @axel22 (Aleksander Prokopec), @vladureche (Vlad Ureche), @dragos (Iulian Dragos) -* named / default args, annotations, plugins: @lrytz (Lukas Rytz) -* macros, reflection, manifests, string interpolation: @xeno-by (Eugene Burmako) -* type checker, inference: @adriaanm (Adriaan Moors) -* language specification: @adriaanm (Adriaan Moors) -* new pattern matcher, implicit search: @adriaanm (Adriaan Moors) -* backend: @lrytz (Lukas Rytz), @retronym (Jason Zaugg), @dragos (Iulian Dragos) -* repl, compiler performance: @retronym (Jason Zaugg) -* scaladoc: @dickwall (Dick Wall), @vladureche (Vlad Ureche) -* optimizer: @vladureche (Vlad Ureche), @lrytz (Lukas Rytz) -* build: @SethTisue -* random compiler bugs: @retronym, @lrytz, @adriaanm -* documentation: @heathermiller (Heather Miller), @dickwall (Dick Wall) + | [`@heathermiller`](https://github.com/heathermiller) | documentation | + | [`@dickwall`](https://github.com/dickwall) | process & community, documentation | + | [`@dragos`](https://github.com/dragos) | specialization, back end | + | [`@axel22`](https://github.com/axel22) | collections, concurrency, specialization | P.S.: If you have some spare time to help out around here, we would be delighted to add your name to this list! -- cgit v1.2.3