policy: add initial RFC process #61

zkat · 2017-09-17T18:06:22Z

Checklist

commit message follows commit guidelines

Affected core subsystem(s)

policy

Description

Hey y'all. This is an initial swing at getting an RFC process going for Ayo.js. It's based on WeAllJS's RFC process and I'm hoping that it helps give more structure to community proposals, and helps funnel conversations towards relevant parties. I believe this RFC works well for feature requests for Ayo.js, specially in that it asks requestors to put a bit more effort into providing a rationale for the changes and thinking through various issues before starting implementation. I think it also is particularly critical for policy conversations, and makes it much more clear about where and how those are supposed to happen, as well, again, as the rationale behind them.

addaleax

Basically looks good imho!

addaleax · 2017-09-17T18:25:57Z

RFC_PROCESS.md

+
+All comments on a particular RFC should be done directly on the PR: An RFC will not be accepted until relevant reviewers are satisfied with changes. Members of the working groups the RFC falls under hold ultimate authority over whether or not to accept an RFC, if there's ever conflict about it, and may resolve that using their own governance and decision-making rules.
+
+Side discussion can happen externally, but the relevant channel on the Ayo.js Discord is the preferred place to talk through things outside of PR reviews/comments. Furthermore, any decisions/suggestions that are decided on externally should be recorded in the RFC itself, for record keeping.


Discord → official documentation channels?

addaleax · 2017-09-17T18:27:56Z

RFC_PROCESS.md

+
+The name itself is a reference to the IETF's Request For Comments process, and basically involves a document or series of documents which are drafted, reviewed, and eventually ratified (approved) by the Ayo.js community through discussion among those interested.
+
+An RFC can extend, modify, or alter any part of the Ayo.js project's code or documents, whether or not they've been previously documented. This includes proposing new features, proposing major breaking changes, changes to the Code of Conduct and other community policies, changes to the governance structure of the project, and anything else that affects a significant part of the community. It can also propose entirely new policies and community agreements.


code or documents – I’m not sure, do you have anything specific in mind when you say that? Proposing API changes or sth like that?

(also: mind if I push here with 80 character line wrapping again? I’m sorry if that’s annoying but if nothing else, it’s nicer for many editors + makes pointing to specific parts of the doc easier)

Yep. Definitely things like proposing APIs. Or, for example, things like WebWorkers, changes to .mjs handling, etc etc.

ghost · 2017-09-17T18:26:51Z

RFC_PROCESS.md

+
+## How do I create an RFC?
+
+* Go to https://github.com/ayojs/ayo


i'm against on having rfc's in the main repo, as it's already a collossal monolith. can we maybe move them to a separate repo, like rust does? i think it'd also help separate community rfc's away from the main code repo

I'd like to advocate for keeping things in this repo for now, because there's relatively little volume and I think it'd be good to bootstrap an RFC process by putting it front-and-center. I would hate it if it ended up being seen like a dumping ground for unwanted ideas.

ghost · 2017-09-17T18:27:03Z

RFC_PROCESS.md

+  * Must be in `rfcs`.
+  * Must be an `.md` file.
+  * The first line should be `# RFC - <title of RFC>`
+* Tag at least one member of any relevant working groups. If you're not sure who would be responsible for reviewing your RFC, let the triage process take care of it for you.


s/working groups/teams

ghost · 2017-09-17T18:28:14Z

RFC_PROCESS.md

+
+## How does review work?
+
+All comments on a particular RFC should be done directly on the PR: An RFC will not be accepted until relevant reviewers are satisfied with changes. Members of the working groups the RFC falls under hold ultimate authority over whether or not to accept an RFC, if there's ever conflict about it, and may resolve that using their own governance and decision-making rules.


s/working groups/teams

this sentence is structured in a weird way that makes it hard to read, but i can't put my finger on it??

zkat · 2017-09-18T04:51:02Z

I've updated things according to comments, and responded to some questions (although GitHub swallowed some of them -- sorry). Let me know if there's anything else!

sandfox · 2017-09-18T10:08:01Z

