docs: add community documentation
This PR introduces:
1. Issue templates for bug reports and feature requests
1. Pull request template
1. Code of conduct, which reuses the content from angular/angular
1. Guidelines for contributing to the project
1. A development document which explains how to get started with fixing
issues/implementing new rules. There's more work here, this is just the
initial draft
1. Update of the readme to introduce project scope
Closes #334
PiperOrigin-RevId: 225438111
diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
new file mode 100644
index 0000000..b7c861b
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -0,0 +1,75 @@
+---
+name: "\U0001F41EBug report"
+about: Report a bug in rules_typescript
+---
+<!--🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅
+
+Oh hi there! 😄
+
+To expedite issue processing please search open and closed issues before submitting a new one.
+Existing issues often contain information about workarounds, resolution, or progress updates.
+
+🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅-->
+
+
+# 🐞 bug report
+
+### Affected Rule
+
+<!-- Can you pin-point one or more rules_typescript as the source of the bug? -->
+<!-- ✍️edit: --> The issue is caused by the rule:
+
+
+### Is this a regression?
+
+<!-- Did this behavior use to work in the previous version? -->
+<!-- ✍️--> Yes, the previous version in which this bug was not present was: ....
+
+
+### Description
+
+<!-- ✍️--> A clear and concise description of the problem...
+
+
+## 🔬 Minimal Reproduction
+
+<!--
+Please create and share minimal reproduction of the issue. For the purpose you can create a GitHub repository and share a link. Make sure you don't upload any confidential files.
+-->
+
+## 🔥 Exception or Error
+
+<pre><code>
+<!-- If the issue is accompanied by an exception or an error, please share it below: -->
+<!-- ✍️-->
+
+</code></pre>
+
+
+## 🌍 Your Environment
+
+**Operating System:**
+
+<pre>
+ <code>
+
+ </code>
+</pre>
+
+**Output of `bazel version`:**
+
+<pre>
+ <code>
+
+ </code>
+</pre>
+
+**Rules version (SHA):**
+
+<pre>
+ <code>
+
+ </code>
+</pre>
+
+**Anything else relevant?**
diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md
new file mode 100644
index 0000000..be9fa49
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/feature_request.md
@@ -0,0 +1,47 @@
+---
+name: "\U0001F680Feature request"
+about: Suggest a feature for rules_typescript
+
+---
+<!--🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅
+
+Oh hi there! 😄
+
+To expedite issue processing please search open and closed issues before submitting a new one.
+Existing issues often contain information about workarounds, resolution, or progress updates.
+
+🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅-->
+
+
+# 🚀 feature request
+
+### Relevant Rules
+
+<!-- Tell us if you want to add a feature to an existing rule or add a new rule -->
+
+<!--
+
+If you're looking for a new rule first make sure you check awesome-bazel for an
+curated list of existing bazel rules https://github.com/jin/awesome-bazel
+
+If you don't find what you're looking for there, before opening a feature request make sure
+this repository is the right place for that.
+
+We have a list of requirements that the rules in this repository need to follow.
+You can check them in the README.md file of the project.
+
+-->
+
+### Description
+
+<!-- ✍️--> A clear and concise description of the problem or missing capability...
+
+
+### Describe the solution you'd like
+
+<!-- ✍️--> If you have a solution in mind, please describe it.
+
+
+### Describe alternatives you've considered
+
+<!-- ✍️--> Have you considered any alternative solutions or workarounds?
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
new file mode 100644
index 0000000..1f8ff5e
--- /dev/null
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -0,0 +1,43 @@
+## PR Checklist
+
+Please check if your PR fulfills the following requirements:
+
+- [ ] Tests for the changes have been added (for bug fixes / features)
+- [ ] Docs have been added / updated (for bug fixes / features)
+
+
+## PR Type
+
+What kind of change does this PR introduce?
+
+<!-- Please check the one that applies to this PR using "x". -->
+
+- [ ] Bugfix
+- [ ] Feature (please, look at the "Scope of the project" section in the README.md file)
+- [ ] Code style update (formatting, local variables)
+- [ ] Refactoring (no functional changes, no api changes)
+- [ ] Build related changes
+- [ ] CI related changes
+- [ ] Documentation content changes
+- [ ] Other... Please describe:
+
+
+## What is the current behavior?
+<!-- Please describe the current behavior that you are modifying, or link to a relevant issue. -->
+
+Issue Number: N/A
+
+
+## What is the new behavior?
+
+
+## Does this PR introduce a breaking change?
+
+- [ ] Yes
+- [ ] No
+
+
+<!-- If this PR contains a breaking change, please describe the impact and migration path for existing applications below. -->
+
+
+## Other information
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
new file mode 100644
index 0000000..b21a395
--- /dev/null
+++ b/CODE_OF_CONDUCT.md
@@ -0,0 +1,15 @@
+# Contributor Code of Conduct
+
+The project is currently maintained by a subset of the Angular team. This means that the collaborators and the maintainers of `rules_typescript` should be familiar with, and follow, the Angular's code of conduct.
+
+## Version 0.3b-angular
+
+As contributors and maintainers of the `rules_typescript` project, we pledge to respect everyone who contributes by posting issues, updating documentation, submitting pull requests, providing feedback in comments, and any other activities.
+
+Communication through any of the channels (GitHub, Gitter, IRC, mailing lists, Google+, Twitter, etc.) must be constructive and never resort to personal attacks, trolling, public or private harassment, insults, or other unprofessional conduct.
+
+We promise to extend courtesy and respect to everyone involved in this project regardless of gender, gender identity, sexual orientation, disability, age, race, ethnicity, religion, or level of experience. We expect anyone contributing to the project to do the same.
+
+If any member of the community violates this code of conduct, the maintainers of the project project may take action, removing issues, comments, and PRs or blocking accounts as deemed appropriate.
+
+If you are subject to or witness unacceptable behavior, or have any other concerns, please email us at [conduct@angular.io](mailto:conduct@angular.io).
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 745cbdc..fde88d2 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,6 +1,7 @@
Want to contribute? Great! First, read this page (including the small print at the end).
### Before you contribute
+
**Before we can use your code, you must sign the
[Google Individual Contributor License Agreement](https://developers.google.com/open-source/cla/individual?csw=1)
(CLA)**, which you can do online.
@@ -17,11 +18,19 @@
with us first. Use the issue tracker to explain your idea so we can help and
possibly guide you.
+**Before starting a complex contribution we strongly encourage you to share a design document**.
+
+[Here](https://goo.gl/YCQttR) you can find a document template.
+
### Code reviews and other contributions.
+
**All submissions, including submissions by project members, require review.**
-TODO(alexeagle): document how external contributions are handled.
+We use GitHub's code review system to suggest changes, then merge the changes
+to master when the PR is green and reviewed. The changes will then be in the
+next release.
### The small print
+
Contributions made by corporations are covered by a different agreement than
the one above, the
[Software Grant and Corporate Contributor License Agreement](https://cla.developers.google.com/about/google-corporate).
diff --git a/DEVELOPING.md b/DEVELOPING.md
new file mode 100644
index 0000000..66ec8fb
--- /dev/null
+++ b/DEVELOPING.md
@@ -0,0 +1,25 @@
+# For Developers
+
+We strongly encourage you to review the project's scope described in the `README.md` file before working on new features. For large changes, consider writing a design document using [this template](https://goo.gl/YCQttR).
+
+### Releasing
+
+Start from a clean checkout at master/HEAD. Check if there are any breaking
+changes since the last tag - if so, this will be a minor, if not, it's a patch.
+(This may not sound like semver - but since our major version is a zero, the
+rule is that minors are breaking changes and patches are new features).
+
+1. Re-generate the API docs: `yarn skydoc`
+1. May be necessary if Go code has changed though probably it was already necessary to run this to keep CI green: `bazel run :gazelle`
+1. If we depend on a newer rules_nodejs, update the `check_rules_nodejs_version` in `ts_repositories.bzl`
+1. `git commit -a -m 'Update docs for release'`
+1. `npm config set tag-version-prefix ''`
+1. `npm version minor -m 'rel: %s'` (replace `minor` with `patch` if no breaking changes)
+1. Build npm packages and publish them: `bazel run //internal:npm_package.publish && bazel run //internal/karma:npm_package.publish`
+1. `bazel build :release`
+1. `git push && git push --tags`
+1. (Manual for now) go to the [releases] page, edit the new release, and attach the `bazel-bin/release.tgz` file
+1. (Temporary): submit a google3 CL to update the versions in package.bzl and package.json
+
+[releases]: https://github.com/bazelbuild/rules_typescript/releases
+
diff --git a/README.md b/README.md
index a1a344b..2eba1cc 100644
--- a/README.md
+++ b/README.md
@@ -91,6 +91,14 @@
)
```
+# Scope of the project
+
+This repository contains an orthogonal set of rules which covers an opinionated toolchain for TypeScript development. When requesting a new rule, describe your use case, why it's important, and why you can't do it with the existing rules. This is because we have limited resources to maintain additional rules.
+
+The repository accepts contributions in terms of bug fixes or implementing new features in existing rules. If you're planning to implement a new rule, please strongly consider opening a [feature request](https://github.com/bazelbuild/rules_typescript/issues/new) first so the project's maintainers can decide if it belongs to the scope of this project or not.
+
+For rules outside of the scope of the projects we recommend hosting them in your GitHub account or the one of your organization.
+
# Self-managed npm dependencies
We recommend you use Bazel managed dependencies but if you would like
@@ -331,23 +339,3 @@
[gazelle]: https://github.com/bazelbuild/rules_go/tree/master/go/tools/gazelle
-### Releasing
-
-Start from a clean checkout at master/HEAD. Check if there are any breaking
-changes since the last tag - if so, this will be a minor, if not, it's a patch.
-(This may not sound like semver - but since our major version is a zero, the
-rule is that minors are breaking changes and patches are new features).
-
-1. Re-generate the API docs: `yarn skydoc`
-1. May be necessary if Go code has changed though probably it was already necessary to run this to keep CI green: `bazel run :gazelle`
-1. If we depend on a newer rules_nodejs, update the `check_rules_nodejs_version` in `ts_repositories.bzl`
-1. `git commit -a -m 'Update docs for release'`
-1. `npm config set tag-version-prefix ''`
-1. `npm version minor -m 'rel: %s'` (replace `minor` with `patch` if no breaking changes)
-1. Build npm packages and publish them: `bazel run //internal:npm_package.publish && bazel run //internal/karma:npm_package.publish`
-1. `bazel build :release`
-1. `git push && git push --tags`
-1. (Manual for now) go to the [releases] page, edit the new release, and attach the `bazel-bin/release.tgz` file
-1. (Temporary): submit a google3 CL to update the versions in package.bzl and package.json
-
-[releases]: https://github.com/bazelbuild/rules_typescript/releases
