├── special-interest-groups ├── infrastructure │ ├── meetings │ │ ├── .gitkeep │ │ └── 2023-05-09.md │ ├── README.md │ └── charter.md ├── readme-template.md ├── security │ ├── README.md │ └── charter.md ├── interoperability │ ├── README.md │ └── charter.md ├── docs │ ├── README.md │ └── charter.md ├── sig-proposal-process.md ├── contributor-experience │ ├── README.md │ ├── meetings │ │ └── q2-2023-technical-community-update.md │ └── charter.md └── charter-template.md ├── .github ├── ISSUE_TEMPLATE │ ├── config.yml │ ├── user-story.md │ ├── test-scenario.md │ ├── task.md │ └── bug-report.md └── workflows │ └── ci.yml ├── assets ├── structure │ └── icon-project-group-relationship-model.jpg └── guidelines │ └── architecture-diagrams │ └── Whiteboard - Example C4 System Context Diagram.svg ├── committees ├── steering-committee │ └── README.md └── security-response-committee │ └── SECURITY.md ├── user-groups ├── readme-template.md ├── ug-proposal-process.md ├── charter-template.md └── sustainability │ ├── meetings │ ├── 2023-02-27-cps.md │ ├── 2023-04-24-cps.md │ └── 2023-03-27-cps.md │ ├── analysis │ ├── case-study-node-butler.md │ ├── comparison-agora-vs-gangstabet.md │ ├── comparison-karma-finance-vs-node-butler.md │ ├── case-study-gangstabet.md │ ├── case-study-agora.md │ └── case-study-karma-finance.md │ ├── README.md │ └── charter.md ├── guidelines ├── communication │ ├── code-of-conduct.md │ ├── bug-bounty.md │ └── communication-guidelines.md ├── technical │ ├── release-template.md │ ├── audit-readiness-checklist.md │ ├── readme-template.md │ ├── software-architecture-design-guidelines.md │ ├── software-architecture-design-template.md │ └── software-development-guidelines.md ├── contribution │ └── README.md └── governance │ └── sig-governance-guidelines.md ├── todos-to-issues.md ├── templates └── community-member-individual-goals.md ├── README.md ├── GOVERNANCE.md ├── VALUES.md ├── CONTRIBUTING.md ├── CODE_OF_CONDUCT.md └── LICENSE /special-interest-groups/infrastructure/meetings/.gitkeep: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/config.yml: -------------------------------------------------------------------------------- 1 | blank_issues_enabled: true -------------------------------------------------------------------------------- /assets/structure/icon-project-group-relationship-model.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/icon-project/community/HEAD/assets/structure/icon-project-group-relationship-model.jpg -------------------------------------------------------------------------------- /committees/steering-committee/README.md: -------------------------------------------------------------------------------- 1 | # Steering committee 2 | 3 | {/* 4 | TODO: Add stuff about the steering committee. 5 | assignees: han-so1omon, CyrusVorwald-ICON, donghyun89 6 | */} -------------------------------------------------------------------------------- /user-groups/readme-template.md: -------------------------------------------------------------------------------- 1 | 2 | # UG #UGNAME 3 | 4 | ## Goals 5 | 6 | A short overview of the UG goals & scope. 7 | 8 | ## Projects 9 | 10 | - [List projects here](#link-project-repos-here) 11 | 12 | ## Contributing 13 | 14 | Link to the CONTRIBUTING.md 15 | 16 | ## Contact 17 | 18 | - [List comms channels here](#link-comms-channels-here) 19 | -------------------------------------------------------------------------------- /special-interest-groups/readme-template.md: -------------------------------------------------------------------------------- 1 | 2 | # SIG #SIGNAME 3 | 4 | ## Goals 5 | 6 | A short overview of the SIG goals & scope. 7 | 8 | ## Projects 9 | 10 | - [List projects here](#link-project-repos-here) 11 | 12 | ## Contributing 13 | 14 | Link to the CONTRIBUTING.md 15 | 16 | ## Contact 17 | 18 | - [List comms channels here](#link-comms-channels-here) 19 | -------------------------------------------------------------------------------- /.github/workflows/ci.yml: -------------------------------------------------------------------------------- 1 | name: "Continuous Integration" 2 | on: 3 | push: 4 | branches: [ main ] 5 | paths-ignore: 6 | - 'todos-to-issues.md' 7 | pull_request: 8 | paths-ignore: 9 | - 'todos-to-issues.md' 10 | jobs: 11 | build: 12 | runs-on: "ubuntu-latest" 13 | steps: 14 | - uses: "actions/checkout@master" 15 | - name: "TODO to Issue" 16 | uses: "alstr/todo-to-issue-action@v4.6.8" 17 | id: "todo" 18 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/user-story.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: User Story 3 | about: Describe a user story 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | ## Overview 11 | 12 | A clear and concise description of the user and their need 13 | 14 | ## Story 15 | 16 | As a [persona], I want [goal] so that [reason] 17 | 18 | ## Test Scenarios 19 | Link given/when/then test scenarios here 20 | 21 | ## Acceptance Criteria 22 | 23 | - Functional acceptance criteria to be met 24 | - Non-functional acceptance criteria to be met 25 | -------------------------------------------------------------------------------- /committees/security-response-committee/SECURITY.md: -------------------------------------------------------------------------------- 1 | # Security Release Process 2 | 3 | This document defines the ICON Foundation's security vulnerability reporting and fix release processes. 4 | 5 | ## Security advisories 6 | 7 | {/* 8 | TODO: Add stuff about the security response committee. 9 | assignees: han-so1omon 10 | */} 11 | 12 | ## Postmortem 13 | 14 | A postmortem should be published within 3 business days after the vulnerability fix is released. The postmortem should follow [Google's SRE postmortem best practices](https://landing.google.com/sre/book/chapters/postmortem-culture.html). 15 | -------------------------------------------------------------------------------- /guidelines/communication/code-of-conduct.md: -------------------------------------------------------------------------------- 1 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 2 | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 3 | "OPTIONAL" in this document are to be interpreted as described in 4 | [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). 5 | 6 | Projects sponsored by the ICON Foundation or [Contribution Proposal System](cps.icon.community) should practice good conduct between collaborators and users. Please see the [Contributor Covenant](https://www.contributor-covenant.org/) for a template of how to present a baseline of communication practices to your community members. -------------------------------------------------------------------------------- /special-interest-groups/security/README.md: -------------------------------------------------------------------------------- 1 | 2 | # SIG Security 3 | 4 | ## Goals 5 | 6 | This group covers horizontal security initiatives for the ICON ecosystem projects, including security audits, vulnerability management, security documentation, and community management on endeavors related to security 7 | 8 | ## Meetings 9 | 10 | {/* TODO: List public meetings here assignees: han-so1omon */} 11 | 12 | ## Projects 13 | 14 | None for this SIG 15 | 16 | ## Contributing 17 | 18 | [CONTRIBUTING.md](../../CONTRIBUTING.md) 19 | 20 | ## Contact 21 | 22 | {/* 23 | TODO: List comms channels here 24 | assignees: han-so1omon 25 | */} 26 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/test-scenario.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Test Scenario 3 | about: Describe a test scenario 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | ## Feature 11 | If applicable, include a link to the Git issue of the feature. Otherwise, describe what the feature being tested is. 12 | 13 | ## Scenario 14 | The case being tested 15 | 16 | * Given 17 | * The pre-conditions to the test. 18 | * When 19 | * The behavior to be tested. 20 | * Then 21 | * The expected outcome of the specified behavior. 22 | 23 | ## Bugs 24 | If applicable, include a link to the Git issue of the bugs identified performing the test. 25 | -------------------------------------------------------------------------------- /special-interest-groups/interoperability/README.md: -------------------------------------------------------------------------------- 1 | 2 | # SIG Interoperability 3 | 4 | ## Goals 5 | 6 | We contribute to cross-chain message transfer and communication services through technical development and advocacy. 7 | 8 | Currently this mostly entails the ICON Bridge project. 9 | 10 | ## Meetings 11 | 12 | {/* TODO: List public meetings here assignees: CyrusVorwald-ICON */} 13 | 14 | ## Projects 15 | 16 | - [ICON Bridge](https://github.com/icon-project/icon-bridge) 17 | 18 | ## Contributing 19 | 20 | Link to the CONTRIBUTING.md 21 | 22 | ## Contact 23 | 24 | {/* 25 | TODO: List comms channels here 26 | assignees: CyrusVorwald-ICON 27 | */} 28 | -------------------------------------------------------------------------------- /todos-to-issues.md: -------------------------------------------------------------------------------- 1 | # TODOs to Issues 2 | 3 | This repository is currently in the early stages of development and subject to change often. We use https://github.com/alstr/todo-to-issue-action to generate issues from TODOs 4 | 5 | ### Inline 6 | 7 | {/* TODO(TEST): Create an inline issue and manually assign */} 8 | 9 | ### Multiline 10 | 11 | Adding lines here 12 | 13 | {/* 14 | TODO(TEST): Create a multiline issue and automatically assign 15 | labels: enhancement, help wanted 16 | assignees: CyrusVorwald-ICON 17 | milestone: 1 18 | */} 19 | 20 | ### Notes 21 | 22 | It seems that you cannot edit issues and that having a TODO in the same lines of code as the last build results in no changes. 23 | -------------------------------------------------------------------------------- /templates/community-member-individual-goals.md: -------------------------------------------------------------------------------- 1 | ## Purpose 2 | This template is to be used for community members who would like to define their goals for participation. This can be to grow as a developer, start a business, run events, or whatever else 3 | 4 | This form can be used to discuss with ICON Ambassadors how to best participate in the ICON or overall web3 ecosystem so that you can accomplish your goals. From this page, you can work together to structure a roadmap for personal participation 5 | 6 | ## Summary 7 | Please use this section to briefly summarize your goals and perspective from a high level 8 | 9 | ## Goals 10 | *List your goals* 11 | - *Goal No. 1* 12 | - *Goal No. 2* 13 | - *Goal No. 3* 14 | 15 | ... 16 | 17 | -------------------------------------------------------------------------------- /special-interest-groups/infrastructure/README.md: -------------------------------------------------------------------------------- 1 | 2 | # SIG Infrastructure and Indexing 3 | 4 | ## Goals 5 | 6 | We build and maintain the community RPC endpoints, tracker, and related tools. 7 | 8 | ## Meetings 9 | 10 | - Meetings kept to ~30 min 11 | - Agenda items will be ranked in importance 12 | - Items not addressed will be left for later date 13 | - Frequency 14 | - 1 per quarter / 1 month depending on agendas 15 | 16 | ## Projects 17 | 18 | - [icon-tracker](https://github.com/sudoblockio/icon-tracker) 19 | 20 | ## Contributing 21 | 22 | Please file issues in the [icon-tracker](https://github.com/sudoblockio/icon-tracker) or any of the relevant associated repositories. 23 | 24 | ## Contact 25 | 26 | Rob Cannon (rob@sudoblock.io) 27 | -------------------------------------------------------------------------------- /special-interest-groups/docs/README.md: -------------------------------------------------------------------------------- 1 | 2 | # SIG Docs 3 | 4 | ## Goals 5 | 6 | Covers documentation, doc processes, and doc publishing for ICON ecosystem projects. 7 | 8 | ## Meetings 9 | 10 | {/* TODO: List public meetings here assignees: han-so1omon */} 11 | 12 | ## Projects 13 | 14 | - [devportal] - Developer docs for ICON network. Found at https://docs.icon.community 15 | 16 | ## Contributing 17 | 18 | [CONTRIBUTING.md](../../CONTRIBUTING.md) 19 | 20 | ## Contact 21 | 22 | [ICON Discord #dev_general](https://discord.com/channels/880651922682560582/898256107653464095) - Shared channel for technical discussions. Requires *Developer* role 23 | 24 | [ICON Discord #dev_support](https://discord.com/channels/880651922682560582/888476176237080687) - Shared channel for technical support. Requires *Developer* role 25 | 26 | 27 | [devportal]: https://github.com/icon-project/devportal -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/task.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Task 3 | about: Individual to-do 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | ### What needs to be done 11 | 12 | Describe what needs to be done here. 13 | 14 | Ex: "Relay synchronization starts from the most recently stored block header" 15 | 16 | ### Why it needs to be done 17 | 18 | Describe why it needs to be done here. 19 | 20 | Ex: "Reduces the amount of time for the relay to synchronize to the latest block" 21 | 22 | ### Tests 23 | 24 | Link associated tests here 25 | 26 | ### Stories 27 | 28 | Link associated stories here 29 | 30 | ### Acceptance Criteria 31 | 32 | Describe how we can know whether the task is done. 33 | 34 | Ex: 35 | - When restarting the relay, synchronization picks up from the most recently stored block 36 | 37 | ### Additional Information 38 | 39 | Describe anything relevant that hasn't been mentioned yet. 40 | -------------------------------------------------------------------------------- /user-groups/ug-proposal-process.md: -------------------------------------------------------------------------------- 1 | # User Group Proposal Process 2 | 3 | ## Introduction 4 | 5 | This document outlines the application process for creating a user group (UG). 6 | 7 | ## Forming a UG 8 | 9 | UGs may be formed by a group of ICON Community members or by the steering committee. The steering committee approves the formation of each UG and periodically reviews the activity of all UGs to ensure they are fulfilling their mission. 10 | 11 | Each ICON UG must draft a charter following the [charter template](charter-template.md) that defines its scope, deliverables, timeline, governance, and communication methods. 12 | 13 | The UG's charter should be submitted as a pull request that will be approved or rejected by the steering committee members. 14 | 15 | {/* 16 | TODO: Add members of the steering committee in an OWNERS.md file and reference here. 17 | assignees: han-so1omon, CyrusVorwald-ICON, donghyun89 18 | */} 19 | -------------------------------------------------------------------------------- /special-interest-groups/sig-proposal-process.md: -------------------------------------------------------------------------------- 1 | # Special Interest Group Proposal Process 2 | 3 | ## Introduction 4 | 5 | This document outlines the application process for creating a special interest group (SIG). 6 | 7 | ## Forming a SIG 8 | 9 | SIGs may be formed by a group of ICON Community members or by the steering committee. The steering committee approves the formation of each SIG and periodically reviews the activity of all SIGs to ensure they are fulfilling their mission. 10 | 11 | Each ICON SIG must draft a charter following the [charter template](charter-template.md) that defines its scope, deliverables, timeline, governance, and communication methods. 12 | 13 | The SIG's charter should be submitted as a pull request that will be approved or rejected by the steering committee members. 14 | 15 | {/* 16 | TODO: Add members of the steering committee in an OWNERS.md file and reference here. 17 | assignees: han-so1omon, CyrusVorwald-ICON, donghyun89 18 | */} 19 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/bug-report.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Bug report 3 | about: Create a report to help us improve 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | **Describe the bug** 11 | A clear and concise description of what the bug is. 12 | 13 | **To Reproduce** 14 | Steps to reproduce the behavior: 15 | 1. Go to '...' 16 | 2. Click on '....' 17 | 3. Scroll down to '....' 18 | 4. See error 19 | 20 | **Expected behavior** 21 | A clear and concise description of what you expected to happen. 22 | 23 | **Screenshots** 24 | If applicable, add screenshots to help explain your problem. 25 | 26 | **Desktop (please complete the following information):** 27 | - OS: [e.g. iOS] 28 | - Browser [e.g. chrome, safari] 29 | - Version [e.g. 22] 30 | 31 | **Smartphone (please complete the following information):** 32 | - Device: [e.g. iPhone6] 33 | - OS: [e.g. iOS8.1] 34 | - Browser [e.g. stock browser, safari] 35 | - Version [e.g. 22] 36 | 37 | **Additional context** 38 | Add any other context about the problem here. 39 | -------------------------------------------------------------------------------- /special-interest-groups/contributor-experience/README.md: -------------------------------------------------------------------------------- 1 | 2 | # SIG Contributor Experience 3 | 4 | ## Goals 5 | 6 | Developing and sustaining a healthy community of contributors is critical to scaling the project and growing the ecosystem. We need to ensure our contributors are happy and productive, and that there are not bottlenecks hindering the project in, for example: feature velocity, community scaling, pull request latency, and absolute numbers of open pull requests and open issues. 7 | 8 | ## Meetings 9 | 10 | **Technical Community Update Meeting** 11 | 12 | Update report published first Monday of the quarter 13 | 14 | Technical Community Meeting held the next week on Wednesday at 1715 UTC 15 | 16 | [Hosted here](https://discord.com/channels/880651922682560582/1007680403861164072) 17 | 18 | [Meeting Archives here](https://www.youtube.com/playlist?list=PLV_LTOH3l7ItpWoTljqR_P1_eBSS6js_S) 19 | 20 | ## Projects 21 | 22 | None for this SIG 23 | 24 | ## Contributing 25 | 26 | [CONTRIBUTING.md](../../CONTRIBUTING.md) 27 | 28 | ## Contact 29 | 30 | [ICON Discord #dev_discussion](https://discord.com/channels/880651922682560582/898256107653464095). Requires *Developer* role -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## Intro 2 | 3 | This is the repository for the organization of certain resources for the technical developments of the [ICON Project](https://github.com/icon-project). This repository is in active development. 4 | 5 | ## Structure 6 | 7 | ### Governance 8 | 9 | This section describes ICON's organizational structure. See [the governance document](/GOVERNANCE.md) for more information. 10 | 11 | 12 | ### Guidelines 13 | 14 | This section includes guidelines for assisting collaborators and grantees to understand how to participate in the ICON ecosystem. Guidelines must be followed as specified by grant agreements or other pertinent contracts. This section maintains guidelines for topics including the following: 15 | 16 | - Communication practices 17 | - Technical development practices 18 | 19 | ## Further resources 20 | 21 | - [ICON Community Site](https://icon.community) 22 | - [ICON Community Forum](https://forum.icon.community) 23 | - [ICON Community Discord](https://discord.com/invite/7a75Hf3cFm) 24 | - [ICON Technical Documentations](https://docs.icon.community) 25 | - [ICE/SNOW Community Site](https://icenetwork.io/) 26 | - [ICE/SNOW Technical Documentations](https://docs.icenetwork.io/welcome/introduction) -------------------------------------------------------------------------------- /GOVERNANCE.md: -------------------------------------------------------------------------------- 1 | # Governance 2 | 3 | The ICON blockchain is decentralized and any party is welcome to establish their own governance structure. The ICON Foundation adopts a similar governance structure to other large open source projects, such as [Kubernetes](https://github.com/kubernetes/community) and [W3C](). We officially support the following types of groups: 4 | 5 | ## Committees 6 | 7 | Each committee is appointed by the ICON Foundation to undertake strategic and sensitive topics. Committees should generally adhere to the [transparency guidelines](/guidelines/communication/communication-guidelines.md#transparency), but may communicate in private when necessary. 8 | 9 | ## Special interest groups 10 | 11 | A special interest group (SIG) is a collaborative group of independent parties that openly contribute and share expertise on a specific technology area. 12 | 13 | Check out any of the CONTRIBUTING.md files of existing SIGs in the [special-interest-groups](/special-interest-groups/) folder for more information about how to contribute. 14 | 15 | To learn more about proposing a new SIG, see the [SIG proposal process document](/special-interest-groups/sig-proposal-process.md). 16 | 17 | ### Projects 18 | 19 | Each SIG is comprised of independent but related projects that advance the SIG's goals. -------------------------------------------------------------------------------- /guidelines/technical/release-template.md: -------------------------------------------------------------------------------- 1 | # Release Template 2 | 3 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 4 | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 5 | "OPTIONAL" in this document are to be interpreted as described in 6 | [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). 7 | 8 | Adherence to this template is recommended for any project on ICON, and required for any of the following code changes to ICON infrastructure: 9 | 10 | - New and nontrivial features 11 | - Nontrivial modifications to existing features 12 | - Changes that require coordination among independent parties, such as changes that impact multiple SIGs or multiple SIG projects 13 | 14 | ## Release Checklist 15 | 16 | {/* 17 | TODO: Create a release checklist. 18 | assignees: CyrusVorwald-ICON 19 | */} 20 | 21 | ## Production Readiness Review 22 | 23 | The purpose of a [production readiness review](https://sre.google/sre-book/evolving-sre-engagement-model/#production-readiness-reviews-simple-prr-model-4ksZcY8) is to verify that a major feature addition or modification of a given service meets the accepted documentation, observability, and reliability standards for that service. 24 | 25 | {/* 26 | TODO: Create a production readiness review template. 27 | assignees: CyrusVorwald-ICON 28 | */} 29 | -------------------------------------------------------------------------------- /user-groups/charter-template.md: -------------------------------------------------------------------------------- 1 | # UG #UGNAME Charter 2 | 3 | | Status | (Proposed / Accepted / Rejected / Archived) | 4 | :-------------- |:---------------------------------------------------- | 5 | | **PR Link** | [PR #](https://github.com/icon-project/community/pulls/#) (update when you have PR link)| 6 | | **Author(s)** | My Name (me@example.org), AN Other (you@example.org) | 7 | | **Sponsor** | Steering committee member name (example@icon.foundation) | 8 | | **Updated** | DD MONTH YYYY | 9 | 10 | This charter adheres to the [UG governance guidelines](/guidelines/governance/sig-governance-guidelines.md). 11 | 12 | ## Overview 13 | 14 | Briefly explain to the community why your SIG could matter to them. 15 | 16 | ## Scope 17 | 18 | Briefly describe all technical and non-technical components within the scope of the project. 19 | 20 | ### Out of scope 21 | 22 | Briefly clarify anything that could be considered to be in scope but are not. 23 | 24 | ## Governance 25 | 26 | This UG adheres to the [UG governance guidelines](/guidelines/governance/sig-governance-guidelines.md). Any changes from the guidelines should be noted here. 27 | 28 | ### Roles and Responsibilities 29 | 30 | Briefly describe the roles and responsibilities of various members of the SIG that are not defined in the [SIG governance guidelines](/guidelines/governance/sig-governance-guidelines.md). 31 | -------------------------------------------------------------------------------- /special-interest-groups/charter-template.md: -------------------------------------------------------------------------------- 1 | # SIG #SIGNAME Charter 2 | 3 | | Status | (Proposed / Accepted / Rejected / Archived) | 4 | :-------------- |:---------------------------------------------------- | 5 | | **PR Link** | [PR #](https://github.com/icon-project/community/pulls/#) (update when you have PR link)| 6 | | **Author(s)** | My Name (me@example.org), AN Other (you@example.org) | 7 | | **Sponsor** | Steering committee member name (example@icon.foundation) | 8 | | **Updated** | DD MONTH YYYY | 9 | 10 | This charter adheres to the [SIG governance guidelines](/guidelines/governance/sig-governance-guidelines.md). 11 | 12 | ## Overview 13 | 14 | Briefly explain to the community why your SIG could matter to them. 15 | 16 | ## Scope 17 | 18 | Briefly describe all technical and non-technical components within the scope of the project. 19 | 20 | ### Out of scope 21 | 22 | Briefly clarify anything that could be considered to be in scope but are not. 23 | 24 | ## Governance 25 | 26 | This SIG adheres to the [SIG governance guidelines](/guidelines/governance/sig-governance-guidelines.md). Any changes from the guidelines should be noted here. 27 | 28 | ### Roles and Responsibilities 29 | 30 | Briefly describe the roles and responsibilities of various members of the SIG that are not defined in the [SIG governance guidelines](/guidelines/governance/sig-governance-guidelines.md). 31 | -------------------------------------------------------------------------------- /user-groups/sustainability/meetings/2023-02-27-cps.md: -------------------------------------------------------------------------------- 1 | # CPS Meeting 2023-02-27 2 | 3 | This meeting is hosted by UG Sustainability 4 | 5 | ## Agenda 6 | 7 | #### SIG Charter 8 | 9 | - See [charter](../charter.md) 10 | - Meeting format 11 | - Meetings kept to ~30 min 12 | - Agenda items will be ranked in importance 13 | - Items not addressed will be left for later date 14 | - Frequency 15 | - 1 per quarter / 1 month depending on agendas 16 | 17 | #### Getting Organized 18 | 19 | *Goal: Align the community around a collective mission and vision, with a plan on how to achieve them* 20 | 21 | - Define meeting structure 22 | - Look into other DAO structures to see which ones are efficient and may benefit the community 23 | - Examples include: MakerDAO endgame, ATOM 2.0, Fantom, Gitcoin protocol, Optimism collective 24 | 25 | #### Improving the existing protocol 26 | *Goal: Introduce improvements to the CPS that can make an immediate difference* 27 | 28 | - Smart contracts 29 | - Frontend 30 | - Social structure and community participation 31 | - Other 32 | - Marketing and communications 33 | 34 | #### Exploring larger protocol upgrades 35 | *Goal: Introduce and explore improvements that improve the long-term sustainability of the CPS as a protocol* 36 | 37 | - Time periods versus milestone based funding 38 | - Reputation based identity 39 | - Funding buckets + specialized voting + enclaves/sub-DAOs 40 | - Sponsor accountability 41 | - ICE network support or collaboration 42 | - Anonymized voting 43 | - Treasury Management -------------------------------------------------------------------------------- /VALUES.md: -------------------------------------------------------------------------------- 1 | # ICON Community Values 2 | 3 | ICON's community culture is the cornerstone of ICON's sustainability. These are the core values of ICON's community culture. 4 | 5 | ## Community first 6 | 7 | We place the highest value on [the common methodology of sustainable open source projects.](https://www.theopensourceway.org/the_open_source_way-guidebook-2.0.html) We invite and encourage users to participate and contribute in the ICON community. 8 | 9 | ## Inclusive participation 10 | 11 | Our community respects the time and effort put into a discussion, regardless of where a contributor is on their growth path. Open communication of both new and researched ideas is key to the success of the ICON project. 12 | 13 | ## Decentralized leadership 14 | 15 | The long-term success and sustainability of the ICON project is only possible as an inclusive meritocracy with decentralization of leadership, funding, development, and documentation. 16 | 17 | ## Less toil 18 | 19 | [Chapter 5 of Google's Site Reliability Engineering handbook](https://sre.google/sre-book/eliminating-toil/) defines toil as "the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows." 20 | 21 | In short, things that can be automated ought to be automated. We value the time spent on automation more than the time spent on toil. 22 | 23 | ## Thoughtful engineering 24 | 25 | Taking the time to reduce cruft greatly improves speed of delivery over time. As with all good open source software, the ability for contributors to easily onboard and add value is high impact and high priority. -------------------------------------------------------------------------------- /guidelines/technical/audit-readiness-checklist.md: -------------------------------------------------------------------------------- 1 | # Audit Readiness Checklist 2 | 3 | This checklist provides an overview of the requirements that should be met before commissioning an audit for your project. 4 | 5 | - [ ] **Documentation:** Describe the project's architecture, functionalities, technology stack, and design. 6 | - [ ] Create a state diagram defining every possible system state and state transitions. 7 | - [ ] Create a logical flowchart depicting how data moves, where it goes, and what happens to it at each step. 8 | - [ ] **Internal Code Review:** Conduct an internal review of the project's codebase. 9 | - [ ] Conduct internal threat modeling and assess vulnerability to identify potential security risks. 10 | - [ ] Define the intended behavior of the critical components*, validate that the actual code aligns with the intended behavior, and document any discrepancies and improvements. 11 | - [ ] **Guard Rails:** Implement throttling and temporary halts when predefined metrics exceed their thresholds in accordance with [EIP-7265](https://github.com/ethereum/EIPs/pull/7265). Note that EIP-7265 is subject to change. 12 | - [ ] **Test Coverage:** Implement a minimum of 80% test coverage. 13 | - [ ] **Adherence to [software development guidelines](https://github.com/icon-project/community/blob/main/guidelines/technical/software-development-guidelines.md)** 14 | 15 | \* Critical components include but are limited to: 16 | * exchange of value 17 | * transfer 18 | * transferFrom 19 | * send 20 | * call 21 | * delegatecall 22 | * selfdestruct 23 | * inline assembly code 24 | * access control 25 | * onlyOwner or similar functions 26 | * fallback 27 | * external contract interactions 28 | * state variable operations 29 | -------------------------------------------------------------------------------- /special-interest-groups/infrastructure/meetings/2023-05-09.md: -------------------------------------------------------------------------------- 1 | # Infrastructure SIG Meeting 2023-05-09 2 | 3 | Post meeting -> [Link to recorded meeting]() 4 | 5 | Meeting shall be ~30 min. Items not covered will be left for subsequent meetings. 6 | 7 | ## Agenda 8 | 9 | #### Inclusiveness Statement 10 | 11 | - This SIG abides by the ICON community [code of conduct](../../../guidelines/communication/code-of-conduct.md) and [contributor covenant](https://www.contributor-covenant.org/) 12 | - All members are welcome and encouraged to share ideas / suggestions / feedback 13 | - All ideas / suggestions / feedback will be treated with respect 14 | - Failure to meet above will result in not attending future meetings 15 | 16 | #### SIG Charter 17 | 18 | > 3 Min 19 | 20 | - See [charter](../charter.md) 21 | - Meeting format 22 | - Meetings kept to ~30 min 23 | - Agenda items will be ranked in importance 24 | - Items not addressed will be left for later date 25 | - Frequency 26 | - 1 per quarter / 1 month depending on agendas 27 | - Tracker frontend as a separate SIG or working group 28 | - Not responsible for UI / UX 29 | - Question is where frontend work is managed 30 | - Feedback? 31 | 32 | ### Future Discussions 33 | 34 | > 5 Min 35 | 36 | Quick discussion for topics for next meeting. 37 | 38 | #### Frontend 39 | 40 | - New tracker pages 41 | - Analytics (iBriz + Rhizome) 42 | - Logs / messages with the ABI 43 | - Transaction explorer 44 | - Upgrading the tracker look and feel 45 | 46 | #### Backend 47 | 48 | - Infrastructure redesign 49 | - Moving to new cloud 50 | 51 | #### Tooling 52 | 53 | - Contract code generator 54 | - https://github.com/sudoblockio/tackle-icon-sc-poc 55 | - Contract client generator 56 | - WIP 57 | 58 | ### Wireframes 59 | 60 | > 20 Min 61 | 62 | [Figma Link](https://www.figma.com/file/c5WYNLg0pHFYGnz3msUP6J/ICON-Design-Proposal---Community-Feedback?node-id=0%3A1&t=6lMXuEoLohUQUO23-1) 63 | 64 | - Any feedback welcome 65 | -------------------------------------------------------------------------------- /user-groups/sustainability/analysis/case-study-node-butler.md: -------------------------------------------------------------------------------- 1 | ## Intro 2 | 3 | This is a project analysis of Node Butler by Espanicon 4 | 5 | ## Context 6 | 7 | ``` 8 | Project developer: Espanicon 9 | Project name: Node Butler 10 | Project section (if applicable): n/a 11 | Analysis time period: 2021 12 | Current date: 28 March 2023 13 | Reviewer (Individual or Organization): UG Sustainability 14 | Tagline: Post-development case study 15 | ``` 16 | 17 | This document is intended to be distributed to Espanicon and the CPS voters so that they may consider it during the process of deciding on future developments and future funding 18 | 19 | ## Successes 20 | 21 | | Success | Notes | 22 | | ------- | ----- | 23 | | Functional, well-built, low-budget | Well-executed development. Product built with satisfactory results for reasonable cost | 24 | 25 | ## Failures 26 | 27 | | Failures | Notes | 28 | | ------- | ----- | 29 | | Marketing | Currently in a bit of a standstill status | 30 | | Not well-used | Useful product, but not effectively brought to validators | 31 | 32 | ## Challenges 33 | 34 | | Challenges | Notes | 35 | | ------- | ----- | 36 | | How to connect to more businesses | Inherently useful product, but seems to be struggling to connect to more businesses | 37 | 38 | ## Solutions 39 | 40 | | Solutions | Notes | 41 | | ------- | ----- | 42 | | Better community building and user engagement | Stunted growth may benefit from more effort into community building and user engagement efforts | 43 | 44 | ## Path Forward 45 | 46 | | Path Forward | Notes | 47 | | ------- | ----- | 48 | | Look for communication-based partnerships | Recommend to partner with projects that keep users highly engaged, for example artist / storytelling / media production communities. This can be a useful way to co-market a product | 49 | | Better showcase of product and documentation | Landing page and documentation page in addition to existing open-source code pages would be useful for brand-building and product-showcasing | 50 | 51 | 52 | ## Notes 53 | 54 | [Comparison Study - Karma Finance vs Node Butler](./comparison-karma-finance-vs-node-butler.md) -------------------------------------------------------------------------------- /user-groups/sustainability/README.md: -------------------------------------------------------------------------------- 1 | 2 | # UG Sustainability 3 | 4 | ## Goals 5 | 6 | Establishing and maintaining healthy communication and participation patterns for businesses of all types within the ICON ecosystem is an important part of the process of sustainability and growth. We aim to promote business scales from sole-proprietors to large-scale corporations, as well as domains from artists to infrastructure providers. Examples of this facilitation include: 7 | 8 | - Discussing and documenting monetization strategies 9 | - Providing clear and accessible communication channels for introductions and discussions 10 | - Performing case studies on business practices 11 | - Noting and registering open niches within the ecosystem 12 | - Developing open funding sources, such as the [Contribution Proposal System](cps.icon.community), and providing the blueprints to establish further, derivative funding sources 13 | 14 | This includes collaborations with SIG Contributor Experience for programs such as jobs portals. 15 | 16 | ## Meetings 17 | 18 | CPS Monthly meeting 19 | - Last Monday of the month at 1715 UTC on [ICON Discord](https://discord.gg/b5QvCXJjJM) 20 | 21 | xCall Integration monthly meeting 22 | - Datetime TBD 23 | 24 | ## Projects 25 | 26 | [icon-community/CPS](https://github.com/icon-community/CPS) - Contribution Proposal System for ICON Main Network 27 | 28 | [icon-community/cps_java_contracts](https://github.com/icon-community/cps_java_contracts) - ICON-Java smart contracts for CPS 29 | 30 | [icon-community/integrate-xcall](https://github.com/icon-community/integrate-xcall) - Track and plan the integrations and usage of xCall by developers and users 31 | 32 | ## Contributing 33 | 34 | [CONTRIBUTING.md](../../CONTRIBUTING.md) 35 | 36 | ## Contact 37 | 38 | [ICON Discord #b2b_general](https://discord.com/channels/880651922682560582/1043189484193316977) - Discussions about business to business interactions. Requires *Business* role 39 | 40 | [ICON Discord #ug_sustainability](https://discord.com/channels/880651922682560582/1043189700103516180) - General discussions for the Sustainability User Group. Requires *Business* role -------------------------------------------------------------------------------- /guidelines/contribution/README.md: -------------------------------------------------------------------------------- 1 | # Getting Started 2 | 3 | - [Getting Started](#getting-started) 4 | - [Welcome](#welcome) 5 | - [Roles](#roles) 6 | - [Ambassador](#ambassador) 7 | - [Technical Member](#technical-member) 8 | - [Business Developer](#business-developer) 9 | - [Content Creator](#content-creator) 10 | - [User](#user) 11 | - [Something Else](#something-else) 12 | 13 | ## Welcome 14 | 15 | Participate in the development of an open, decentralized ecosystem! 16 | This guide will help you understand the overall organization of the [ICON ecosystem](https://icon.foundation/), and direct you to the best places to get started contributing. 17 | 18 | ## Roles 19 | 20 | Contributions for open, decentralized, cryptocurrency ecosystems take many varied forms. These roles and corresponding contirbution guides are presented so that someone with a specific domain of interest can take direction and inspiration. However, forms of participation are not limited to these roles. 21 | 22 | ### Ambassador 23 | 24 | #### Joining as an Ambassador 25 | 26 | Raise the issue in the official [ICON Discord Server](https://discord.com/invite/7a75Hf3cFm) in the `#support` channel that you would like to be an Ambassador 27 | 28 | TODO 29 | 30 | ### Technical Member 31 | 32 | #### Setting up your Development Environment 33 | 34 | - For ICON Network development, check through the [Welcome](https://docs.icon.community/) guide on the ICON Network docs, as well as the various `Getting Started` guides 35 | - For ICE/SNOW Network development, check through the [Introduction](https://docs.icenetwork.io/welcome/introduction) guide on the ICE/SNOW Network docs 36 | - Refer to the [Polkadot documentations](https://wiki.polkadot.network/) for further resources 37 | 38 | #### Contributing code 39 | 40 | Look through the issues present in the various projects in the [ICON Project](https://github.com/icon-project) or [ICON Community](https://github.com/icon-community) Github organizations for an issue that you feel motivated to pursue 41 | 42 | TODO 43 | 44 | ### Business Developer 45 | 46 | TODO 47 | 48 | ### Content Creator 49 | 50 | TODO 51 | 52 | ### User 53 | 54 | TODO 55 | 56 | ### Something Else 57 | 58 | TODO -------------------------------------------------------------------------------- /user-groups/sustainability/analysis/comparison-agora-vs-gangstabet.md: -------------------------------------------------------------------------------- 1 | ## Intro 2 | 3 | *Please be sure to listen to each person's perspective when going through this process. The main goal is to work together effectively and create successes for the ecosystem and in general* 4 | 5 | This is a project analysis of Agora by Staky and Gangstabet by Iconosphere. This is a postmortem analysis, which is useful to gain insights into the team performance 6 | 7 | ## Context 8 | 9 | ``` 10 | Analysis time period: 2021-2022 11 | Current date: 28 March 2023 12 | Reviewer (Individual or Organization): UG Sustainability 13 | Tagline: Post-development analysis 14 | ``` 15 | 16 | | Project | Project section (if applicable) | Link | 17 | | ------- | ------- | ------- | 18 | | Agora | n/a | [Agora](https://daos.staky.io/) | 19 | | Gangstabet | n/a | [Gangstabet](https://gangstabet.io/) | 20 | 21 | ## Decision-making process 22 | 23 | ### Weighted Decision Matrix 24 | 25 | A [weighted decision matrix](https://airfocus.com/blog/weighted-decision-matrix-prioritization/) is a form of [payoff matrix](https://mathworld.wolfram.com/PayoffMatrix.html) for determining optimal decision strategies. It comes from ideas in [game theory](https://en.wikipedia.org/wiki/Game_theory) 26 | 27 | 28 | 29 | | Criteria | Criteria Weight | Agora | Gangstabet | 30 | | ----------------------- | --------------- | ------------- | ----------- | 31 | | Impact on the Ecosystem | 5 | 4 | 5 | 32 | | Feasibility | 5 | 5 | 5 | 33 | | Cost | 5 | 5 | 3 | 34 | | Timeframe | 3 | 5 | 5 | 35 | | Innovation | 2 | 4 | 3 | 36 | | Total Score | \--- | 93 | 86 | 37 | 38 | --- 39 | **From this process, we see that Agora is more valuable, then Gangstabet. The total possible score is 100. By heuristically stating that any project over 65 has value, both projects are shown to have value** 40 | 41 | ## Notes 42 | 43 | [Case Study - Agora](./case-study-agora.md) 44 | 45 | [Case Study - Gangstabet](./case-study-gangstabet.md) -------------------------------------------------------------------------------- /user-groups/sustainability/analysis/comparison-karma-finance-vs-node-butler.md: -------------------------------------------------------------------------------- 1 | ## Intro 2 | 3 | *Please be sure to listen to each person's perspective when going through this process. The main goal is to work together effectively and create successes for the ecosystem and in general* 4 | 5 | This is a project analysis of Karma Finance by Protokol 7 and Node Butler by Espanicon. This is a postmortem analysis, which is useful to gain insights into the team performance 6 | 7 | ## Context 8 | 9 | ``` 10 | Analysis time period: 2021-2022 11 | Current date: 28 March 2023 12 | Reviewer (Individual or Organization): UG Sustainability 13 | Tagline: Post-development analysis 14 | ``` 15 | 16 | | Project | Project section (if applicable) | Link | 17 | | ------- | ------- | ------- | 18 | | Karma Finance | n/a | [Karma Finance](https://www.karmafinance.org/) | 19 | | Node Butler | n/a | [Node Butler](https://github.com/Espanicon/node-butler-frontend) | 20 | 21 | ## Decision-making process 22 | 23 | ### Weighted Decision Matrix 24 | 25 | A [weighted decision matrix](https://airfocus.com/blog/weighted-decision-matrix-prioritization/) is a form of [payoff matrix](https://mathworld.wolfram.com/PayoffMatrix.html) for determining optimal decision strategies. It comes from ideas in [game theory](https://en.wikipedia.org/wiki/Game_theory) 26 | 27 | 28 | 29 | | Criteria | Criteria Weight | Karma Finance | Node Butler | 30 | | ----------------------- | --------------- | ------------- | ----------- | 31 | | Impact on the Ecosystem | 5 | 5 | 2 | 32 | | Feasibility | 5 | 4 | 3 | 33 | | Cost | 5 | 4 | 5 | 34 | | Timeframe | 3 | 4 | 5 | 35 | | Innovation | 2 | 5 | 3 | 36 | | Total Score | \--- | 87 | 71 | 37 | 38 | --- 39 | **From this process, we see that Karma Finance is the most valuable, then Node Butler. The total possible score is 100. By heuristically stating that any project over 65 has value, both projects are shown to have value** 40 | 41 | ## Notes 42 | 43 | [Case Study - Karma Finance](./case-study-karma-finance.md) 44 | 45 | [Case Study - Node Butler](./case-study-node-butler.md) -------------------------------------------------------------------------------- /user-groups/sustainability/analysis/case-study-gangstabet.md: -------------------------------------------------------------------------------- 1 | ## Intro 2 | 3 | This is a project analysis of Gangstabet by ICONosphere 4 | 5 | ## Context 6 | 7 | ``` 8 | Project developer: ICONosphere 9 | Project name: Gangstabet 10 | Project section (if applicable): n/a 11 | Analysis time period: April - July 2021 12 | Current date: 01 May 2023 13 | Reviewer (Individual or Organization): UG Sustainability 14 | Tagline: Post-development case study 15 | ``` 16 | 17 | This document is intended to be distributed to ICONosphere and the CPS voters so that they may consider it during the process of deciding on future developments and future funding 18 | 19 | ## Successes 20 | 21 | | Success | Notes | 22 | | ------- | ----- | 23 | | Successfully built product | Target was NFT collection in ICON ecosystem. Gangstabet is now a well-known and respected NFT project in the ICON ecosystem | 24 | 25 | ## Failures 26 | 27 | | Failures | Notes | 28 | | ------- | ----- | 29 | | Community development and collaboration | By no means a failure, as the community has been consistent. However, from the perspective of creating partnerships based around the Gangstabet brand, there is room for improvement. It would be good to see more NFTs used as profile pictures or brand assets from other groups | 30 | 31 | ## Challenges 32 | 33 | | Challenges | Notes | 34 | | ------- | ----- | 35 | | How to create better collaborations | The project maintains its status in the ICON ecosystem with solid development and delivery. What are the ways that the project can grow into more than an isolated game? | 36 | 37 | ## Solutions 38 | 39 | | Solutions | Notes | 40 | | ------- | ----- | 41 | | Marketing and community management | Users and collaborating organizations may like to see more engagement from personalities involved with the Gangstabet project. People like to follow the stories of involved parties so that they can feel as if they are growing together | 42 | 43 | 44 | ## Path Forward 45 | 46 | | Path Forward | Notes | 47 | | ------- | ----- | 48 | | Look for someone to do interpersonal community management | This exists in some ways through the Discord, but there is not as much engagement as there could be. Working with a community manager that keeps the story going and keeps everyone engaged to promote each other's endeavors is a great way to create a more useful and enjoyable product | 49 | 50 | ## Notes 51 | 52 | [Comparison Study - Agora vs Gangstabet](./comparison-agora-vs-gangstabet.md) -------------------------------------------------------------------------------- /user-groups/sustainability/analysis/case-study-agora.md: -------------------------------------------------------------------------------- 1 | ## Intro 2 | 3 | This is a project analysis of Agora by Staky 4 | 5 | ## Context 6 | 7 | ``` 8 | Project developer: Staky 9 | Project name: Agora 10 | Project section (if applicable): n/a 11 | Analysis time period: June - October 2022 12 | Current date: 01 May 2023 13 | Reviewer (Individual or Organization): UG Sustainability 14 | Tagline: Post-development case study 15 | ``` 16 | 17 | This document is intended to be distributed to Staky and the CPS voters so that they may consider it during the process of deciding on future developments and future funding 18 | 19 | ## Successes 20 | 21 | | Success | Notes | 22 | | ------- | ----- | 23 | | Successfully built product | Target was DAOs in ICON community. Currently in-use by popular teams in ICON ecosystem, including Balanced, Craft, and Gangstabet. Also planned to be used by other projects, including by Protokol 7 projects | 24 | 25 | ## Failures 26 | 27 | | Failures | Notes | 28 | | ------- | ----- | 29 | | Ease of use | Ideally, new DAOs would be deployable with a single click. Currently, it still requires manual intervention. Additionally, documentation could be improved to minimize direct interaction with the development team | 30 | 31 | ## Challenges 32 | 33 | | Challenges | Notes | 34 | | ------- | ----- | 35 | | How to connect to more businesses | Useful product, but limited reach currently. This is in part due to low marketing and the relatively small ICON ecosystem | 36 | | Sustainable revenue | Currently team is not making any (little to none) money from this product | 37 | 38 | ## Solutions 39 | 40 | | Solutions | Notes | 41 | | ------- | ----- | 42 | | More marketing | This product is pretty easily marketable to organizations outside of the existing ICON ecosystem. It should be developed and marketed as such | 43 | | Establish cross-chain product | Creating an efficient cross-chain system for DAO infrastructure would be helpful to the overall web3 ecosystem | 44 | 45 | 46 | ## Path Forward 47 | 48 | | Path Forward | Notes | 49 | | ------- | ----- | 50 | | Market and develop outside of direct ICON ecosystem | Recommend to establish more partnerships and marketing outside of the direct ICON ecosystem. This product is applicable for general DAO infrastructure and should be treated as such. The biggest roadblock is that it is not yet cross-chain | 51 | 52 | ## Notes 53 | 54 | [Comparison Study - Agora vs Gangstabet](./comparison-agora-vs-gangstabet.md) -------------------------------------------------------------------------------- /user-groups/sustainability/analysis/case-study-karma-finance.md: -------------------------------------------------------------------------------- 1 | ## Intro 2 | 3 | This is a project analysis of Karma Finance by Protokol 7 4 | 5 | ## Context 6 | 7 | ``` 8 | Project developer: Protokol 7 9 | Project name: Karma Finance 10 | Project section (if applicable): n/a 11 | Analysis time period: 2021 12 | Current date: 28 March 2023 13 | Reviewer (Individual or Organization): UG Sustainability 14 | Tagline: Post-development case study 15 | ``` 16 | 17 | This document is intended to be distributed to Protokol 7 and the CPS voters so that they may consider it during the process of deciding on future developments and future funding 18 | 19 | ## Successes 20 | 21 | | Success | Notes | 22 | | ------- | ----- | 23 | | Successfully built product | Target was Icon DeFi and NFT(fi) protocols (OMM, Balanced, Optimus, Craft, Inanis Invictus, ..). Successfully provided bonds for OMM, Inanis Invictus and Balanced | 24 | 25 | ## Failures 26 | 27 | | Failures | Notes | 28 | | ------- | ----- | 29 | | Marketing | Currently in stand still because of active development of Convexus and resourcefully connected Equality project as well as revision plan making where sustainable business model is being created for Karma Bond | 30 | | Late delivery | Took an extra month or so for delivery. On-time delivery is always preferable | 31 | 32 | ## Challenges 33 | 34 | | Challenges | Notes | 35 | | ------- | ----- | 36 | | How to connect to more businesses | 100% dependency on the will of other protocols (bond providers). Protocols seeking to raise their own POL without using Karma Bond in order to avoid paying fees for the service (e.g. Balanced is going to deploy their own bond rather than using Karma Bond) | 37 | | Sustainable revenue | Currently team is not making any (little to none) money | 38 | 39 | ## Solutions 40 | 41 | | Solutions | Notes | 42 | | ------- | ----- | 43 | | Better community building and user engagement | Stunted growth may benefit from more effort into community building and user engagement efforts | 44 | | Fewer dependencies on business customers | Provide products and services for users without external dependency on the will of other protocols. From a high level, must establish sustainable income revenue flows which will cover the costs of development, marketing, management and further growth of the product | 45 | 46 | 47 | ## Path Forward 48 | 49 | | Path Forward | Notes | 50 | | ------- | ----- | 51 | | Look for communication-based partnerships | Recommend to partner with projects that keep users highly engaged, for example artist / storytelling / media production communities. This can be a useful way to co-market a product | 52 | 53 | ## Notes 54 | 55 | [Comparison Study - Karma Finance vs Node Butler](./comparison-karma-finance-vs-node-butler.md) -------------------------------------------------------------------------------- /guidelines/governance/sig-governance-guidelines.md: -------------------------------------------------------------------------------- 1 | # SIG Governance Guidelines 2 | 3 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 4 | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 5 | "OPTIONAL" in this document are to be interpreted as described in 6 | [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). 7 | 8 | ## Introduction 9 | 10 | The purpose of this document is to describe special interest group (SIG) best practices and guidelines. SIG contributors MUST adhere to these guidelines where applicable. 11 | 12 | ### Development 13 | 14 | - SIGs MUST develop software in accordance with the [software development guidelines](/guidelines/software/software-development-guidelines.md). 15 | - SIG contributors SHOULD participate in relevant project release planning meetings at least once per quarter. 16 | - SIG contributors are responsible for the health of project code bases. 17 | 18 | ### Communications 19 | 20 | - All SIGs MUST openly and transparently communicate in accordance with the [communications guidelines](/guidelines/communication/communication-guidelines.md). 21 | - SIG contributors MUST meet at least once a month and post recorded meeting notes to the SIG's folder in the community repo. 22 | - SIG contributors can optionally record meetings and make them publicly available on the ICON Community YouTube playlist. 23 | - SIG contributors MUST use public communications channels specified in the SIG charter. Private communications SHOULD be avoided unless necessary. 24 | - All SIGs MUST provide roadmap or status updates to the community at least once a quarter. 25 | - All publicly available meetings SHOULD have their agenda posted at least 24 hours before the meeting start time. 26 | 27 | ## Leadership roles 28 | 29 | ### Chair 30 | 31 | The chair MUST do the following: 32 | 33 | - Define and set SIG priorities 34 | - Drive SIG direction 35 | - Organize and facilitate meetings 36 | - Own CONTRIBUTING.md file and contributor onboarding experience 37 | - Provide monthly community updates 38 | - Ensure that the SIG adheres to technical and communication best practices and guidelines 39 | - Coordinate multi-party and cross-functional communications 40 | 41 | ### Technical lead 42 | 43 | The technical lead MUST do the following: 44 | 45 | - Triage issues 46 | - Optimize software development lifecycle, process, and workflow 47 | 48 | ## Project management 49 | 50 | Each SIG project MUST define the rationale, methodology, and public observability for 51 | 52 | - how priorities are determined, staffed, managed, and accepted. 53 | - how target release dates are determined 54 | - how releases are published 55 | 56 | ## Archiving decomissioned SIGs 57 | 58 | - SIGs that shut down MUST be archived in the [archives](/archives) folder. 59 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | ## Introduction 4 | 5 | The purpose of this document is to familiarize users with how they can get involved with the ICON project, become contributors, and advance their contributor membership. 6 | 7 | ## Becoming a contributor 8 | 9 | The ICON project welcomes and appreciates your interest in contributing. This section will walk you through step-by-step how to make your first contribution. 10 | 11 | In order to contribute, you will need to [create a GitHub account](http://github.com/signup). 12 | 13 | Please familiarize yourself with the [Code of Conduct](/CODE_OF_CONDUCT.md) and [ICON Community Values](/VALUES.md). 14 | 15 | ## Ways of contributing 16 | 17 | There are many ways of contributing to the ICON project. All contributors from beginner to expert are welcome to openly share their ideas and contributions. 18 | 19 | ### Code 20 | 21 | {/* 22 | TODO: Create a description and page on code contributions. 23 | assignees: CyrusVorwald-ICON 24 | */} 25 | 26 | ### Documentation 27 | 28 | Writing documentation 29 | 30 | {/* 31 | TODO: Create a description and page on documentation contributions. 32 | assignees: CyrusVorwald-ICON 33 | */} 34 | 35 | ### Issue triaging 36 | 37 | Issue triaging involves organizing, prioritizing, categorizing, and labeling a project's backlog of issues and pull requests. Regularly triaging increases engagement, transparency, and productivity. 38 | 39 | {/* 40 | TODO: Create a page on issue triaging. 41 | assignees: CyrusVorwald-ICON 42 | */} 43 | 44 | ### Repository management 45 | 46 | {/* 47 | TODO: Create a page on repository management. 48 | assignees: CyrusVorwald-ICON 49 | */} 50 | 51 | ### Community support 52 | 53 | {/* 54 | TODO: Create a page on community support. 55 | assignees: CyrusVorwald-ICON 56 | */} 57 | 58 | ### Event management 59 | 60 | {/* 61 | TODO: Create a page on community events. 62 | assignees: CyrusVorwald-ICON 63 | */} 64 | 65 | ### Running a validator node 66 | 67 | {/* 68 | TODO: Create a page on validator nodes. (may be out of scope) 69 | assignees: CyrusVorwald-ICON 70 | */} 71 | 72 | ## Funding pathways 73 | 74 | ### Volunteering 75 | 76 | As an open source project, volunteer efforts are always welcome. We strive to foster the community in such a way that newcomers can easily grow into contributors and spin off their own projects. The best way to get started is volunteering in any of the [ways of contributing](#ways-of-contributing). 77 | 78 | ### Community grants 79 | 80 | {/* 81 | TODO: Create a description and page on the CPS. 82 | assignees: tjhunt1 83 | */} 84 | 85 | ### ICON Foundation grants 86 | 87 | {/* 88 | TODO: Create a description and page on ICON Foundation grants. 89 | assignees: CyrusVorwald-ICON 90 | */} 91 | -------------------------------------------------------------------------------- /user-groups/sustainability/meetings/2023-04-24-cps.md: -------------------------------------------------------------------------------- 1 | # CPS Meeting 2023-04-24 2 | 3 | This meeting is hosted by UG Sustainability 4 | 5 | ## Agenda 6 | 7 | ### SIG Charter 8 | 9 | - See [charter](../charter.md) 10 | - Meeting format 11 | - Meetings kept to ~30 min 12 | - Agenda items will be ranked in importance 13 | - Items not addressed will be left for later date 14 | - Frequency 15 | - 1 per month depending on agendas 16 | 17 | ### Project Analysis 18 | 19 | *Goal: Analyze 2-3 projects per months for better understanding of performance and expectations* 20 | 21 | - [Single-project analysis template](https://github.com/icon-project/grants-program/blob/main/templates/yymmdd-single-project-analysis.md) 22 | - [Project options analysis template](https://github.com/icon-project/grants-program/blob/main/templates/yymmdd-project-options-analysis.md) 23 | 24 | **Projects for this month** 25 | 26 | - [Agora](https://cps.icon.community/proposals/bafybeied3bp5i44aiyyma4jt4rd2auf2uf74cao7hs45qeus7adxclbamm) 27 | - [Gangstabet](https://cps.icon.community/proposals/bafybeiaubhdzignnbe24ypwwulsr6fxju4uyujzx5tnyqc6fgop3qbyldu) 28 | 29 | ### Protocol upgrades and discussions 30 | 31 | *Goal: Introduce improvements to the CPS that can make an immediate difference. Also form a longer-term plan for improvements that are important, but more complex or not immediately high priority* 32 | 33 | **Upcoming CPS developments** 34 | 35 | *As of now, this is still in review, but is what is planned* 36 | 37 | - Payout based on delivery of milestones 38 | - Variables tunable by governance 39 | - Frontend upgrades 40 | 41 | **Committee-based vs validator-based decision-making** 42 | 43 | *This would not be implemented immediately, but once we sufficiently discuss an implementation plan can be created* 44 | 45 | - Should CPS governance change to be committee-based instead of validator-based or something else. This is a high priority to discuss 46 | 47 | **CPS-funded project code ownership and accountability** 48 | 49 | *Last time, we mostly seemed to agree that full, required code-ownership is not beneficial. However, maybe there's some medium* 50 | 51 | - Should code be owned by CPS in some cases? Currently some projects leave after being funded, and there's nothing to show even if it were delivered 52 | - Note that exclusivity agreements may not be competitive 53 | - Open-source is a good medium, and maybe worth looking to generate more interest in open-source deliverables for continued, decentralized development 54 | 55 | **Revenue return** 56 | 57 | *This is a longer-term idea that would mostly be relevant if there were a larger funding pool or a venture-arm of the CPS* 58 | 59 | - If there were KYC agreements for funding, it may be good to have revenue percentages go back to the CPS if the project is reaches certain amount of success 60 | - Long-off goal, but worth noting -------------------------------------------------------------------------------- /guidelines/technical/readme-template.md: -------------------------------------------------------------------------------- 1 | 2 | [![License][license-badge]][license-url] 3 | [![OpenSSF Scorecard][openssf-scorecard-badge]](https://api.securityscorecards.dev/projects/github.com/icon-project/icon-bridge) 4 | 5 | # Project title 6 | 7 | Briefly describe what your project does. 8 | 9 | 10 |
11 | Table of Contents 12 |
    13 |
  1. 14 | Features 15 | 18 |
    2. 19 |
  2. 20 | Getting started 21 | 25 |
    3. 26 |
  3. Usage
    4. 27 |
  4. Contributing
    5. 28 |
  5. License
    6. 29 |