I think I'm quite pro moving RFCs into separate repo but equally, being out of sight and out of mind are probably a bigger a problem now.
Probably a thing for later, but if RFCs are going to stay in the core repo I think it might be nice to somehow make travis skip running builds for RFC related PR's / branches (so long as they only contained changes to the RFCs).
I know people can skip tests with [ci skip] but it's easy to forget.
Anyway, it's looking pretty good, awesome work @zkat :-)

hypesystem

Looks really good!

(had one nit for clarity)

hypesystem · 2017-09-18T10:29:19Z

RFC_PROCESS.md

+
+* Go to https://github.com/ayojs/ayo
+* Create a PR with a new RFC document:
+  * Must be in `rfcs`.


suggestion for clarity (if my reading is correct?): "Must be in the rfcs folder."

[ci skip] PR-URL: #61

addaleax reviewed Sep 17, 2017

View reviewed changes

ghost suggested changes Sep 17, 2017

View reviewed changes

zkat force-pushed the zkat/rfc branch from dc5fcdf to 134a325 Compare September 18, 2017 04:50

ghost approved these changes Sep 18, 2017

View reviewed changes

varjmes approved these changes Sep 18, 2017

View reviewed changes

sandfox approved these changes Sep 18, 2017

View reviewed changes

hypesystem approved these changes Sep 18, 2017

View reviewed changes

jrasanen approved these changes Sep 18, 2017

View reviewed changes

scotttrinh approved these changes Sep 18, 2017

View reviewed changes

policy: add initial RFC process

29df4f0

zkat force-pushed the zkat/rfc branch from 134a325 to 29df4f0 Compare September 18, 2017 15:36

Harrison-M approved these changes Sep 18, 2017

View reviewed changes

Qard approved these changes Sep 18, 2017

View reviewed changes

zkat merged commit d264247 into latest Sep 18, 2017

zkat deleted the zkat/rfc branch September 18, 2017 17:18

zkat added a commit that referenced this pull request Sep 18, 2017

policy: add initial RFC process (#61)

5767fb8

[ci skip] PR-URL: #61

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

policy: add initial RFC process #61

policy: add initial RFC process #61

zkat commented Sep 17, 2017

addaleax left a comment

addaleax Sep 17, 2017

addaleax Sep 17, 2017

zkat Sep 18, 2017

ghost Sep 17, 2017

zkat Sep 17, 2017

ghost Sep 17, 2017

ghost Sep 17, 2017

ghost Sep 17, 2017

zkat commented Sep 18, 2017

sandfox commented Sep 18, 2017

hypesystem left a comment

hypesystem Sep 18, 2017


		All comments on a particular RFC should be done directly on the PR: An RFC will not be accepted until relevant reviewers are satisfied with changes. Members of the working groups the RFC falls under hold ultimate authority over whether or not to accept an RFC, if there's ever conflict about it, and may resolve that using their own governance and decision-making rules.

		Side discussion can happen externally, but the relevant channel on the Ayo.js Discord is the preferred place to talk through things outside of PR reviews/comments. Furthermore, any decisions/suggestions that are decided on externally should be recorded in the RFC itself, for record keeping.


		The name itself is a reference to the IETF's Request For Comments process, and basically involves a document or series of documents which are drafted, reviewed, and eventually ratified (approved) by the Ayo.js community through discussion among those interested.

		An RFC can extend, modify, or alter any part of the Ayo.js project's code or documents, whether or not they've been previously documented. This includes proposing new features, proposing major breaking changes, changes to the Code of Conduct and other community policies, changes to the governance structure of the project, and anything else that affects a significant part of the community. It can also propose entirely new policies and community agreements.


		## How do I create an RFC?

		* Go to https://github.com/ayojs/ayo


		## How does review work?

		All comments on a particular RFC should be done directly on the PR: An RFC will not be accepted until relevant reviewers are satisfied with changes. Members of the working groups the RFC falls under hold ultimate authority over whether or not to accept an RFC, if there's ever conflict about it, and may resolve that using their own governance and decision-making rules.

policy: add initial RFC process #61

policy: add initial RFC process #61

Conversation

zkat commented Sep 17, 2017

Checklist

Affected core subsystem(s)

Description

addaleax left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zkat commented Sep 18, 2017

sandfox commented Sep 18, 2017

hypesystem left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment