diff --git a/.prettierrc b/.prettierrc new file mode 100644 index 0000000000..8c58bd48da --- /dev/null +++ b/.prettierrc @@ -0,0 +1,6 @@ +{ + "semi": false, + "singleQuote": true, + "printWidth": 80, + "proseWrap": "always" +} diff --git a/linkerd.io/content/blog/linkerd-rfc-process.md b/linkerd.io/content/blog/linkerd-rfc-process.md new file mode 100644 index 0000000000..0f52d25302 --- /dev/null +++ b/linkerd.io/content/blog/linkerd-rfc-process.md @@ -0,0 +1,169 @@ +--- +title: "Introducing Linkerd's RFC process" +author: 'thomas' +date: Wed, 8 Apr 2020 09:00:00 +0000 +draft: false +tags: [Linkerd] +thumbnail: /uploads/scroll.png +--- + +Earlier this year +[we introduced a formal RFC ("request for comment") process for Linkerd](https://github.com/linkerd/rfc). +In this post, I'll describe the motivations for adding this process and talk a +little bit about how it works. If you're interested in contributing to Linkerd, +or just curious about the mechanics of an open source, open governance project, +read on for all the details! + +## Why did we introduce an RFC process? + +Linkerd is an "extremely open source" project: it is licensed under the Apache +License Version 2.0; it's hosted by a neutral foundation (the +[CNCF](https://cncf.io)) which owns the trademark; and it is +[committed to open governance](https://linkerd.io/2019/10/03/linkerds-commitment-to-open-governance/) +as its operational model. As a community-focused project, bug reports, ideas, +and feedback can come from anywhere, and we consider it critical that Linkerd +_always_ be a project that anyone anywhere in the world can use and contribute +to. This belief is part and parcel of the project's continued success. + +Linkerd has been very fortunate to have always had a very active community of +contributors. From early contributors like NIH's +[Borys Pierov](https://github.com/ashald) and BigCommerce's +[Zack Angelo](https://github.com/zackangelo) to more recent folks like +[Tarun Pothulapati](https://github.com/Pothulapati) (who started as a +[GSoC](https://summerofcode.withgoogle.com/) student in 2019 and has since then +[merged 40 PRs](https://github.com/linkerd/linkerd2/pulls?page=1&q=is%3Apr+is%3Aclose+author%3APothulapati) +into Linkerd, including some +[major features](https://github.com/linkerd/linkerd2/pull/3955/)!), Linkerd has +always benefited mightily from the community around it. + +But despite these amazing people and their efforts, we, the maintainers, still +felt that making larger contributions to Linkerd was simply not as easy as it +should be. Earlier this year, we set out to address this with the introduction +of an RFC process. We had a couple goals going into this: + +- We wanted to ensure that we had the opportunity to socialize major changes + within not just maintainers but end-users, many of whom rely on Linkerd for + the critical reliability of their systems. +- We wanted to ensure that any major changes fit within Linkerd's philosophy of + maximizing out-of-the-box value and debuggability, and were in accordance with + [Linkerd's design principles](https://linkerd.io/2019/04/29/linkerd-design-principles/). +- Most importantly, we wanted to be able to set contributors up for success and + get contentious issues on the docket as early in the process as possible, + rather than duking out design decisions in the confines of a PR when code had + already been written. + +With these goals in mind, we drafted our RFC process. Like any good open source +project, the process itself is +[defined in a repo](https://github.com/linkerd/rfc) and we're very open to your +feedback on it! + +## A three-step plan for success + +Like any good open source project, we designed our RFC process by borrowing +heavily from other projects. We took a lot of inspiration from Rust: the Rust +RFC process is clear, straightforward, and approachable, and it also happens to +be an ecosystem we depend on and care a lot about. We also took inspiration from +the Python PEP process, which was notable in its level of polish. + +While the RFC process will (must!) evolve over time, the current process looks +something like this: + +{{< fig src="/uploads/feature-workflow.svg" + title="The Feature Workflow" >}} + +As you can see, while there are two "release" stages (edge and stable), the hard +work of the process is separated into three stages: a problem statement, a +design proposal, and finally, implementation. Let's walk through them one at a +time. + +### Step 1: State the problem + +First up is the problem statement. Problem statements live in the `problem` +directory and have a short template to fill out. We’d like to know exactly what +problem you’re solving. The more details the better! Everything helps us build +the perfect solution to the issues you’re looking to have taken care of. You’ll +notice that we explicitly don’t want any solutions at this stage. It is easy to +become fixated on a solution and totally miss out on others, especially when the +problem statement isn’t extremely clear. Please make sure to clean the template +up and remove any sections that are not applicable at this time. + +With a problem statement written out, it is time for a PR to the RFC repo. The +Linkerd community will be able to ask lots of questions and get an understanding +of what kind of problem you’re experiencing. Once the community has gotten a +chance to ask all the questions they’d like, your PR will be merged into the +`problem` directory. At this point, your proposal can wait for an implementer to +come along and take care of it for you. We hope you continue in the process +though! + +### Step 2: Propose your design + +Next up is the design proposal. This is really the meat of the RFC process and +the part that will receive the most attention from the community. It is here +that we’ll work through exactly how the feature will be implemented. Before you +get started, please reach out in the [#contributors](https://slack.linkerd.io/) +Slack channel. We’ll pair you up with a reviewer who will be with you the whole +time. Once the two of you are feeling confident, it is time to move the proposal +in the problem directory to the design directory. + +Each section of the template provides direction on what makes a successful +design proposal. Thinking through how to implement a feature isn’t all the work +after all. We find it just as important to explicitly call out functionality +that is out of scope. This allows implementation and architecture to be +simplified and stick to Linkerd’s project goals of being lightweight and easy to +understand. + +A pull request to the RFC repo will start community discussion again. Don’t be +surprised if there is conversation and changes to the proposal. During this +stage you can expect to make edits, both big and small, to clarify or change the +design based on feedback. Consensus will lead to your pull request being merged +and now it is time to start development! + +### Step 3: You finally get to write code + +Now for the fun part, writing code! An important piece of the proposal is +outlining deliverables. We do this to ensure pull requests are small, thoughtful +and implement small pieces of the larger functionality. With an accepted +proposal, code review is primarily around style and functionality, the major +architectural decisions will already be sorted out. The assigned reviewer will +be with you every step of this phase and be your primary reviewer. + +### Step 4: Profit? + +As all your deliverables get merged, they’ll get shipped in the next release. +Linkerd does regular edge releases every week. These allow anyone interested to +play with new functionality and test it out. It also provides time for writing +documentation and educating the community on what is happening with the project. +Once we’re comfortable with the stability of the project, a stable release will +happen. These are about 6 weeks between each other. Don’t worry, even if a +stable release is going to happen during the middle of development, we’ll just +make sure it is marked as experimental. + +## Once more unto the RFC + +We've already had +[a few early proposals](https://github.com/linkerd/rfc/pulls?q=is%3Apr) start to +wend their way through the RFC process, and we're eager to see how things play +out and to do any fine tuning along the way. Of course, we'd love your feedback, +and we'd love even more to have you participate! We can't wait to see what +amazing things that you have planned for the future for Linkerd. + +## Linkerd is for everyone + +Linkerd is a community project and is hosted by the +[Cloud Native Computing Foundation](https://cncf.io/). Linkerd is +[committed to open governance.](https://linkerd.io/2019/10/03/linkerds-commitment-to-open-governance/) +If you have feature requests, questions, or comments, we'd love to have you join +our rapidly-growing community! Linkerd is hosted on +[GitHub](https://github.com/linkerd/), and we have a thriving community on +[Slack](https://slack.linkerd.io/), [Twitter](https://twitter.com/linkerd), and +the [mailing lists](https://linkerd.io/2/get-involved/). Come and join the fun! + +## Want to get involved? + +We’d love your feedback on service mirroring. Please leave us feedback on the +[service mirroring design doc](https://docs.google.com/document/d/1uzD90l1BAX06za_yie8VroGcoCB8F2wCzN0SUeA3ucw/edit). +You can also email the +[cncf-linkerd-dev mailing list](https://lists.cncf.io/g/cncf-linkerd-dev) or +find us on the [Linkerd community Slack](https://slack.linkerd.io). We're +actively prototyping this solution today, and hope to have a functioning +implementation very soon. diff --git a/linkerd.io/package.json b/linkerd.io/package.json index 1598ff55b4..869db6091f 100644 --- a/linkerd.io/package.json +++ b/linkerd.io/package.json @@ -23,11 +23,5 @@ "markdownlint-cli": "^0.14.1", "pa11y-ci": "^2.1.1", "prettier": "^1.16.4" - }, - "prettier": { - "semi": false, - "singleQuote": true, - "printWidth": 80, - "proseWrap": "never" } } diff --git a/linkerd.io/static/uploads/feature-workflow.svg b/linkerd.io/static/uploads/feature-workflow.svg new file mode 100644 index 0000000000..604fdf54bc --- /dev/null +++ b/linkerd.io/static/uploads/feature-workflow.svg @@ -0,0 +1,3 @@ + + +
Problem Statement
Problem Statement
Design Proposal
Design Proposal
Development
Development
Edge Release
Edge Release
Stable Release
Stable Release
Code Review
Code Review
Questions
Questions
Architecture Review
Architecture ReviewViewer does not support full SVG 1.1 \ No newline at end of file diff --git a/linkerd.io/static/uploads/scroll.png b/linkerd.io/static/uploads/scroll.png new file mode 100644 index 0000000000..25d97dce9e Binary files /dev/null and b/linkerd.io/static/uploads/scroll.png differ