[readme] Modernize a.js-core repo

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,42 @@
+# 🎉 Thanks for taking the time to contribute to Analytics.js! 🎉
+
+It is highly appreciated that you take the time to help improve Analytics.js.
+We appreciate it if you would take the time to write up a bug report or feature request.
+
+If we don't receive enough information, or the issue/feature request doesn't
+align well with our roadmap, we might respectfully thank you for your time, and close the issue.
+
+_Bug fixes and documentation fixes are welcome._
+
+## In the case of a bug report 🐞
+
+Please consider the following items when filing a bug report:
+
+- Issue and steps to reproduce.
+- Versions.
+- Screenshots.
+- Expected result.
+- Actual result.
+- Link to your project.
+- Browser name and version.
+- Operating system.
+
+## In the case of a feature/component request ✍️
+
+Please consider the following items when filing a feature request:
+
+- Problem that feature/component addresses.
+- Examples in other projects of feature/component.
+- Ideas of how to implement the feature.
+
+See the contributing guide for more details.
+
+## Respect earns Respect 👏
+
+Please respect our Code of Conduct, in short:
+
+- Using welcoming and inclusive language.
+- Being respectful of differing viewpoints and experiences.
+- Gracefully accepting constructive criticism.
+- Focusing on what is best for the community.
+- Showing empathy towards other community members.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,26 @@
+# 🎉 Thanks for taking the time to contribute to Analytics.js! 🎉
+
+It is highly appreciated that you take the time to help improve Analytics.js.
+We appreciate it if you would take the time to document your Pull Request.
+
+Sadly, if we don't receive enough information, or the Pull Request doesn't
+align well with our roadmap, we might respectfully thank you for your time, and close the issue.
+
+## Checklist
+
+Please ensure the following are completed to help get your PR merged:
+
+- [ ] Thorough explanation of the issue/solution, and a link to the related issue
+- [ ] CI tests are passing
+- [ ] Unit tests were written for any new code
+- [ ] Code coverage is at least maintained, or increased.
+
+## Respect earns Respect 👏
+
+Please respect our Code of Conduct, in short:
+
+- Using welcoming and inclusive language.
+- Being respectful of differing viewpoints and experiences.
+- Gracefully accepting constructive criticism.
+- Focusing on what is best for the community.
+- Showing empathy towards other community members.

.github/stale.yml

@@ -0,0 +1,25 @@
+# Number of days of inactivity before an issue becomes stale
+daysUntilStale: 60
+# Number of days of inactivity before a stale issue is closed
+daysUntilClose: 7
+# Issues with these labels will never be considered stale
+exemptLabels:
+  - pinned
+  - security
+exemptMilestones: true
+exemptAssignees: true
+exemptProjects: true
+# Label to use when marking an issue as stale
+staleLabel: stale
+# Comment to post when marking an issue as stale. Set to `false` to disable
+markComment: >
+  This issue has been automatically marked `stale` because it has not had
+  any activity in the last 60 days. If no further activity occurs within 7
+  days, it will be closed. *Closed does not mean "never"*, just that it has
+  no momentum to get accomplished any time soon.
+  See [CONTRIBUTING.md](CONTRIBUTING.md) for more info.
+# Comment to post when closing a stale issue. Set to `false` to disable
+closeComment: >
+  Closing due to staleness. *Closed does not mean "never"*, just that it has
+  no momentum to get accomplished any time soon.
+  See [CONTRIBUTING.md](CONTRIBUTING.md) for more info.

CODE_OF_CONDUCT.md

@@ -0,0 +1,41 @@
+# 🏳️‍🌈 Contributor Covenant Code of Conduct 🏳️‍🌈
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment include:
+
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
+- Examples of unacceptable behavior by participants include:
+
+The use of sexualized language or imagery and unwelcome sexual attention or advances
+Trolling, insulting/derogatory comments, and personal or political attacks
+Public or private harassment
+Publishing others' private information, such as a physical or electronic address, without explicit permission
+Other conduct which could reasonably be considered inappropriate in a professional setting
+Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at friends@segment.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at http://contributor-covenant.org/version/1/4.

CONTRIBUTING.md

