First draft of Riker reorganization. #1
Conversation
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.md
Outdated
|
|
||
| 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. |
transition-outline.md
Outdated
| ## 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 was a problem hiding this comment.
on other languages => of other languages
transition-outline.md
Outdated
| ## 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 |
There was a problem hiding this comment.
maybe a comma after low level would make reading this sentence easier
transition-outline.md
Outdated
|
|
||
| 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. |
| 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. |
There was a problem hiding this comment.
That is yet to be established. I've reached out to members of community. (Can you also check Gitter DM).
transition-outline.md
Outdated
| 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. |
There was a problem hiding this comment.
"the Liberal Community governance style" sounds like it's "a Thing", so please link to it, for those unfamiliar with it
transition-outline.md
Outdated
| ## Core Team | ||
| Initially there will be four members of the Core Team. | ||
|
|
||
| The first tasks of the CT will be: |
There was a problem hiding this comment.
please spell out CT, otherwise this reads like a medical / social study white paper, where scientists make up an ad-hoc abbreviation no one's ever heard of, while talking about a new concept
(there's worse things, of course: creating an abbreviation only ever used in said papers, even established abbreviations already exist;)
transition-outline.md
Outdated
|
|
||
| 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. |
There was a problem hiding this comment.
DAO (which, thanks to my broken brain i keep reading as DOA, dead or alive) also sounds like "a Thing", so please link to it.
| 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. | ||
|
|
There was a problem hiding this comment.
We don't yet, and this is something that would come from the core team in the short term. This policy section is setting the tone. It's letting those that want to join the team know the general culture that I'd like to see. That is, I don't want a comprehensive list of rules that attempts to supervise sensible actors. I also know though that there are bad actors out there, so to take from good design, we would be context bound. I.e. limit discussion to Riker and related technical topics, and when doing so to extend the respect they deserve as humans above all. Not a monolithic system that attempts to code for state and behavior outside of the context of Riker, e.g. people's political views on social media.
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.