Initial commit
This commit is contained in:
commit
286dc71134
47
.github/ISSUE_TEMPLATE/bug_report.md
vendored
Normal file
47
.github/ISSUE_TEMPLATE/bug_report.md
vendored
Normal file
@ -0,0 +1,47 @@
|
|||||||
|
---
|
||||||
|
name: Bug report
|
||||||
|
about: Create a report to help us improve
|
||||||
|
title: ''
|
||||||
|
labels: ''
|
||||||
|
assignees: ''
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!--
|
||||||
|
Need help?
|
||||||
|
Refer to our contributing guidelines for additional information about making a good issue:
|
||||||
|
https://github.com/ethereum-optimism/.github/blob/master/CONTRIBUTING.md
|
||||||
|
-->
|
||||||
|
|
||||||
|
**Bug Description**
|
||||||
|
A clear and concise description of what the bug is.
|
||||||
|
|
||||||
|
**Steps to Reproduce**
|
||||||
|
|
||||||
|
1. Outline the steps to reproduce the bug.
|
||||||
|
2. Be specific and detailed to help developers replicate the issue.
|
||||||
|
|
||||||
|
**Expected behavior**
|
||||||
|
A clear and concise description of what you expected to happen.
|
||||||
|
|
||||||
|
**Environment Information:**
|
||||||
|
- Operating System: [e.g. Ubuntu 20.04]
|
||||||
|
- Package Version (or commit hash): [e.g. op-node v1.5.1, op-node c934019]
|
||||||
|
|
||||||
|
**Configurations:**
|
||||||
|
Command line flags or environment variables you're using.
|
||||||
|
|
||||||
|
**Logs:**
|
||||||
|
Logs and/or error messages that help illustrate the issue.
|
||||||
|
|
||||||
|
**Additional context**
|
||||||
|
Add any other context about the problem here.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
⚠️ **Notice:** Issues that do not include the following sections will be subject to closure:
|
||||||
|
- Bug Description
|
||||||
|
- Steps to Reproduce
|
||||||
|
- Environment Information
|
||||||
|
|
||||||
|
Please ensure all required sections are filled out accurately to expedite the debugging process and improve issue resolution efficiency.
|
26
.github/ISSUE_TEMPLATE/feature_request.md
vendored
Normal file
26
.github/ISSUE_TEMPLATE/feature_request.md
vendored
Normal file
@ -0,0 +1,26 @@
|
|||||||
|
---
|
||||||
|
name: Feature request
|
||||||
|
about: Suggest an idea for this project
|
||||||
|
title: ''
|
||||||
|
labels: ''
|
||||||
|
assignees: ''
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
<!--
|
||||||
|
Need help?
|
||||||
|
Refer to our contributing guidelines for additional information about making a good issue:
|
||||||
|
https://github.com/ethereum-optimism/.github/blob/master/CONTRIBUTING.md
|
||||||
|
-->
|
||||||
|
|
||||||
|
**Is your feature request related to a problem? Please describe.**
|
||||||
|
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
|
||||||
|
|
||||||
|
**Describe the solution you'd like**
|
||||||
|
A clear and concise description of what you want to happen.
|
||||||
|
|
||||||
|
**Describe alternatives you've considered**
|
||||||
|
A clear and concise description of any alternative solutions or features you've considered.
|
||||||
|
|
||||||
|
**Additional context**
|
||||||
|
Add any other context or screenshots about the feature request here.
|
23
.github/ISSUE_TEMPLATE/project_template.md
vendored
Normal file
23
.github/ISSUE_TEMPLATE/project_template.md
vendored
Normal file
@ -0,0 +1,23 @@
|
|||||||
|
# Project Overivew
|
||||||
|
|
||||||
|
A breif description of what the project. Why do we have this project, what are its goals. Remember to add the "Project" label to this issue.
|
||||||
|
|
||||||
|
## Timeline
|
||||||
|
|
||||||
|
Start and finish date.
|
||||||
|
Remember that projects MUST take more than 6 weeks to complete. Anything shorter than that is an issue, not a project.
|
||||||
|
Remeber to also put the timeline in the timeline feild (somewhere to the right of this).
|
||||||
|
|
||||||
|
## Dependancies & Blockers
|
||||||
|
|
||||||
|
### Signoffs Required
|
||||||
|
|
||||||
|
i.e @legal needs to sign off by [date & time].
|
||||||
|
|
||||||
|
### Dependancies
|
||||||
|
|
||||||
|
Links to projects or issues that are blocking for this project, that are NOT a part of this project.
|
||||||
|
|
||||||
|
## Issues
|
||||||
|
|
||||||
|
Links to all the issues needed to complete this project.
|
40
.github/ISSUE_TEMPLATE/project_template_fancy.yml
vendored
Normal file
40
.github/ISSUE_TEMPLATE/project_template_fancy.yml
vendored
Normal file
@ -0,0 +1,40 @@
|
|||||||
|
name: Project Template
|
||||||
|
description: High level issue for tracking a project.
|
||||||
|
title: "Project: "
|
||||||
|
labels: ["Project"]
|
||||||
|
body:
|
||||||
|
- type: textarea
|
||||||
|
id: description
|
||||||
|
attributes:
|
||||||
|
label: High level description of project.
|
||||||
|
value: A breif description of what the project. Why do we have this project, what are its goals.
|
||||||
|
validations:
|
||||||
|
required: true
|
||||||
|
- type: markdown
|
||||||
|
id: dependancies & blockers
|
||||||
|
attributes:
|
||||||
|
value: |
|
||||||
|
Dependancies and blockers of this project.
|
||||||
|
@legal needs to sign off by 2 OCT 2023 11:00 UTC.
|
||||||
|
This project is blocked by issue #34 from project #25.
|
||||||
|
validations:
|
||||||
|
required: true
|
||||||
|
- type: checkboxes
|
||||||
|
id: label-check
|
||||||
|
attributes:
|
||||||
|
label: Label Checks
|
||||||
|
options:
|
||||||
|
- label: I have added the team label for this project (CH, TH, Contributions).
|
||||||
|
required: true
|
||||||
|
- label: I have added the timeline for this project to the issue.
|
||||||
|
required: true
|
||||||
|
- type: markdown
|
||||||
|
id: Tasks
|
||||||
|
attributes:
|
||||||
|
value: |
|
||||||
|
Tasks for this project
|
||||||
|
#34 Planning & scoping the project.
|
||||||
|
#35 Coordinating with involved teams for sign off.
|
||||||
|
validations:
|
||||||
|
required: false
|
||||||
|
|
15
.github/ISSUE_TEMPLATE/task_template.md
vendored
Normal file
15
.github/ISSUE_TEMPLATE/task_template.md
vendored
Normal file
@ -0,0 +1,15 @@
|
|||||||
|
# Overview
|
||||||
|
|
||||||
|
What is the task? Remember that a task MUST take longer than 3 full work days to complete. Tasks are not intended to track granular issues, but lager tasks that need to be completed for a project to move forward.
|
||||||
|
|
||||||
|
## Timeline
|
||||||
|
|
||||||
|
End date of task. If the task has a hard deadline (impovable) please highlight that here.
|
||||||
|
|
||||||
|
## Links & Notes
|
||||||
|
|
||||||
|
If there are docs or places where the work is actually being done, please link them here.
|
||||||
|
|
||||||
|
If there is anything about this task that others should understand or be made aware of, please put them here.
|
||||||
|
|
||||||
|
Note that actual work should NOT live in GH issues. This is for tracking, not documenting.
|
74
CODE_OF_CONDUCT.md
Normal file
74
CODE_OF_CONDUCT.md
Normal file
@ -0,0 +1,74 @@
|
|||||||
|
## 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 contributing@optimism.io. 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][homepage], version 1.4,
|
||||||
|
available at [http://contributor-covenant.org/version/1/4][version].
|
||||||
|
|
||||||
|
[homepage]: http://contributor-covenant.org
|
||||||
|
[version]: http://contributor-covenant.org/version/1/4/
|
71
CONTRIBUTING.md
Normal file
71
CONTRIBUTING.md
Normal file
@ -0,0 +1,71 @@
|
|||||||
|
# Contributing
|
||||||
|
|
||||||
|
🎈 Thanks for your help improving the project! We are so happy to have you!
|
||||||
|
|
||||||
|
🚨 Before making any non-trivial change, please first open an issue describing the change to solicit feedback and guidance. This will increase the likelihood of the PR getting merged.
|
||||||
|
|
||||||
|
In general, the smaller the diff the easier it will be for us to review quickly.
|
||||||
|
|
||||||
|
Please note that we have a [Code of Conduct](./CODE_OF_CONDUCT.md), please follow it in all your interactions with the project.
|
||||||
|
|
||||||
|
# Pull Request Process
|
||||||
|
|
||||||
|
## Steps for the PR author
|
||||||
|
|
||||||
|
We recommend using the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) format on commit messages.
|
||||||
|
|
||||||
|
Before opening a PR:
|
||||||
|
|
||||||
|
1. Ensure that tests pass and code is lint free. You can run `yarn test` and `yarn lint` locally to check.
|
||||||
|
1. Update the README.md if your changes invalidate or extend its current content.
|
||||||
|
1. Include tests for any new functionality.
|
||||||
|
1. Ensure each section of the [Pull Request Template](./PULL_REQUEST_TEMPLATE.md) is filled out. Delete any sections that are not relevant.
|
||||||
|
|
||||||
|
Unless your PR is ready for immediate review and merging, please mark it as 'draft' (or simply do not open a PR yet).
|
||||||
|
|
||||||
|
**Bonus:** Add comments to the diff under the "Files Changed" tab on the PR page to clarify any sections where you think we might have questions about the approach taken.
|
||||||
|
|
||||||
|
### Response time:
|
||||||
|
We aim to provide a meaningful response to all PRs and issues from external contributors within 2 business days.
|
||||||
|
|
||||||
|
## Steps for PR Reviewers
|
||||||
|
|
||||||
|
### For all PRs
|
||||||
|
|
||||||
|
Reviewers should submit their review with either `Approve` or `Request changes` options (not `Comment`).
|
||||||
|
|
||||||
|
If the reviewer selects `Request changes`, they should clearly indicate which changes they require in order to approve.
|
||||||
|
|
||||||
|
If the reviewer selects `Approves`, they should either:
|
||||||
|
1. immediately merge it, or
|
||||||
|
2. indicate what further review they deem necessary (and from whom).
|
||||||
|
|
||||||
|
We further distinguish between two classes of PR those which modify production code (ie. smart contracts, go-ethereum), and those which do not (ie. dev tooling, test scripts, comments).
|
||||||
|
|
||||||
|
### For PRs which modify production code
|
||||||
|
|
||||||
|
The reviewer's job is to check that the PR:
|
||||||
|
|
||||||
|
1. Conforms to the specification (WIP, soon to be published here), or has an issue describing the additional functionality which a code owner has approved.
|
||||||
|
2. Is appropriately tested.
|
||||||
|
3. Does not introduce security issues.
|
||||||
|
|
||||||
|
#### Merge Criteria
|
||||||
|
|
||||||
|
1. All CI checks MUST pass.
|
||||||
|
1. At least 2 code owners must approve.
|
||||||
|
1. In the case of very simple changes, a single code owner may choose to merge at their discretion.
|
||||||
|
|
||||||
|
### For PRs which modify non-production code
|
||||||
|
|
||||||
|
For PRs which do not modify production code (ie. test, dev tooling),
|
||||||
|
|
||||||
|
The reviewer's job is to check that the PR:
|
||||||
|
|
||||||
|
1. Is correct.
|
||||||
|
1. Is desirable.
|
||||||
|
|
||||||
|
#### Merge Criteria
|
||||||
|
|
||||||
|
1. All CI checks MUST pass.
|
||||||
|
1. At least one code owner must approve.
|
17
PULL_REQUEST_TEMPLATE.md
Normal file
17
PULL_REQUEST_TEMPLATE.md
Normal file
@ -0,0 +1,17 @@
|
|||||||
|
<!-- Contributions welcome! See https://github.com/ethereum-optimism/.github/blob/master/CONTRIBUTING.md -->
|
||||||
|
|
||||||
|
**Description**
|
||||||
|
|
||||||
|
A clear and concise description of the features you're adding in this pull request.
|
||||||
|
|
||||||
|
**Tests**
|
||||||
|
|
||||||
|
Please describe any tests you've added. If you've added no tests, or left important behavior untested, please explain why not.
|
||||||
|
|
||||||
|
**Additional context**
|
||||||
|
|
||||||
|
Add any other context about the problem you're solving.
|
||||||
|
|
||||||
|
**Metadata**
|
||||||
|
|
||||||
|
- Fixes #[Link to Issue]
|
4
README.md
Normal file
4
README.md
Normal file
@ -0,0 +1,4 @@
|
|||||||
|
# Community Health Files
|
||||||
|
This repository contains our default issue templates & other important community documents.
|
||||||
|
|
||||||
|
See: https://docs.github.com/en/free-pro-team@latest/github/building-a-strong-community/creating-a-default-community-health-file
|
50
SECURITY.md
Normal file
50
SECURITY.md
Normal file
@ -0,0 +1,50 @@
|
|||||||
|
# Security Policy
|
||||||
|
|
||||||
|
## How to disclose a vulnerability to us
|
||||||
|
|
||||||
|
### The wrong way to disclose
|
||||||
|
|
||||||
|
The following actions will disqualify you from eligibility for a reward:
|
||||||
|
|
||||||
|
1. Filing a public ticket mentioning the vulnerability
|
||||||
|
2. Testing the vulnerability on the mainnet or testnet
|
||||||
|
|
||||||
|
#### The right way to disclose
|
||||||
|
|
||||||
|
### Smart contract and infrastructure vulnerabilities
|
||||||
|
|
||||||
|
We have a bounty program with a maximum payout of $2,000,042. Please see [our bounty program](https://immunefi.com/bounty/optimism/) at Immunefi for more details.
|
||||||
|
|
||||||
|
### Other vulnerabilities
|
||||||
|
|
||||||
|
For vulnerabilities in any of our websites, email servers or other non-critical infrastructure, please email OP Labs at [security@oplabs.co](mailto:security@oplabs.co). We and Labs appreciate detailed instructions for confirming the vulnerability.
|
||||||
|
|
||||||
|
|
||||||
|
## How we disclose vulnerabilities
|
||||||
|
|
||||||
|
In the event that we learn of a critical security vulnerability, we reserve the right to
|
||||||
|
silently fix it without immediately publicly disclosing the existence of nature of the vulnerability.
|
||||||
|
|
||||||
|
In such a scenario we will:
|
||||||
|
|
||||||
|
1. silently fix a vulnerability and include the fix in release X,
|
||||||
|
2. after 4-8 weeks, we will disclose that X contained a security-fix,
|
||||||
|
3. after an additional 4-8 weeks, we will publish details of the vulnerability along with credit to the reporter (with express permission from the reporter).
|
||||||
|
|
||||||
|
Alongside this policy, we also reserve the right to do either of the following:
|
||||||
|
- bypass this policy and publish details on a shorter timeline
|
||||||
|
- to directly notify a subset of downstream users prior to making a public announcement
|
||||||
|
|
||||||
|
This policy is based the Geth team’s [silent patch policy](https://geth.ethereum.org/docs/vulnerabilities/vulnerabilities#why-silent-patches).
|
||||||
|
|
||||||
|
### Defensive measures during an incident
|
||||||
|
|
||||||
|
Our system does not currently have fault proofs, meaning we are able to pause the system in an
|
||||||
|
emergency.
|
||||||
|
|
||||||
|
We've established some guiding criteria for disabling the system during an incident response
|
||||||
|
situation:
|
||||||
|
|
||||||
|
- If an attack is ongoing: we should disable or pause in order to prevent further damage.
|
||||||
|
- If we suspect that a vulnerability might be widely known: we should disable or pause proactively.
|
||||||
|
- Otherwise: we should not disable or pause the system.
|
6
dependabot.yml
Normal file
6
dependabot.yml
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
version: 2
|
||||||
|
updates:
|
||||||
|
- package-ecosystem: 'npm'
|
||||||
|
directory: '/'
|
||||||
|
schedule:
|
||||||
|
interval: 'daily'
|
Loading…
Reference in New Issue
Block a user