@@ -0,0 +1,63 @@
+Thanks for thinking about contributing to Analytics.js!
+
+Analytics.js is an open-source library that powers Segment. We've made it open source in the hope that other folks will find it useful. That said, making open source software takes a lot of work, so we try to keep Analytics.js focused on its goals. That means first and foremost supporting the use cases we have at Segment, but any other reasonable additions will be accepted with gratitude.
+
+The purpose of these guidelines is all about setting expectations.
+
+# Feature requests (`enhancement` label)
+
+New features should be requested via Issue first, to decide whether it falls within Analytics.js' scope. _Don't_ start with a feature PR without discussion.
+
+Even if it is decided that a feature fits Analytics.js' goals, that doesn't imply that someone is working on it. The only people who are obliged to work on a feature are the people who intend to use it. An `enhancement` issue without an assignee or a milestone means that nobody intends to work on it. If you're interested in working on it, just say so and we can assign it to you.
+
+An `enhancement` issue with a milestone means we intend to write it, but haven't decided who will do it yet.
+
+`enhancement` issues are subject to our [Staleness Policy](#Staleness Policy). An `enhancement` that's gone stale means that no one's intending to work on it, which implies the feature isn't really that important. If this isn't the case, commenting during the staleness grace period will freshen it; this should almost always be a commitment to implementing it.
+
+# Issues / Pull Requests
+
+- CI tests must be passing for a PR to be considered.
+- Issues must have reproduction steps and a detailed explanation of the issue.
+- PR template must be filled out.
+- Issue template must be filled out.
+- Unit tests must be present for PRs.
+- Code Coverage is at least maintained, or increased.
+
+# Timeliness
+
+As a user, there's nothing worse than crafting a beautiful PR with extensive tests only to be met with tumbleweeds from a long-abandoned project. We want to assure you that Analytics.js is maintained and actively worked on, but give you some guidelines on how long you might expect to wait before things get done.
+
+Issues should be triaged within 2 weeks, where triaging generally means figuring out which type of issue it is and adding labels.
+
+Pull requests (that have had design approval in an issue) should expect responses within a week.
+
+If you're finding we aren't abiding by these timelines, feel free to @-mention someone in [CODEOWNERS](.github/CODEOWNERS) to get our attention. If you're the shy type, don't worry that you're bothering us; you're helping us stick to the commitments we've made :)
+
+# Staleness
+
+All issues and PRs are subject to staleness after some period of inactivity. An issue/PR going stale indicates there isn't enough interest in getting it resolved. After some grace period, a stale issue/PR will be closed.
+
+An issue/PR being closed doesn't mean that it will never be addressed, just that there currently isn't any intention to do so.
+
+During the grace period, any activity will reset the staleness counter. Generally speaking, this should be a commitment to making progress.
+
+The current staleness policy is defined in [.github/stale.yml](.github/stale.yml).
+
+Stale issues get the `stale` label.
+
+# Labels
+
+- `bug`: behaviour in Analytics.js that is obviously wrong (but not necessarily obviously solvable).
+- `improvement`: a new feature. Without an assignee, it's looking for someone to take the reins and get it made.
+- `help wanted`: no pressing desire to get this addressed. An easy contribution for someone looking to get started contributing.
+- `repro hard` (issue): difficult to repro without specific setup. often of third party software. We'll make an effort to help narrow in on the problem, but probably can't guarantee we'll be able to make a definitive judgment on whether it's a real bug.
+- `question`: we'll make an effort to answer your question, but won't guarantee we can solve it.
+- `jira`: we're tracking this issue internally.
+
+# Anti-contribution
+
+- Obtuse commit messages, issues/PRs without any details.
+- Obviously, anything that violates our [Code of Conduct](CODE_OF_CONDUCT.md)
+- Noisy comments: "me too!", or "here's my setup" when the bug's already been located. Use a :thumbsup: emoji on the issue/PR instead, since we can count these.
+- Non-constructive complaining.
+- Feature PRs without a discussion issue: it's important we agree the feature is in-scope before anyone wastes time writing code or reviewing

README.md

@@ -9,6 +9,6 @@ To build this into a full, usable library, see the [Analytics.js](https://github
 
 ## License
 
-Released under the [MIT license](License.md).
+Released under the [MIT license](LICENSE).
 
 [analytics.js]: https://segment.com/docs/libraries/analytics.js/