From 8c49b5767a980849d17c69a73b50a560af374e19 Mon Sep 17 00:00:00 2001 From: Lee Smith Date: Tue, 30 Jun 2020 18:22:59 +0800 Subject: [PATCH 1/4] First draft of Riker reorganization. I have created this document to get buy-in for forming a core team for the Riker project. I believe it is important to communicate the vision and set basic direction. It's critical to get basic alignment before discussing to-dos. After agreeing on these basics we can discuss concrete action points, such as where/how to communicate, near-term roadmap, code review & merge process, etc. You are welcome to propose changes to this document directly or comment below. --- transition-outline.txt | 115 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 transition-outline.txt diff --git a/transition-outline.txt b/transition-outline.txt new file mode 100644 index 0000000..63336eb --- /dev/null +++ b/transition-outline.txt @@ -0,0 +1,115 @@ +# Riker Reorganization + +## Introduction +Riker is a Rust actor system that has been developed by a single maintainer and small group of contributors since 2018. + +As Rust and the actor model has grown in interest so has Riker. For Riker to continue to grow and seize the opportunities ahead, a transition to a more effective development process is required. + +Lee Smith, the founder and maintainer of Riker has called for this transition in a GitHub issue: [Issue #102](https://github.com/riker-rs/riker/issues/102). + +The purpose of this document is to gain alignment and consensus on forming the first steps of transition. Several Riker users (developers that use or have contributed to Riker) have provided input on how they would like to move forward. However, anyone interest in contributing through PRs or comments to this document may do so. + +The style of this document is semi-official, optimizing for ideas and shared thoughts, rather than concrete guides and rules. Concrete materials must however emerge from this process. + +Ultimately, this document aims to set direction and initial targets/goals of the reorganization, much like an RFC. + +## Background +Riker started out as another project, a closed-source Rust library, to provide easy to use concurrency abstracted using the actor model. Rust async primitives were not part of the standard library and other libraries were too low level. + +Riker, the open source project that spun off has provided the Rust community with a familiar actor model, taking inspiration from actor systems on other languages, in particular Scala's Akka, and Erlang. + +There has always been a firm belief that Rust is unique and therefore, while drawing inspiration from Akka and Erlang provides guidance, simply copying core concepts from those systems isn't the best approach. I.e. Rust needs its own actor system. + +Another firm belief is that Riker should not attempt to provide concurrency primitives. The concurrency primitive in Erlang is the actor, and in the early days of Akka that was the default goto concurrency type too. Rust however was created with concurrency in mind from its first release, with a roadmap to futures and async. For concurrent IO operations in Rust, please use the excellent async capabilities developed by the Rust core team. + +## Opportunity & Vision +The Rust language has provided solutions to two major problems: + +1. Safety to low level performant code through its unique use of ownership +2. Modern language design and semantics to low level performant code in the form of traits and other concepts + +This has made Rust unique in that it provides developers the power and performance of low level languages such as C and C++, while also providing developers the benefits of modern language design. It is the belief of the Riker developers that these solutions are increasingly important in today's environment. + +The future's problems lie not in large cloud systems hosted on abundant, powerful server infrastructure, but instead in resource limited environments, that are often mission critical. + +Essentially, Rust provides a robust solution to developing systems at scale where speed, efficiency and safety are paramount. Typical examples are: xyz. + +So why Riker? + +While the Rust language and libraries are first-class solutions, there are no major frameworks that assist developers, especially for production environments. + +Today, Rust is mostly chosen for the actual language features. Many successful languages however are chosen because of a tried and tested set of tools or components, often unified by some model. Scala's Akka for example provides such a framework, that uses the common actor model and concepts such as supervision. For many Scala developers they were introduced to the language via Akka. And for Erlang developers a major attraction is it's use of actors. + +To summarize: + +- Async is difficult to reason about +- State is difficult to manage in Async (especially in Rust's strict ownership system) +- Large projects are difficult to maintain using low level async +- The Actor Model is familiar, proven and widely used +- Actor Model provides a language agnostic abstraction, without boxing developers off from Rust's power +- Actor model compliments Rust's fundemental concept of ownership (Actors own their state) and safety (Actors provide resilience through 'let it fail' supervision) +- Common framework for solving common problems +- Entry point to Rust. Onboarding for non-Rust developers + +Riker's ultimate goal is to supply individuals and teams with a product that is future proof. + +## Core Team +Initially there will be four members of the Core Team. + +The first tasks of the CT will be: +- Establish communication guides and channels +- Solve immediate pace of code review and merge of PRs +- Provide outline of roadmap and direction +- Local development environment setup guide +- Pull Request requirements and process +- Code style requirements +- RFC process, including templates and guide + +Long term the CT will work to establish workgroups that will ideally be empowered to work autonomously. + +## Governance & Contribution +Riker will initially use the Liberal Community governance style, employing the RFC (Request for Comments) document process for changes to code. + +While Riker remains primarily a Rust library, major changes to code will require an RFC document to be submitted. Everyone is able to participate in the discussion and it will be the decision of the Core Team to approve, or reject, resulting proposals. + +It is expected that the governing structure will evolve in to a DAO (Distributed Autonomous Organization) as the framework grows. Such a move will only take place if and when certain conditions (yet to be defined) are met. + +The DAO will reserve the right to issue its own cryptocurrency token. The token can be used to participate in governance decision making and sharing of funds generated by any economic activity that the DAO undertakes. + +## Website +- State the problem +- Why use Riker, both from Rust perspective and non-current Rust developers +- Areas of key focus and opportunity, e.g. SBCs, resource limited environments, blockchain, web browsers (WebAssembly) +- Roadmap. E.g. on https://beam.mw/#exchanges +- Polls on features and direction +- Should communicate to individuals and teams. Individuals will value the independence of the organization and teams will have reassurance of long term commitment + +## Workgroups +- Core (system, kernel, actor modules, performance) +- CI and Publishing (should this be part of Core?) +- Documentation +- Ecosystem (Actor patterns, Rust, http, interop with common libraries, end-to-end guidance). Should this be part of Documentation? +- Community (Twitter, Rust groups, etc) + +## Policy +Respect is the ultimate governing ideal for persons participating in Riker. Persons who are giving their time to add value to the project will be respected. + +- Respect that people are unique yet equal +- Respect that people have differing views and opinions + +Successful human aggregates are historically those that respect and promote cooperation between persons holding contrary opinions. Those that enforce a single, monolithic view are short lived. + +Unless otherwise stated, group communication will be limited to Riker-specific topics. + +The core team will be responsible for reviewing policy changes. + +## References +- [Open source best practices](https://opensource.guide/best-practices/) +- [Open source governance](https://opensource.guide/leadership-and-governance/) +- [Healthy open source](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) +- [Six lessons from RFC process](https://opensource.com/article/17/9/6-lessons-rfcs) + + + + + From 575a0797216ebdd1185cd83b09a3dd77c20b1f1c Mon Sep 17 00:00:00 2001 From: Lee Smith Date: Mon, 13 Jul 2020 20:56:04 +0800 Subject: [PATCH 2/4] renamed file with extension .md --- transition-outline.txt => transition-outline.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename transition-outline.txt => transition-outline.md (100%) diff --git a/transition-outline.txt b/transition-outline.md similarity index 100% rename from transition-outline.txt rename to transition-outline.md From f172760b91727cb8926552164256971c0759ec30 Mon Sep 17 00:00:00 2001 From: Lee Smith Date: Wed, 15 Jul 2020 14:27:04 +0800 Subject: [PATCH 3/4] Replaces ambiguous statements with specifics. Provides links to Things --- transition-outline.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/transition-outline.md b/transition-outline.md index 63336eb..4921fd6 100644 --- a/transition-outline.md +++ b/transition-outline.md @@ -16,7 +16,7 @@ Ultimately, this document aims to set direction and initial targets/goals of the ## Background Riker started out as another project, a closed-source Rust library, to provide easy to use concurrency abstracted using the actor model. Rust async primitives were not part of the standard library and other libraries were too low level. -Riker, the open source project that spun off has provided the Rust community with a familiar actor model, taking inspiration from actor systems on other languages, in particular Scala's Akka, and Erlang. +Riker, the open source project that spun off has provided the Rust community with a familiar actor model, taking inspiration from actor systems built on other languages, in particular Scala's Akka, and Erlang. There has always been a firm belief that Rust is unique and therefore, while drawing inspiration from Akka and Erlang provides guidance, simply copying core concepts from those systems isn't the best approach. I.e. Rust needs its own actor system. @@ -25,7 +25,7 @@ Another firm belief is that Riker should not attempt to provide concurrency prim ## Opportunity & Vision The Rust language has provided solutions to two major problems: -1. Safety to low level performant code through its unique use of ownership +1. Safety to low level, performant code through its unique use of ownership 2. Modern language design and semantics to low level performant code in the form of traits and other concepts This has made Rust unique in that it provides developers the power and performance of low level languages such as C and C++, while also providing developers the benefits of modern language design. It is the belief of the Riker developers that these solutions are increasingly important in today's environment. @@ -36,7 +36,7 @@ Essentially, Rust provides a robust solution to developing systems at scale wher So why Riker? -While the Rust language and libraries are first-class solutions, there are no major frameworks that assist developers, especially for production environments. +The Rust language and libraries are first-class solutions. However, there are no major frameworks that assist developers to build concurrent, resiliant applications, especially for production environments. Today, Rust is mostly chosen for the actual language features. Many successful languages however are chosen because of a tried and tested set of tools or components, often unified by some model. Scala's Akka for example provides such a framework, that uses the common actor model and concepts such as supervision. For many Scala developers they were introduced to the language via Akka. And for Erlang developers a major attraction is it's use of actors. @@ -56,7 +56,7 @@ Riker's ultimate goal is to supply individuals and teams with a product that is ## Core Team Initially there will be four members of the Core Team. -The first tasks of the CT will be: +The first tasks of the Core Team will be: - Establish communication guides and channels - Solve immediate pace of code review and merge of PRs - Provide outline of roadmap and direction @@ -65,14 +65,14 @@ The first tasks of the CT will be: - Code style requirements - RFC process, including templates and guide -Long term the CT will work to establish workgroups that will ideally be empowered to work autonomously. +Long term the Core Team will work to establish workgroups that will ideally be empowered to work autonomously. ## Governance & Contribution -Riker will initially use the Liberal Community governance style, employing the RFC (Request for Comments) document process for changes to code. +Riker will initially use the [Liberal Contribution](https://opensource.guide/leadership-and-governance/#what-are-some-of-the-common-governance-structures-for-open-source-projects) governance style, employing the RFC (Request for Comments) document process for changes to code. While Riker remains primarily a Rust library, major changes to code will require an RFC document to be submitted. Everyone is able to participate in the discussion and it will be the decision of the Core Team to approve, or reject, resulting proposals. -It is expected that the governing structure will evolve in to a DAO (Distributed Autonomous Organization) as the framework grows. Such a move will only take place if and when certain conditions (yet to be defined) are met. +It is expected that the governing structure will evolve in to a DAO ([Distributed Autonomous Organization](https://aragon.org/dao)) as the framework grows. Such a move will only take place if and when certain conditions (yet to be defined) are met. The DAO will reserve the right to issue its own cryptocurrency token. The token can be used to participate in governance decision making and sharing of funds generated by any economic activity that the DAO undertakes. @@ -80,6 +80,7 @@ The DAO will reserve the right to issue its own cryptocurrency token. The token - State the problem - Why use Riker, both from Rust perspective and non-current Rust developers - Areas of key focus and opportunity, e.g. SBCs, resource limited environments, blockchain, web browsers (WebAssembly) +- State non-goals - Roadmap. E.g. on https://beam.mw/#exchanges - Polls on features and direction - Should communicate to individuals and teams. Individuals will value the independence of the organization and teams will have reassurance of long term commitment From 16186f16d381948672fb3cc8d8b74dabc6c2dd8e Mon Sep 17 00:00:00 2001 From: Lee Smith Date: Wed, 15 Jul 2020 15:02:57 +0800 Subject: [PATCH 4/4] Adds code of conduct to list of items to do --- transition-outline.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/transition-outline.md b/transition-outline.md index 4921fd6..b47c008 100644 --- a/transition-outline.md +++ b/transition-outline.md @@ -9,7 +9,7 @@ Lee Smith, the founder and maintainer of Riker has called for this transition in The purpose of this document is to gain alignment and consensus on forming the first steps of transition. Several Riker users (developers that use or have contributed to Riker) have provided input on how they would like to move forward. However, anyone interest in contributing through PRs or comments to this document may do so. -The style of this document is semi-official, optimizing for ideas and shared thoughts, rather than concrete guides and rules. Concrete materials must however emerge from this process. +The style of this document is semi-official, optimizing for ideas and shared thoughts, rather than concrete guides and rules. Ultimately, this document aims to set direction and initial targets/goals of the reorganization, much like an RFC. @@ -64,6 +64,7 @@ The first tasks of the Core Team will be: - Pull Request requirements and process - Code style requirements - RFC process, including templates and guide +- Create Code of Conduct, based on the principles and policy of organization Long term the Core Team will work to establish workgroups that will ideally be empowered to work autonomously.