30 |
31 | 32 | ## Features 33 | 34 | * List project features here 35 | 36 | #### Out of scope 37 | 38 | Optional section. Briefly clarify anything that could be considered to be in scope but are not. 39 | If this section is removed, please also be sure to remove it from the table of contents. 40 | 41 | ## Getting Started 42 | 43 | Simple and easy instructions on setting up your project locally. 44 | 45 | ### Prerequisites 46 | 47 | List software prerequisites here in the format of the example below. 48 | 49 | * docker 50 | ```sh 51 | brew install docker 52 | ``` 53 | 54 | ### Installation 55 | 56 | List installation steps in the format of the example below. 57 | 58 | 1. Clone the repo 59 | ```sh 60 | git clone https://github.com/icon-project/REPO-NAME.git 61 | ``` 62 | 2. Install project dependencies 63 | ```sh 64 | yarn install 65 | ``` 66 | 67 | ## Usage 68 | 69 | Examples of how the project is intended to be used. 70 | 71 | _For more examples, please refer to the [documentation][docs]._ 72 | 73 | ## Contributing 74 | 75 | If you want to contribute, be sure to review the [contributing guidelines][contributing]. 76 | 77 | We use GitHub Issues for tracking requests and bugs, and Github Discussions for general questions and discussion. 78 | 79 | The ICON project strives to abide by generally accepted best practices in open-source software development. 80 | 81 | ## License 82 | 83 | Distributed under the PROJECT-LICENSE License. See [LICENSE][license-url] for more information. 84 | 85 | [license-badge]: https://img.shields.io/github/license/icon-project/REPO-NAME.svg 86 | [license-url]: ./LICENSE 87 | [openssf-scorecard-badge]: https://api.securityscorecards.dev/projects/github.com/icon-project/REPO-NAME/badge 88 | [docs]: ./docs 89 | [contributing]: ./CONTRIBUTING.md 90 | [report-bug]: https://github.com/icon-project/REPO-NAME/issues/new?assignees=&labels=&template=bug.md&title= 91 | [request-feature]: https://github.com/icon-project/REPO-NAME/issues/new?assignees=&labels=&template=feature.md&title= 92 | -------------------------------------------------------------------------------- /special-interest-groups/interoperability/charter.md: -------------------------------------------------------------------------------- 1 | # SIG Interoperability Charter 2 | 3 | | Status | (Accepted) | 4 | :-------------- |:---------------------------------------------------- | 5 | | **PR Link** | [PR 43](https://github.com/icon-project/community/pull/43)| 6 | | **Author(s)** | Cyrus Vorwald (cyrus@icon.foundation) | 7 | | **Sponsor** | Cyrus Vorwald (cyrus@icon.foundation) | 8 | | **Updated** | 08 August 2022 | 9 | 10 | This charter adheres to the [SIG governance guidelines](/guidelines/governance/sig-governance-guidelines.md). 11 | 12 | ## Overview 13 | 14 | We contribute to cross-chain message transfer and communication services through technical development and advocacy. 15 | 16 | ## Scope 17 | 18 | ### Guidance and technical expertise of ICON based interoperability solutions 19 | 20 | We assist projects and companies looking to build cross-chain services and integrations. 21 | 22 | ### Standardized frameworks and best practices 23 | 24 | We standardize and modularize integrations with the ICON Bridge where applicable. These ongoing and completed efforts include 25 | 26 | - Merged code bases 27 | - [Generalized multi-chain build framework architecture and implementation](https://github.com/icon-project/icon-bridge/discussions/192) 28 | - [Generalized multi-chain functional test framework architecture](https://github.com/icon-project/icon-bridge/discussions/134) 29 | - [Generalized multi-chain end-to-end test framework architecture and implementation](https://github.com/icon-project/icon-bridge/discussions/141) 30 | 31 | We plan to optimize and share the entire continuous delivery pipeline in such a way that any integrating project can quickly onboard. These future plans include: 32 | 33 | - Generalized multi-chain functional test framework implementation 34 | - Reference specification and implementation of the ICON Bridge project 35 | - Generalized multi-chain mock test framework architecture and implementation 36 | - Easy configurations change (ie. new environment, artifcat) 37 | - Generalized mult-chain deployment architecture and implementation. Deployed releases should have minimal downtime in any configured environment 38 | - Standardized chain integration roadmap and quality gates. Any new chain integration to BTP should follow the same steps where applicable. 39 | - Manual release checklist and production release readiness review template 40 | - Generalized multi-chain logging and monitoring framework 41 | - Standardized rollback procedures 42 | 43 | ### Out of scope 44 | 45 | This special interest group currently does not include efforts of the Blockchain Transmission Protocol (BTP). 46 | 47 | ## Governance 48 | 49 | This SIG adheres to the [SIG governance guidelines](/guidelines/governance/sig-governance-guidelines.md). Any changes from the guidelines should be noted here. 50 | 51 | ## Contacts 52 | 53 | SIG chair & technical lead: [Cyrus Vorwald](https://github.com/CyrusVorwald-ICON) 54 | 55 | ## Projects 56 | 57 | - [ICON Bridge](https://github.com/icon-project/icon-bridge) 58 | - Project lead: [Cyrus Vorwald](https://github.com/CyrusVorwald-ICON) 59 | - [Nexus](https://github.com/icon-project/Nexus) 60 | - Project lead: [Cyrus Vorwald](https://github.com/CyrusVorwald-ICON) 61 | -------------------------------------------------------------------------------- /user-groups/sustainability/meetings/2023-03-27-cps.md: -------------------------------------------------------------------------------- 1 | # CPS Meeting 2023-03-27 2 | 3 | This meeting is hosted by UG Sustainability 4 | 5 | ## Agenda 6 | 7 | ### SIG Charter 8 | 9 | - See [charter](../charter.md) 10 | - Meeting format 11 | - Meetings kept to ~30 min 12 | - Agenda items will be ranked in importance 13 | - Items not addressed will be left for later date 14 | - Frequency 15 | - 1 per month depending on agendas 16 | 17 | ### Project Analysis 18 | 19 | *Goal: Analyze 2-3 projects per months for better understanding of performance and expectations* 20 | 21 | - [Single-project analysis template](https://github.com/icon-project/grants-program/blob/main/templates/yymmdd-single-project-analysis.md) 22 | - [Project options analysis template](https://github.com/icon-project/grants-program/blob/main/templates/yymmdd-project-options-analysis.md) 23 | 24 | **Projects for this month** 25 | 26 | - TBD... 27 | 28 | ### Protocol upgrade proposals 29 | *Goal: Introduce improvements to the CPS that can make an immediate difference* 30 | 31 | **Mandatory progress report sections** 32 | 33 | *The main purpose of a mandatory progress report section is to increase accountability of project teams, better be able to predict future behavior of development teams, and better be able to plan for future voting decisions of CPS voters* 34 | 35 | - 'Deliverables Accomplished This Cycle' should be necessary to show that work was accomplished or not so that the community can understand the state of the project 36 | - 'Projected for next cycle' should be necessary to let the community know what to expect from the project team during the next cycle. This aids with planning for related projects and aids understanding about whether the team was able to accomplish the stated milestones in the stated timeframe 37 | 38 | **Payment per milestone** 39 | 40 | *The main purpose of payment per milestone is to increase accountability of project teams and incentivize follow-through on projects* 41 | 42 | - Majority or total payment on delivery. Possibility for small percentage up-front 43 | - Validation of delivery decided by CPS voters 44 | 45 | **Domain-specific funding buckets** 46 | 47 | *The main purpose of domain-specific funding buckets is to give attention to important aspects of ecosystem development that deserve more focused funding* 48 | 49 | - Bucket categories: 'open technology' (15%, 6 month accumulation), 'media' (15% 4 month accumulation), 'general' (70% 1 month accumulation as before) 50 | - The idea of the given percentages is to ensure that the majority functionality of the CPS is the same as before. However, we can now test out giving domain-specific projects more focused attention as a way to manage ecosystem growth per domain 51 | - The idea of the given accumulation periods is to ensure that there is enough funding for open technology and marketing projects, given the size of the projects that we expect to be proposed 52 | - Open technology projects may be viable for longer contracts and more substantial development teams as we project at this time, so they have an accumulation period of 15%, which over 6 months yields approximately 95% of the full monthly CPS budget 53 | - Media projects may be viable for shorter term contracts, such as running a single event or producing a series of smaller marketing endeavors. Over 4 months, this bucket yields approximately 40% of the full monthly CPS budget 54 | - Teams may look to utilize all funding buckets, but should note that their proposals should be judged accordingly and should be cautioned against complex forms of funding coordination reliant on multiple proposals passing -------------------------------------------------------------------------------- /guidelines/communication/bug-bounty.md: -------------------------------------------------------------------------------- 1 | ## Program Overview 2 | The Bug Bounty Program is to find vulnerabilities in the ICON network. The greater the risk of the vulnerabilities, the greater the reward will be sent to those who discover the vulnerabilities. This will lead whitehats to report them to ICON, instead of taking advantage of the bug. It will start with ICON Mainnet and will expand to other applications. 3 | Bug reporters can register bug reports in Immunefi 4 | https://immunefi.com/bounty/icon/ 5 | 6 | ## Rewards by Threat Level 7 | Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.2, focusing on the impact of the vulnerability reported. 8 | 9 | All High and Critical Blockchain/DLT and Smart Contract bug reports require a Proof of Concept (PoC) to be eligible for a reward. Explanations and statements are not accepted as PoC and code is required. 10 | 11 | ICON requires KYC to be done for all bug bounty hunters submitting a report and wanting a reward. If the entity is an individual, the information needed are Name, Address, Nationality, Birthday, copy of ID card, copy of residence certificate, criminal records and personal relations with politicians. If the entity is a company, business start date, address, country the business base on, copy of business certificate. And some information about people who have over 20% of the company's share. The collection of this information will be done by the ICON project team. 12 | 13 | Payouts are handled by the ICON team directly and are denominated in USD. However, payouts are done in ICX. If the reporter disagree with the KYC requirement or you are denied by the KYC process, payouts cannot be done. 14 | 15 | Blockchain/DLT 16 | 17 | | Severity | Payout | PoC | 18 | | --------- | -------------- | ----- | 19 | |Critical | USD $100,000 | PoC Required | 20 | |High |USD $25,000 | PoC Required | 21 | |Medium |USD $5,000 | | 22 | |Low |USD $1,000 | | 23 | 24 | 25 | 26 | ## Impacts in scope 27 | Only the following impacts are accepted within this bug bounty program. All other impacts are not considered as in-scope, even if they affect something in the assets in scope table. 28 | 29 | Blockchain/DLT 30 | | Critical | 31 | | -------- | 32 | |Network not being able to confirm new transactions (Total network shutdown)| 33 | |Unintended permanent chain split requiring hard fork (Network partition requiring hard fork) | 34 | |Direct loss of funds | 35 | |Permanent freezing of funds (fix requires hardfork) | 36 | |RPC API crash | 37 | |Arbitrary transaction affecting ICON ledger | 38 | |Change block data which is already finalised | 39 | |Arbitrary smart contract (Score) call, updating or deleting Score without permission | 40 | |Inconsistent data in partitioned blockchain | 41 | 42 | 43 | 44 | | High | 45 | | -------- | 46 | |Unintended chain split (Network partition) | 47 | |Transient consensus failures | 48 | |Disability to make a new block(no consensus working) | 49 | |Newly created block never comes to the finality | 50 | 51 | 52 | 53 | | Medium | 54 | | -------- | 55 | |High compute consumption by validator/mining nodes | 56 | |Attacks against thin clients | 57 | |DoS of greater than 30% of validator or miner nodes and does not shut down the network | 58 | |Attacking single node to shut down | 59 | |Stopping a node from working properly | 60 | 61 | 62 | 63 | | Low | 64 | | -------- | 65 | |DoS of greater than 10% but less than 30% of validator or miner nodes and does not shut down the network | 66 | |Underpricing transaction fees relative to computation time | 67 | |Trivial minor bugs except the one related to consensus, safety, liveness, consistency | 68 | 69 | 70 | 71 | -------------------------------------------------------------------------------- /special-interest-groups/infrastructure/charter.md: -------------------------------------------------------------------------------- 1 | # SIG Infrastructure and Indexing Charter 2 | 3 | | Status | (Accepted) | 4 | :-------------- |:----------------------------------------------------| 5 | | **PR Link** | [](https://github.com/icon-project/community/pull/) | 6 | | **Author(s)** | Rob Cannon (rob@sudoblock.io) | 7 | | **Sponsor** | Cyrus Vorwald (cyrus@icon.foundation) | 8 | | **Updated** | 19 December 2022 | 9 | 10 | This charter adheres to the [SIG governance guidelines](/guidelines/governance/sig-governance-guidelines.md). 11 | 12 | ## Overview 13 | 14 | The Infrastructure and Indexing SIG is in charge of maintaining critical infrastructure for supporting the network including public RPC nodes and developing the community tracker. 15 | 16 | ## Scope 17 | 18 | Specific planning items are laid out in the [icon-tracker](https://github.com/sudoblockio/icon-tracker/tree/main/planning) repo with the following serving as the broad scope of the SIG. 19 | 20 | ### Infrastructure 21 | 22 | The SIG oversees the community's public RPC endpoints which are running in at: 23 | 24 | - https://api.icon.community/ 25 | - https://api.sejong.icon.community/ 26 | - https://api.lisbon.icon.community/ 27 | - https://api.berlin.icon.community/ 28 | 29 | These endpoints are running on optimized hardware and are instrumented with observability tooling to ensure high reliability. The SIG will outline and implement any changes to these endpoints in an effort to keep costs as low as possible and uptime as high as possible. It is also overseeing the open sourcing of the infrastructure stack so that users are able to contribute to the stack along with running their own API endpoints. 30 | 31 | ### Indexing 32 | 33 | The SIG oversees the community trackers which are running in at: 34 | 35 | - https://tracker.icon.community/ 36 | - https://tracker.sejong.icon.community/ 37 | - https://tracker.lisbon.icon.community/ 38 | - https://tracker.berlin.icon.community/ 39 | 40 | These trackers are running in 2 regions with both dev and prod environments allowing developers to push changes to the appropriate cluster and see changes before they are ultimately pushed up into production. This SIG oversees these environments along with coordinating long term changes to the tracker. These improvements will be done by various teams across the community with this SIG serving as the planning point for implementing these changes. 41 | 42 | ## Governance 43 | 44 | This SIG adheres to the [SIG governance guidelines](/guidelines/governance/sig-governance-guidelines.md). 45 | 46 | Regular meetings will be planned on a monthly / quarterly basis to engage with the community for planning / feedback purposes. Meeting agendas will be made public and can be contributed to via PR in the [meetings](meetings) directory. Announcements for actual meeting dates / times will be made on [twitter](https://twitter.com/sudoblockio), Discord, and the [ICON Community Forum](https://forum.icon.community/). 47 | 48 | ## Contacts 49 | 50 | SIG chair & technical lead: [Rob Cannon](https://github.com/robcxyz) 51 | 52 | Tracker discussions take place on a private discord channel. To gain access to the channel, please raise a support ticket in the [official ICON discord support channel](https://discord.gg/umYWjqz8mF). 53 | 54 | ## Projects 55 | 56 | - [icon-tracker](https://github.com/sudoblockio/icon-tracker) 57 | - All associated repos are linked to from that repo in the [planning section](https://github.com/sudoblockio/icon-tracker/tree/main/planning) 58 | - Production infrastructure as code is private 59 | - Docker compose version of the tracker can be used for development and local deployments 60 | - ICON Community Endpoints 61 | - Production infrastructure as code is private 62 | -------------------------------------------------------------------------------- /special-interest-groups/docs/charter.md: -------------------------------------------------------------------------------- 1 | # SIG Docs Charter 2 | 3 | | Status | (Proposed) | 4 | :-------------- |:---------------------------------------------------- | 5 | | **PR Link** | [PR 62](https://github.com/icon-project/community/pull/62)| 6 | | **Author(s)** | Eric Solomon (eric@icon.foundation) | 7 | | **Sponsor** | Eric Solomon (eric@icon.foundation) | 8 | | **Updated** | 22 December 2022 | 9 | 10 | This charter adheres to the [SIG governance guidelines](/guidelines/governance/sig-governance-guidelines.md). 11 | 12 | ## Overview 13 | 14 | Responsibility for creating feature documentation belongs to the developers and SIGs creating each feature. This includes task-driven documentation for the feature itself and conceptual documentation about the feature. 15 | 16 | ## Scope 17 | 18 | SIG Docs publishes ICON project documentation on docs.icon.community. ICON project documentation includes: 19 | 20 | - Documentation of the core ICON blockchain, including economic and technical specifications 21 | - Core ICON APIs 22 | - ICON execution environment tools, including for compilation and testing 23 | 24 | Responsibility for creating feature documentation belongs to the developers and SIGs creating each feature. This includes task-driven documentation for the feature itself and conceptual documentation about the feature. 25 | 26 | SIG Docs sets standards for feature documentation, provides clear paths for docs contribution, and coordinates documentation updates during quarterly releases. 27 | 28 | SIG Docs creates subprojects as needed to handle specific aspects of ICON project documentation. 29 | 30 | ### In scope 31 | 32 | #### Code, Binaries and Services 33 | 34 | The docs.icon.community website, which includes: 35 | 36 | - Site content and documentation 37 | - Content style guides and their application to feature documentation and release notes 38 | - Processes for launching feature content and release notes during releases 39 | - Reference documentation for: 40 | - The core ICON blockchain, including economic and technical specifications 41 | - The core ICON APIs, including core derivative SDKs 42 | - The core ICON execution environment tools, including for compilation and testing 43 | 44 | #### Cross-cutting and Externally Facing Processes 45 | 46 | - Standards for content: style guide, contributor guide, PR reviews SIG Docs is not responsible for branding any content related to the ICON project organization. We are sometimes informally invited to consult on branding and design decisions, but we have no formal responsibility for such work. 47 | - Coordinating docs contributions for releases 48 | - Other project documentation: SIG Docs is sometimes advises on ICON project components outside of the icon-project Github organization, the icon-community Github organization, or on other ICON subprojects, but is not responsible for the documentation of any of these components or projects 49 | 50 | ### Out of scope 51 | 52 | - SIG Docs is not responsible for creating new feature documentation 53 | - SIG Docs reviews and coordinates feature documentation created by community members 54 | - SIG Docs sets standards for content creation, in the form of a style guide; offers feedback and review of new feature documentation; offers advice about information architecture for new features in the docs; and otherwise provides guidance and oversight to make sure that new feature documentation is maximally helpful to developers. 55 | - Branding, logos, or brand style guides for the ICON project 56 | 57 | 58 | ## Governance 59 | 60 | This SIG adheres to the [SIG governance guidelines](/guidelines/governance/sig-governance-guidelines.md). Any changes from the guidelines should be noted here. 61 | 62 | ## Contacts 63 | 64 | SIG chair: [Eric Solomon](https://github.com/han-so1omon), [Cyrus Vorwald](https://github.com/CyrusVorwald) 65 | Technical lead: [Eric Solomon](https://github.com/han-so1omon) 66 | 67 | ## Projects 68 | 69 | - [devportal] - Developer docs for ICON network. Found at https://docs.icon.community 70 | -------------------------------------------------------------------------------- /special-interest-groups/security/charter.md: -------------------------------------------------------------------------------- 1 | # SIG Security Charter 2 | 3 | | Status | (Proposed) | 4 | :-------------- |:---------------------------------------------------- | 5 | | **PR Link** | [PR 56](https://github.com/icon-project/community/pull/56)| 6 | | **Author(s)** | Eric Solomon (eric@icon.foundation) | 7 | | **Sponsor** | Eric Solomon (eric@icon.foundation) | 8 | | **Updated** | 14 September 2022 | 9 | 10 | This charter adheres to the [SIG governance guidelines](/guidelines/governance/sig-governance-guidelines.md). 11 | 12 | ## Overview 13 | 14 | This group covers horizontal security initiatives for the ICON ecosystem projects, including security audits, vulnerability management, security documentation, and community management on endeavors related to security. 15 | 16 | ## Scope 17 | 18 | ### Security Audits 19 | 20 | Manage recurring security audits and follow up on issues. Coordinate vendors to perform the audit and publish the findings. Follow up on issues with the affected SIG and help coordinate resolution, which can include: 21 | 22 | - Helping to prioritize the fixes, possibly by recruiting from SIG Security (while acknowledging that the ultimate authority in deciding whether and how to fix an issue lies with the responsible SIG). 23 | - Documenting mitigations, workarounds, or caveats, especially when the responsible SIG decides not to fix a reported issue. 24 | 25 | ### Vulnerability Management 26 | 27 | Work with the ICON Security Response Committee to define the processes for fixing and disclosing vulnerabilities, as outlined in https://github.com/icon-project/. For example: 28 | 29 | - When the private fix & release process is invoked 30 | - How vulnerabilities are rated 31 | - The scope of the bug bounty 32 | - Post-announcement follow-ups, such as additional fixes, mitigations, preventions or documentation after a vulnerability is made public 33 | - Distributor announcement policies, such as timelines, criteria for joining the list, etc 34 | - How, when and where vulnerabilities are announced 35 | - Defining the criteria and process for supporting ICON sub-ecosystems, such as the BTP, ICON main network, or ICE/SNOW 36 | 37 | ### Security Documentation 38 | 39 | Author and maintain security documentation, such as hardening guides and security benchmarks. Seek out and coordinate with experts in other SIGs for input on the documentation (i.e. we go to them, they don't need to come to us). In-scope documentation includes: 40 | 41 | - Hardening guides and best practices 42 | - Security benchmarks 43 | - Improving documentation to address common misunderstandings or questions 44 | - Threat models 45 | 46 | ### Community management on endeavors related to security 47 | 48 | Provide an entry point to the ICON community for new security-minded contributors and participants, as well as a meeting point to discuss security themes and issues within the ICON ecosystem, including: 49 | 50 | - Work with SIG Contributor Experience to curate and staff security discussion channels (e.g. discord channel, mailing list, discourse, stack overflow, etc.). 51 | - Answer security questions from inexperienced users (that don't know what SIG to go to), and identify common questions or issues as areas for improvement. 52 | - Provide an "entry point" for new contributors interested in security. Route these new contributors to other SIGs when they have more specific goals (e.g. SIG Interoperability for cross-chain messaging). 53 | 54 | ### Out of scope 55 | 56 | SIG Security does not own any code from the ICON ecosystem projects 57 | 58 | Further, SIG Security’s scope does not include: 59 | 60 | - Any projects outside of the ICON ecosystem projects 61 | - Cloud provider-specific or distributor-specific hardening guides 62 | - Recommendations or endorsements of specific commercial product vendors or cloud providers 63 | - Private vulnerability response (belongs to the Security Response Committee), including: 64 | - Embargoed vulnerability management 65 | - Bug bounty submission triage and management 66 | - Non-public vulnerability collection, triage, and disclosure 67 | 68 | ## Governance 69 | 70 | This SIG adheres to the [SIG governance guidelines](/guidelines/governance/sig-governance-guidelines.md). Any changes from the guidelines should be noted here. 71 | 72 | ## Contacts 73 | 74 | SIG chair & technical lead: [Eric Solomon](https://github.com/han-so1omon) 75 | 76 | ## Projects 77 | 78 | None defined for this SIG 79 | -------------------------------------------------------------------------------- /guidelines/communication/communication-guidelines.md: -------------------------------------------------------------------------------- 1 | # Communication Guidelines 2 | 3 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 4 | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 5 | "OPTIONAL" in this document are to be interpreted as described in 6 | [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). 7 | 8 | ## Introduction 9 | 10 | The purpose of this document is to describe best practices for communicating among project participants. We expect developers to adhere to these guidelines where applicable. 11 | 12 | ## README.md 13 | 14 | All projects should include a README.md file that clearly and succinctly describes what the project is and how it is used. A visitor to the project should immediately be able to figure out 15 | 16 | - what the project is 17 | - who developed the project 18 | - how to build the project, including supported development environments 19 | - how to use the project 20 | - supported features 21 | - how to contribute, linking to a CONTRIBUTING.md file 22 | 23 | ### README badges 24 | 25 | The README.md file should have information about the status of the project's code base. We recommend using badges to display this information. https://shields.io is a good place to generate badges from. Recommended badges include: 26 | 27 | - code coverage 28 | - continuous integration build status 29 | - license SPDX identifier 30 | - code quality report ie. OpenSSF scorecard and best practices 31 | 32 | ## CONTRIBUTING.md 33 | 34 | All projects should include a CONTRIBUTING.md file that specifies how a prospective contributor may get involved with the project. We recommend providing information about the following: 35 | 36 | - Contributing code 37 | - Contributing documentation 38 | - Requesting features 39 | - Reporting bugs 40 | - Reviewing pull requests 41 | - Participating in discussions 42 | 43 | ## Code contributor onboarding 44 | 45 | All projects should have good first issues labeled so that prospective code contributors can onboard smoothly. We also recommend identifying in the documentation good entry points for stepping through the code base, such as specifying newcomer-friendly unit tests. 46 | 47 | ## Transparency 48 | 49 | All projects should be unambiguously clear that they are open source. All projects should transparently and openly communicate development status as much as possible. Visitors should quickly know what the reality of the project's status is, how actively it is maintained, how often it puts out new releases, and how responsive it is to bug reports. 50 | 51 | Developers should not inflate or hype the development status or misrepresent the project features. Open source projects set their own community expectations. Project owners should understand that conservatively managing expectation is always better for software and community health than risking not delivering on expectations. It's perfectly acceptable to state something along the lines of: 52 | 53 | "This project is in alpha stage and is not representative of the final stage. Things may or may not work. We have a list of known bugs here \ and are still developing the project. We encourage users to raise issues and contribute by following our contributing guidelines at \." 54 | 55 | Marketing should be mindful of its impact on the development community. Marketing should refrain from misleading project delivery dates, strengths, weaknesses, and attacking competitors. 56 | 57 | ## Handling security vulnerabilities 58 | 59 | Security vulnerabilities should immediately be reported to the security response committee at [security@icon.foundation](mailto:security@icon.foundation). For more information about the security response committee and escalation process, check out their info [here](/committees/security-response-committee/SECURITY.md). 60 | 61 | Unlike regular communications, security vulnerabilities should be discussed privately and handled silently to avoid alerting potentially malicious parties. 62 | 63 | As demonstrated by [the Solana Wormhole exploit](https://research.kudelskisecurity.com/2022/02/03/quick-analysis-of-the-wormhole-attack/), even committing a fix announces the vulnerability's existence to the world. **The public should only be made aware of the security vulnerability after the fix is deployed to production.** 64 | 65 | The formal announcement of the vulnerability should go out at the same time that the fix is released to the public. 66 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | CONTRIBUTOR COVENANT CODE OF CONDUCT 2 | Our Pledge 3 | 4 | We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. 5 | 6 | We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community. 7 | Our Standards 8 | 9 | Examples of behaviour that contributes to a positive environment for our community include: 10 | 11 | Demonstrating empathy and kindness toward other people 12 | Being respectful of differing opinions, viewpoints, and experiences 13 | Giving and gracefully accepting constructive feedback 14 | Accepting responsibility and apologising to those affected by our mistakes, and learning from the experience 15 | Focusing on what is best not just for us as individuals, but for the overall community 16 | 17 | Examples of unacceptable behaviour include: 18 | 19 | The use of sexualized language or imagery, and sexual attention or advances of any kind 20 | Trolling, insulting or derogatory comments, and personal or political attacks 21 | Public or private harassment 22 | Publishing others’ private information, such as a physical or email address, without their explicit permission 23 | Other conduct which could reasonably be considered inappropriate in a professional setting 24 | 25 | Enforcement Responsibilities 26 | 27 | Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. 28 | 29 | Community leaders 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, and will communicate reasons for moderation decisions when appropriate. 30 | Scope 31 | 32 | This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. 33 | Enforcement 34 | 35 | Instances of abusive, harassing, or otherwise unacceptable behaviour may be reported to the community leaders responsible for enforcement @moderators . All complaints will be reviewed and investigated promptly and fairly. 36 | 37 | All community leaders are obligated to respect the privacy and security of the reporter of any incident. 38 | Enforcement Guidelines 39 | 40 | Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct: 41 | 1. Correction 42 | 43 | Community Impact : Use of inappropriate language or other behaviour deemed unprofessional or unwelcome in the community. 44 | 45 | Consequence : A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behaviour was inappropriate. A public apology may be requested. 46 | 2. Warning 47 | 48 | Community Impact : A violation through a single incident or series of actions. 49 | 50 | Consequence : A warning with consequences for continued behaviour. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban. 51 | 3. Temporary Ban 52 | 53 | Community Impact : A serious violation of community standards, including sustained inappropriate behaviour. 54 | 55 | Consequence : A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban. 56 | 4. Permanent Ban 57 | 58 | Community Impact : Demonstrating a pattern of violation of community standards, including sustained inappropriate behaviour, harassment of an individual, or aggression toward or disparagement of classes of individuals. 59 | 60 | Consequence : A permanent ban from any sort of public interaction within the community. 61 | Attribution 62 | 63 | This Code of Conduct is adapted from the Contributor Covenant , version 2.0, available at Contributor Covenant: . 64 | 65 | Community Impact Guidelines were inspired by Mozilla’s code of conduct enforcement ladder and Manjaro’s forum rules. 66 | 67 | For answers to common questions about this code of conduct, see the FAQ at Contributor Covenant: Frequently Asked Questions about Contributor Covenant . Translations are available at Contributor Covenant: Contributor Covenant Translations . -------------------------------------------------------------------------------- /guidelines/technical/software-architecture-design-guidelines.md: -------------------------------------------------------------------------------- 1 | # Sofware Architecture Design Guidelines 2 | 3 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 4 | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 5 | "OPTIONAL" in this document are to be interpreted as described in 6 | [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). 7 | 8 | ## Introduction 9 | 10 | The purpose of this document is to describe software architecture design and decision making best practices and guidelines. 11 | We expect developers to adhere to these guidelines where applicable. 12 | 13 | ## What is software architecture? 14 | 15 | We define software architecture as the important decisions to be made regarding how and why a body of code is implemented. 16 | 17 | ## What is the purpose of a software architecture design document? 18 | 19 | The purpose of a software architecture design document is to explicitly declare why a body of code works in the way it does. 20 | This provides a baseline to align all stakeholders in understanding the internal workings of how the software works, what was considered, 21 | and what important decisions were made. It also prevents multiple teams from independently building out the same features. 22 | 23 | ## When is a software architecture design document needed? 24 | 25 | A software architecture design document is needed any time there involves coordination across teams for a feature or body of code, either now or in the future. 26 | If you are fixing a bug or making minor changes, you do not need a design document. 27 | 28 | ## What should be in a software architecture design document? 29 | 30 | The following subsections should all be declared in a software architecture design document. We provide a template document at [software-architecture-design-template.md](software-architecture-design-template.md). 31 | 32 | ### Introduction 33 | 34 | The introduction should include the purpose and overview for this technical design. It should detail the problem and the reason for proposing a solution. 35 | This problem description should be centered on the user perspective. The problem description should be understandable to the layman. 36 | The introduction should be 1-2 paragraphs, and should contain minimal technical terms. 37 | 38 | ### Terminology 39 | 40 | All variables and unclear technical terms used should be defined in this section. Please note that you do not need to pre-emptively list every 41 | technical term in this section. However, as you fill out this document, evaluate which terms may be unclear and add them to this section with a 42 | brief definition. Additionally, a collaborator on this document may add terms to this list if they find that it may benefit viewers of the document. 43 | The terminology list should include acronyms as well as technical words or phrases. 44 | 45 | ### Considerations 46 | 47 | The considerations should include the assumptions that are made, and the constraints that are faced. There may be multiple different considerations. 48 | Considerations can include technical topics, user-experience topics, or other topics that the collaborators of this document view as pertinent to 49 | understanding the design selection process. 50 | 51 | ### Designs 52 | 53 | The designs section should contain proposed solutions. There may be one or more proposed solutions. Each proposed solution should have its own design, 54 | defined in bold font. It should be clear which design was selected to move forward with implementation. 55 | 56 | The steps of the proposed solution should be laid out in full sentences and should cover all major logically likely outcomes, including corner cases. If the proposed solution’s flow branches, all cases should be clearly defined and stepped through. The steps of the proposed solution should also be written as pseudocode where applicable. 57 | 58 | ### Diagrams 59 | 60 | Each proposed solution should have an associated architecture diagram. We recommend going through the [C4 model checklist](https://c4model.com/review/) when creating a diagram. 61 | 62 | We do not specify diagram tooling or notation preferences, as that is left to the architect. However, in accordance with the [C4 model](https://c4model.com/#CoreDiagrams), we do require that diagrams follow a common set of abstractions. 63 | 64 | ### Comparisons 65 | 66 | Comparisons should be made between the designs laid out in the “Designs” section. Comparisons should be formatted in a table with the 67 | appropriate major design aspects represented by table columns. 68 | 69 | ### Discussions 70 | 71 | Discussions are artifacts of the clarifying design points that should be left for other contributors, advisors, or general viewers to 72 | gain context into the decision-making process. Discussions should take place on a Github Discussions topic. It is preferable to have one 73 | Github Discussions topic per Architecture Design document, but there may be additional side-topics if something specific is to be 74 | discussed and it would be simpler to understand in its own topic. 75 | 76 | ## When should a software architecture design document be an ICON Improvement Proposal? 77 | 78 | If the body of code impacts the core ICON blockchain, or the ICON developer community, it should be formatted and submitted as an 79 | [ICON Improvement Proposal](https://github.com/icon-project/IIPs). 80 | -------------------------------------------------------------------------------- /user-groups/sustainability/charter.md: -------------------------------------------------------------------------------- 1 | # UG Sustainability Charter 2 | 3 | | Status | (Proposed) | 4 | :-------------- |:---------------------------------------------------- | 5 | | **PR Link** | [PR 63](https://github.com/icon-project/community/pull/63)| 6 | | **Author(s)** | Eric Solomon (eric@icon.foundation) | 7 | | **Sponsor** | Eric Solomon (eric@icon.foundation) | 8 | | **Updated** | 04 November 2022 | 9 | 10 | This charter adheres to the [SIG governance guidelines](/guidelines/governance/sig-governance-guidelines.md). 11 | 12 | ## Overview 13 | 14 | Establishing and maintaining healthy communication and participation patterns for businesses of all types within the ICON ecosystem is an important part of the process of sustainability and growth. We aim to promote business scales from sole-proprietors to large-scale corporations, as well as domains from artists to infrastructure providers. Examples of this facilitation include: 15 | 16 | - Discussing and documenting monetization strategies 17 | - Providing clear and accessible communication channels for introductions and discussions 18 | - Performing case studies on business practices 19 | - Noting and registering open niches within the ecosystem 20 | - Developing open funding sources, such as the [Contribution Proposal System](cps.icon.community), and providing the blueprints to establish further, derivative funding sources 21 | 22 | This includes collaborations with SIG Contributor Experience for programs such as jobs portals. 23 | 24 | ## Scope 25 | 26 | The Sustainability User Group (UG) is responsible for improving the experience of those who want to participate in a sustainable way in the ICON ecosystem. We do this by creating and maintaining programs and processes that promote monetarily and socially sustainable participation practices, while retiring those programs and processes that don't. Being conscientious of the feasibility of sustainable participation within our ecosystem is critical to scaling the project, growing the ecosystem, and helping the project succeed. 27 | 28 | We aim to promote both competition and collaboration. We recognize that there are benefits to both idealogical approaches, with the base principle to be held that open communication is to everybody's benefit. 29 | 30 | ### In scope 31 | 32 | #### Monetization Strategies 33 | 34 | - Discuss and establish strategies for product and service monetization 35 | - Document boilerplate strategies with write-ups that are up-to-date with the modern ecosystem and referenceable by all companies in their business strategy cycle 36 | - Facilitate connections for revenue flow between organizations in the ecosystem 37 | 38 | #### Ecosystem Niches Registry 39 | 40 | - Track & document state of niches in the ICON ecosystem, as they relate to useful service offerings and typical niches for the modern web3 industry 41 | - Facilitate the filling of available ecosystem niches 42 | - Support the competitive and collaborative processes to grow the strength of documented ecosystem niches 43 | 44 | #### Case Studies on Business Practices 45 | 46 | - Organize group-led case studies on business practices for organizations in the ecosystem 47 | - Share successes and failures of ecosystem projects for the purpose of learning and creating robust, sustainable projects 48 | 49 | #### Open Funding Sources 50 | 51 | - Organize and collaborate on the development of open funding sources within the ICON ecosystem 52 | - Including [CPS] development 53 | - Collaborate to decide upon purpose and function of open funding sources 54 | - Provide template structure for open funding sources, including smart contracts, frontend, and backend code as appropriate 55 | 56 | ### Out of scope 57 | 58 | - Business development strategies internal to an organization 59 | - Deciding which businesses are fit or unfit to participate in the ICON ecosystem 60 | - Onboarding contributors to projects within the [icon-project Github Organization](github.com/icon-project) 61 | - Establishing best practices for software development for software products managed by this User Group, such as [CPS](https://github.com/icon-community/CPS) 62 | 63 | ## Governance 64 | 65 | This SIG adheres to the [SIG governance guidelines](/guidelines/governance/sig-governance-guidelines.md). Any changes from the guidelines should be noted here. 66 | 67 | ## Contacts 68 | 69 | UG chair & technical lead: [Eric Solomon](https://github.com/han-so1omon) 70 | 71 | ## Projects 72 | 73 | [icon-community/CPS](https://github.com/icon-community/CPS) - Contribution Proposal System for ICON Main Network 74 | 75 | [icon-community/cps_java_contracts](https://github.com/icon-community/cps_java_contracts) - ICON-Java smart contracts for CPS 76 | 77 | [icon-community/integrate-xcall](https://github.com/icon-community/integrate-xcall) - Track and plan the integrations and usage of xCall by developers and users 78 | 79 | [CPS]: (https://github.com/icon-community/cps) 80 | 81 | ## Contributing Organizations 82 | 83 | *Partial list of organizations that contribute to the ICON Sustainability User Group* 84 | 85 | - [Espanicon](http://espanicon.team/) 86 | - [Hugobyte](https://hugobyte.com) 87 | - [Lydia Labs](https://lydialabs.xyz/) 88 | - [Protokol 7](https://protokol7.com/) 89 | - [Venture23](https://ibriz.ai/) 90 | - [Ingenierias Lentas](https://github.com/ingenierias-lentas) 91 | - [with ICONists](https://github.com/with-ICONists/pillars/wiki) -------------------------------------------------------------------------------- /special-interest-groups/contributor-experience/meetings/q2-2023-technical-community-update.md: -------------------------------------------------------------------------------- 1 | # Technical Community Update Meeting Q2 2023 2 | 3 | This meeting is hosted by SIG Contributor Experience on Wednesday, April 12 at 1715 UTC in the ICON Discord server 4 | 5 | ## Agenda 6 | 7 | ### SIG Charter 8 | 9 | - See [charter](../charter.md) 10 | - Meeting format 11 | - Meetings kept to ~45 min 12 | - Agenda items will be ranked in importance 13 | - Items not addressed will be left for later date 14 | - Frequency 15 | - 1 per quarter 16 | 17 | ### Purpose 18 | 19 | To support the growing technical community on ICON, we are publishing “ICON Technical Community Reports” on a quarterly basis. These reports are designed to inform ICON’s technical community about the ideological focus, milestones, specific goals, and planned timelines for a given time period. In this update, we will discuss milestones and goals for Q2 2023. Let’s dive in! 20 | 21 | ### Specs 22 | 23 | #### Dates 24 | 25 | April 1, 2023 - June 30, 2023 26 | 27 | #### Focus 28 | 29 | During this time period, our main focus will be on utilizing in-place collaboration mechanisms to expand on the utility and adoption of existing or forthcoming interoperability tools. Much of this will be done through the Sustainability User Group, and the various Special Interest Groups. 30 | 31 | ### Prior milestones 32 | 33 | - Ongoing: Create technical tutorials and templates 34 | - Ongoing Reorganize BTP specifications 35 | - Completed: Integrate CPS development with UG Sustainability 36 | - Ongoing: Increase knowledge of ICON-Java Execution Environment 37 | - Ongoing: Increase knowledge of ICON Consensus Environment 38 | - Ongoing: Organize in-person meetups 39 | 40 | ### Goals 41 | 42 | *We are keeping the same high level goals for this quarter, as they have proven to be useful beacons towards sustainable and forward-moving technical developments for the icon technical community* 43 | 44 | #### Create technical tutorials and templates 45 | 46 | In the last quarter, we have added Fidel Sanchez-Bueno, also known as [Espanicon](https://github.com/Espanicon) as a contractor working in support of the ICON Foundation Developer Relations team. With his help, we have improved information on [running a local network](https://docs.icon.community/getting-started/how-to-run-a-local-network), [working with accounts](https://docs.icon.community/getting-started/how-to-create-a-wallet-account) and [debugging nodes](https://docs.icon.community/support/advanced-topics/validator-nodes/how-to-check-if-a-validator-is-missing-blocks), as well as added some of those to the [tutorials section](https://icon.community/tutorials/) of the icon.community site. More to come about BTP relays, smart contracts, etc. 47 | 48 | #### Reorganize BTP specifications 49 | 50 | This will take some time, as the BTP implementation is taking priority. However, we continue to work with the primary BTP developers, Parameta (fka ICONLOOP), in order to create this specification set 51 | 52 | #### Integrate CPS development with UG Sustainability 53 | 54 | As with last time, efforts are being made to further decentralize the process that guides the decisions made with respect to the development roadmap. Code developments will continue to largely be made by Venture23 (fka iBriz). This is being integrated into the now-operational Sustainability User Group and is being tracked via that group and the CPS project. You can also participate in community discussions about this on the [ICON Community Forum](https://forum.icon.community/), on [Twitter](https://twitter.com/iconcps/), or on [Discord](https://discord.com/channels/880651922682560582/1043189700103516180) 55 | 56 | We have begun the monthly CPS meetings, run by UG Sustainability. Meeting notes are archived in the [icon-project/community repository](https://github.com/icon-project/community/tree/main/user-groups/sustainability/meetings). Meeting recordings are archived in the ICON Network Youtube in the [ICON Community Group](https://www.youtube.com/watch?v=PYT6COdQVYA&list=PLV_LTOH3l7ItM7IA8MEdmrNgUGsKxk9T9) playlist 57 | 58 | #### Increase knowledge of ICON-Java Execution Environment 59 | 60 | This will take time as well, as it is a big undertaking. We are working with the primary developers of this execution environment, Parameta, to understand more. Additionally, we are working on better user-level tutorials for the ICON-Java environment so that we can encourage more development in that environment, which brings along new security-based development practices, more debugging, more tooling and libraries, and more general user feedback. This is expected to be facilitated through a new Special Interest Group called SIG Execution Environment 61 | 62 | #### Increase knowledge of ICON Consensus Environment 63 | 64 | Again, this will take time. We are working with the primary developers of this execution environment, Parameta, to understand more. This is expected to be facilitated through a new Special Interest Group called SIG Core Blockchain 65 | 66 | #### Organize in-persion meetups 67 | 68 | We have begun in-person community meetups through the [Web3 Partners](https://web3partners.community/) endeavor, launched by [Eric Solomon](https://github.com/han-so1omon/). Web3 Partners communities are localized business development and collaboration-based education communities. As the goal of the ICON project is to bridge many web3 and general decentralized technology communities together, these communities are not limited to ICON-based project development and education. However, the ICON community is taking the initiative to bootstrap and co-organize in these communities to promote themselves, their projects, and the ICON ecosystem in the larger decentralized technology landscape. So far, there are active communities in Delft/Rotterdam/the Hague, Netherlands and in Bogota, Colombia. There are a few more global communities in development. Shout out to the community members collaborating on this -------------------------------------------------------------------------------- /guidelines/technical/software-architecture-design-template.md: -------------------------------------------------------------------------------- 1 | # Software Architecture Design Template 2 | 3 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 4 | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 5 | "OPTIONAL" in this document are to be interpreted as described in 6 | [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). 7 | 8 | ## Introduction 9 | 10 | The introduction should include the purpose and overview for this technical design. It should detail the problem and the reason for proposing a solution. This problem description should be centered on the user perspective. The problem description should be understandable to the layman. 11 | 12 | Introduction should be 1-2 paragraphs, and should contain minimal technical terms. 13 | 14 | ### Introduction example: 15 | 16 | This document describes design options for a protocol that allows for arbitrary cross-chain transactions. Developers looking to build a distributed application increasingly want to integrate their products with other aspects of the blockchain ecosystem. Users benefit from this, as it simplifies their process of interacting with multiple blockchain technologies. 17 | 18 | Here, we present two design options for such a protocol. We propose the name to be “Cross-chain Transfer Protocol” (CTP). 19 | 20 | ## Terminology 21 | All variables and unclear technical terms used should be defined in this section. Please note that you do not need to pre-emptively 22 | list every technical term in this section. However, as you fill out this document, evaluate which terms may be unclear and add them to 23 | this section with a brief definition. Additionally, a collaborator on this document may add terms to this list if they find that it may 24 | benefit viewers of the document. The terminology list should include acronyms, mathematical symbols, and technical words or phrases. 25 | 26 | ### Terminology example: 27 | 28 | | Term | Definition | 29 | | ----------- | ----------- | 30 | | CTP | Cross-chain Transfer Protocol | 31 | | Message center | Smart contract for aggregating messages and scheduling them for delivery between blockchains | 32 | | $R_{x \rightarrow y}$ | Unidirectional relay that transfers messages from blockchain X to blockchain Y | 33 | | $B_k$ | Block header at height $k$ | 34 | 35 | ## Considerations 36 | 37 | The considerations should include the assumptions that are made, and the constraints that are faced. There may be multiple different considerations. Considerations can include technical topics, user-experience topics, or other topics that the collaborators of this document view as pertinent to understanding the design selection process. 38 | 39 | ### Considerations example: 40 | 41 | #### Relay 42 | 43 | The relay delivers messages between blockchains. It is essential to the cross-chain transfer process. In this case it is important to consider the balance between responsibilities of the user and the abilities of the user to reliably execute complex actions. The two main considerations here are that the user should be the relay or that there should be a third party that manages a relay service. 44 | 45 | #### Fee 46 | 47 | In each step of the CTP process there are different services provided, some of which have implicit fees charged by the blockchain, and others that do not have implicit fees but may require explicitly defined fees to incentivize efficient operation. 48 | 49 | An example of an implicit fee would be a transaction that occurs on the blockchain. Most blockchains charge some fee to process a transaction. 50 | 51 | An example of a fee that may be explicitly defined would be a message delivery fee. Currently, there is no predefined cost for a relay to send a message from one blockchain to another. However, it should be considered whether a fee should be defined to incentivize the user or a third-party relay to operate efficiently with respect to time, robustness, and reliability. 52 | 53 | ## Designs 54 | 55 | This section should contain proposed solutions. Each proposed solution should have its own design, defined in bold font. The steps of the proposed solution should be laid out in full sentences and should cover all major logically likely outcomes, including corner cases. If the proposed solution’s flow branches, all cases should be clearly defined and stepped through. The steps of the proposed solution should also be written as pseudocode when applicable. 56 | 57 | ### Designs example: 58 | 59 | #### Cross-Chain Transfer Protocol Design A 60 | 61 | Caller performs a cross-chain transaction to transfer amount from source blockchain to sink blockchain . Relay updates the state of blockchain on blockchain in smart contract representing a light node... 62 | ##### Pseudocode of the cross-chain transfer protocol Design A 63 | 64 | ```python 65 | def cross_chain_transfer_protocol(routes, from_address, to_address, amount): 66 | lock(from_address, amount) 67 | mint(routes, to_address, amount) 68 | … 69 | ``` 70 | 71 | ##### Cross-Chain Transfer Protocol System Context Diagram 72 | 73 | 74 | ##### Cross-Chain Transfer Protocol Container Diagram 75 | 76 | 77 | ##### Cross-Chain Transfer Protocol Component Diagram 78 | 79 | 80 | ## Comparisons 81 | 82 | Comparisons should be made between the designs laid out in the “Designs” section. Comparisons should be formatted in a table with the appropriate major design aspects represented by table columns. 83 | 84 | ### Comparisons example: 85 | 86 | | Item | Design A | Design B | 87 | | ----------- | ----------- | ----------- | 88 | | Scalability | Medium
- Reliance on Relay | Good | 89 | | Flexibility | Poor
- Rigid connections | Good | 90 | 91 | ## Discussions 92 | 93 | Discussions are artifacts of the clarifying design points that should be left for other contributors, advisors, or general viewers to 94 | gain context into the decision-making process. Discussions should take place on a Github Discussions topic. It is preferable to have one 95 | Github Discussions topic per Technical Design Options document, but there may be additional side-topics if something specific is to be 96 | discussed and it would be simpler to understand in its own topic. It is likely that certain editing or commenting parties will not 97 | fully understand all of the technical designs presented in a Technical Design Options document. Please edit this document to present 98 | a clearer understanding of the technical aspects of the design during the discussion process. 99 | -------------------------------------------------------------------------------- /special-interest-groups/contributor-experience/charter.md: -------------------------------------------------------------------------------- 1 | # SIG Contributor Experience Charter 2 | 3 | | Status | (Proposed) | 4 | :-------------- |:---------------------------------------------------- | 5 | | **PR Link** | [PR 62](https://github.com/icon-project/community/pull/62)| 6 | | **Author(s)** | Eric Solomon (eric@icon.foundation) | 7 | | **Sponsor** | Eric Solomon (eric@icon.foundation) | 8 | | **Updated** | 18 October 2022 | 9 | 10 | This charter adheres to the [SIG governance guidelines](/guidelines/governance/sig-governance-guidelines.md). 11 | 12 | ## Overview 13 | 14 | Developing and sustaining a healthy community of contributors is critical to scaling the project and growing the ecosystem. We need to ensure our contributors are happy and productive, and that there are not bottlenecks hindering the project in, for example: feature velocity, community scaling, pull request latency, and absolute numbers of open pull requests and open issues. 15 | 16 | ## Scope 17 | The [Contributor Experience Special Interest Group](./) (SIG) is responsible for improving the experience of those who contribute to the ICON ecosystem. We do this by creating, and maintaining programs and processes that promote community health and reduce project friction, while retiring those programs and processes that don't. Being conscientious of our contributor base is critical to scaling the project, growing the ecosystem, and helping the project succeed. 18 | 19 | We do this by listening - whether it’s through our community events to SIG meetings, surveys, data, or [GitHub issues], we take in the feedback and turn it into our [project list]. We build a welcoming and inclusive community of contributors by giving them places to be heard and productive. 20 | 21 | ### In scope 22 | 23 | #### Code, Binaries and Services 24 | 25 | - Establish policies, standards and procedures for the use, moderation, and management of all public platforms officially used by the project, as related to the contributor community, including but not limited to: 26 | - [forum.icon.community](https://forum.icon.community) 27 | - [Discord](https://discord.com/invite/7a75Hf3cFm) 28 | - [Youtube channel](https://www.youtube.com/channel/UCI7Z_1sTKN-kCVgFD2a0GXQ) 29 | - [Github](https://github.com/icon-project) 30 | - Establish and staff teams responsible for the administration and moderation of these platforms 31 | - Teams must be staffed by trusted contributors spanning time zones, see moderation for more detail 32 | - They are authorized to take immediate action when dealing with code of conduct issues 33 | - They are expected to escalate to the project's code of conduct committee when issues rise above the level of simple moderation 34 | - Work with other SIGs and interested parties in the project to execute GitHub tasks where required 35 | - Own and execute events that are targeted to the Kubernetes contributor community, including: 36 | - ICON community meetings, including in-person and virtual 37 | - Cryptocurrency industry conferences 38 | - Retrospective moderation for other SIGs upon request 39 | - Other events, like other SIG face to face events, upon request and consideration 40 | - Strategize, build, and execute on scalable mentoring programs for all contributor levels. These may include: 41 | - Meet Our Contributors 42 | - Group Mentoring 43 | - Help onboard new and current contributors into the culture, workflow, and CI of our contributor experience through the [contributor guide](../../guidelines/contribution/contribution-guide.md), other related documentation, [contributor summits] and programs tailored to onboarding. 44 | - Perform issue triage on and maintain the [icon-project/community](https://github.com/icon-project/community) repository. 45 | - Help SIGs with being as transparent and open as possible through creating best practices, guidelines, and general administration of YouTube, Discord, and our mailing lists where applicable 46 | - Assist SIGs/WG Chairs and Technical Leads with organizational management operations as laid out in the [sig-governance](../../guidelines/governance/sig-governance-guidelines.md) doc 47 | - Distribute contributor related news on various ICON ecosystem channels, including collaborating with the communications team for posting blogs, social media, and other media as needed. 48 | - Establish and share metrics to measure project health, community health, and general trends, including: 49 | - the contributor experience survey(s) 50 | - engagement on project platforms that we manage 51 | - Research other OSS projects and consult with their leaders about contributor experience topics to make sure we are always delivering value to our contributors 52 | 53 | #### Cross-cutting and Externally Facing Processes 54 | 55 | We cross-cut all SIGs and WGs to deliver the following processes: 56 | 57 | - Deploying Changes: 58 | When implementing policy changes we strive to balance responding quickly to the needs of the community and ensuring a disruption-free experience for project contributors. As such, the amount of notice we provide and the amount of consensus we seek is driven by our estimation of risk. We don't measure risk objectively at this time, but estimate it based on these parameters: 59 | - Low-risk changes impact a small number (<4) of SIGs, WGs, or repos, do not break existing contributor workflows, and are easy to roll back. When implementing low-risk changes we: 60 | - Socialize on [ICON Discord](https://discord.com/invite/7a75Hf3cFm) and our update calls 61 | - We will go to each lead, their mailing lists, slack channel, and/or their update meetings and ask for feedback and a [lazy consensus] process. We will follow up with a post to [ICON Discord](https://discord.com/invite/7a75Hf3cFm) `#dev_announcements` channel 62 | - High-risk changes impact a large number (>4) of SIGs, WGs, or repos, break existing contributor workflows, and are not easy to roll back. When implementing high-risk changes we: 63 | - Socialize on [ICON Discord](https://discord.com/invite/7a75Hf3cFm) and our update calls 64 | - Seek [lazy consensus] with a time box of at least 72 business hours with a GitHub issue link (or proposal if not applicable) to the following communication channels: 65 | - [ICON Discord](https://discord.com/invite/7a75Hf3cFm) `#dev_announcements` channel 66 | - We will also announce it at an ICON Community Meeting 67 | - Depending on how wide of an ecosystem change this is, we may also discord message, blog, tweet, and use other channels to get the word out. 68 | - Our standard time box is 72 business hours; however, there may be situations where we need to act quickly but the time period will always be clear and upfront. 69 | - Encourage automation to improve productivity for contributors where it makes sense and consult with SIG Testing if automation is covering GitHub workflows. 70 | 71 | ### Out of scope 72 | 73 | - Code for the testing and CI infrastructure - that’s SIG Testing 74 | - [icon-project/iips](https://github.com/icon-project/iips) ownership of proposals. This is managed by the [Technical Steering Committee](../../committees/steering-committee/). 75 | - User community management. Outside of contributors, the Communications Team manages the user community 76 | - We do not create SIGs/WGs/UGs but can assist in the various community management needs of their micro communities that would kick off their formation and keep them going. 77 | - We are not the [code of conduct committee] and therefore do not control incident management reporting or decisions; however, our moderation guidelines allow us to act swiftly if there is a clear violation of terms of either our code of conduct or one of our supported platforms terms of service. If there is an action that the committee needs to take that involves one of these platforms (example: the removal of someone from GitHub), we will carry that out if none of the committee members have access. 78 | - Communication platforms that are out of our scope for maintenance and support but we may still have some influence: 79 | - [r/helloicon](https://www.reddit.com/r/helloicon) 80 | - [@helloiconworld](https://twitter.com/helloiconworld) twitter account 81 | 82 | ## Governance 83 | 84 | This SIG adheres to the [SIG governance guidelines](/guidelines/governance/sig-governance-guidelines.md). Any changes from the guidelines should be noted here. 85 | 86 | ## Contacts 87 | 88 | SIG chair & technical lead: [Eric Solomon](https://github.com/han-so1omon) 89 | 90 | ## Projects 91 | 92 | None defined for this SIG 93 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /guidelines/technical/software-development-guidelines.md: -------------------------------------------------------------------------------- 1 | # Software Development Guidelines 2 | 3 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 4 | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 5 | "OPTIONAL" in this document are to be interpreted as described in 6 | [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). 7 | 8 | ## Introduction 9 | 10 | The purpose of this document is to describe code development best practices and guidelines. We expect developers to adhere to these guidelines where applicable. Deviations from these guidelines should be explicitly stated. 11 | 12 | ## Table Of Contents 13 | 14 | * [Licensing](#licensing) 15 | 16 | * [Repository hosting and status](#repository-hosting-and-status) 17 | 18 | * [Documentation](#documentation) 19 | * [How to write good narrative documentation](#how-to-write-good-narrative-documentation) 20 | * [How to write good code documentation](#how-to-write-good-code-documentation) 21 | 22 | * [Code formatting](#code-formatting) 23 | 24 | * [Source code branching](#source-code-branching) 25 | 26 | * [Versioning](#commit-messages) 27 | 28 | * [Commit messages](#commit-messages) 29 | 30 | * [Testing](#testing) 31 | * [Unit tests](#unit-tests) 32 | * [Integration tests](#unit-tests) 33 | * [End-to-end tests](#end-to-end-tests) 34 | 35 | * [Code reviews](#code-reviews) 36 | 37 | * [Definition of done](#definition-of-done) 38 | 39 | * [Deployment](#deployment) 40 | 41 | * [Security auditing](#security-auditing) 42 | 43 | ## Licensing 44 | 45 | Unless otherwise stated, the ICON Foundation requires open source code. The code must include an MIT license, Apache 2.0, or another license explicitly approved by the ICON Foundation. Businesses should use the Apache 2.0 license. If you don’t know what to choose, pick the MIT license. 46 | 47 | ## Repository hosting and status 48 | 49 | Code repositories should be hosted on Github. Issue tracking must be made public. Rare exceptions may be made for security vulnerabilities or other sensitive matters. Public code repositories should be pushed to regularly. 50 | 51 | ## Documentation 52 | 53 | All of the following must be documented: 54 | * Public classes, constructors, and functions 55 | * Describe inputs/arguments 56 | * Describe outputs/returns 57 | * Brief narrative description 58 | * Architectures, algorithms, and services 59 | * Extensive narrative description of how they work 60 | * Diagrams where applicable 61 | 62 | Code documentation lives in the code files, for example above a function. Narrative documentation lives outside the code files, for example a general knowledge base. 63 | 64 | ### How to write good narrative documentation 65 | 66 | **Do** 67 | * Keep the audience in mind. 68 | * Treat the audience as you would a close friend. Tell them a story. 69 | * Write succinctly and directly. 70 | * Link to other pages for glossary terms and other supplementary information. 71 | * Use analogy, example, and comparison to get points across. 72 | * Think about how pages flow from one to the next. 73 | 74 | **Don’t** 75 | * Talk down to the audience. 76 | * Assume the audience has prior knowledge on the subject. 77 | * Require the audience to navigate through multiple pages to reach the important information. 78 | 79 | ### How to write good code documentation 80 | 81 | **Do** 82 | * Think of code documentation as a short guide on how to use a function. 83 | * Apply [rubberducking](https://rubberduckdebugging.com) to documentation when explaining what the function does. 84 | * Add a minimal code example showing how the function would be used. 85 | 86 | **Don’t** 87 | * Assume a vague description and type signature is sufficient. 88 | * Assume that the code should speak for itself. 89 | 90 | **Examples** 91 | * [Tensorflow's Python3 implementation of tensorflow::softmax()](https://github.com/tensorflow/tensorflow/blob/v2.9.1/tensorflow/python/ops/nn_ops.py#L3829-L3867) 92 | 93 | ## Code formatting 94 | 95 | Projects should adopt a code format style and adhere to it from project inception to maintain consistency in readability in the codebase. The adopted code format style should be explicitly stated somewhere in the project, such as the CONTRIBUTING.md file. 96 | 97 | We recommend using one of the following styles: 98 | 99 | * [Google (multiple languages)](https://google.github.io/styleguide/) 100 | * [Uber's style guide for Golang](https://github.com/uber-go/guide/blob/master/style.md) 101 | * [AirBnb’ style guide for React](https://airbnb.io/javascript/react/) 102 | * [PEP-8, the official style guide for Python](https://peps.python.org/pep-0008/) 103 | 104 | ## Source code branching 105 | 106 | Projects should adhere to a well-formed source code branching pattern. Projects should explicitly state their pull request submission, review, and approval process somewhere in the project, such as the CONTRIBUTING.md file. 107 | 108 | We recommend using [Feature Branching](https://martinfowler.com/bliki/FeatureBranch.html). In this pattern, developers should follow these steps when branching: 109 | 1. Create a new Git issue when there is a feature or fix to be written that clearly defines what is needed and why. The Git issue is appropriately labeled, assigned, and given a milestone. 110 | 2. Create a new branch referencing that Git issue to develop the feature or fix. 111 | 3. Submit a pull request to merge back to the main branch upon completion of the feature or fix. 112 | 4. If possible, assign a reviewer to review the code of the pull request. 113 | 114 | To minimize divergence between main branch and feature branches, features should be atomic and small enough to be able to merge back to main branch quickly. Features should also be small enough that the pull request to be reviewed is not burdensome to the reviewer. Large features can be broken into many smaller features. 115 | 116 | For working within a given repository, please follow the branching conventions of that repository. 117 | 118 | You may find that another source code branching pattern works better for you. The important thing is that development is tracked publicly via Git issues and pull requests. 119 | 120 | ### Branch protection 121 | 122 | We recommend protecting long lived branches such that all changes require at least one reviewer and one approver. It may be the case that this requirement is too restrictive if changes take too long to get reviewed. For example, if a typo is being fixed, it probably doesn't need a review or approval. The [ship/show/ask](https://martinfowler.com/articles/ship-show-ask.html) methodology decreases restrictions so that changes to mainline are not always blocked pending review, but increases instability risk because it is up to the author to request for review and approval. For more information on code reviews, see [code reviews](#code-reviews). 123 | 124 | ### Example 125 | 126 | __Issue__: "Architecture Diagram Guidelines #6" 127 | 128 | __Branch name__: "feature/architecture-diagram-guidelines" 129 | 130 | __Pull Request header__: "feature/architecture-diagram-guidelines" -> "main" => "#6 Create architecture diagram guidelines #7" 131 | 132 | _Note that the first number in the Pull Request header references the issue number. The second number is associated with the Pull Request itself_ 133 | 134 | ## Versioning 135 | 136 | We use [semantic versioning](https://semver.org) and expect all releases to be tagged. See [version bumps](#version-bumps) for more information on how we do versioning. 137 | 138 | We sometimes use pre-release labels to indicate that a version is unstable and might not satisfy the intended compatibility requirements. The pre-release labels we use include: 139 | 140 | | Version state | Notation | Explanation | 141 | | ------------- | -------- | ----------- | 142 | | Alpha | -alpha | Testing phase. Sandbox usage. Breaking issues expected | 143 | | Beta | -beta | Testing phase. Real-world usage. Breaking issues expected | 144 | | Release candidate | -rc | Pre-release phase. Real-world usage. Breaking issues may be expected but are not identified | 145 | | Release | _No extra notation_ | Release / ready phase. Real-world usage. No further changes expected to this version | 146 | 147 | You may find that another versioning convention works better for you. The important thing is that releases are clearly and consistently tagged, and that versioning methodology is explicit. One alternative we recommend to consider is [calendar versioning](https://calver.org/). 148 | 149 | ## Commit Messages 150 | 151 | We recommend to squash the commit history of a short-lived branch when merging to a long-lived branch. 152 | 153 | We adopt our commit message format from [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/). Commits MUST follow this format because it makes commit history easy to understand. 154 | 155 | ``` 156 | (): 157 | 158 | 159 | 160 |