New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC to describe the RFC process #1

Merged
merged 39 commits into from Mar 18, 2017

Conversation

@zimbatm
Member

zimbatm commented Feb 12, 2017

The goal is to define a process to unblock issues and PRs where there is clearly a need or good contribution but no clear outcome. The hope here is that by putting down all the context it will help the community reach a consensus. I also want to keep the process lite-weight to avoid hindering the contribution process.

The proposal is mainly lifted from the Rust community. This is mainly a starting point for the discussion, we should probably adapt the RFC process to our community.

One of the big difference with our community is that we don't have paid members that can implement the RFCs. That makes it hard to "accept" a RFC and have it implemented without having a "champion" that first agrees to be working on this. So I propose that instead we should have the RFC submitter try to gain at least traction of one other community member.

There are also some open questions regarding the feedback process. What is the acceptable response period for a feedback?

Actions after merge:

  • Add cleaned-up RFC to README.md (will be handled in #2)
  • Move repo to the NixOS org
  • Redirect relevant issues and PRs to this repo
  • Go through the process with another RFC to improve the process

Rendered

@zimbatm zimbatm changed the title from RFC to describe the process RFC to RFC to describe the RFC process Feb 12, 2017

zimbatm added some commits Feb 12, 2017

@zimbatm zimbatm referenced this pull request Feb 12, 2017

Merged

Implement RFC 0001 #2

Show outdated Hide outdated rfcs/0000-rfc-process.md
At this point, the person submitting the RFC should find at least one "buddy"
that will help him bring the RFC to reality. The goal is to improve the
chances that the RFC is both desired and lilely to be implemented.

This comment has been minimized.

@nbp

nbp Feb 12, 2017

Member

nit: lilely -> likely

@nbp

nbp Feb 12, 2017

Member

nit: lilely -> likely

This comment has been minimized.

@zimbatm

zimbatm Feb 13, 2017

Member

Fixed in 254918a

Show outdated Hide outdated rfcs/0000-rfc-process.md
are much more likely to make progress than those that don't receive any
comments.
At this point, the person submitting the RFC should find at least one "buddy"

This comment has been minimized.

@teh

teh Feb 12, 2017

I'd go even further and find a "shepherd" who has the implied right to pull in people who are currently blocking progress. I don't mean "blocking" in a bad way. AFAICT all PRs die due to indifference or lack of time, not because anyone is maliciously blocking.

My hope is that "ownership" will help avoiding no-one being responsible for moving things forward to either accepted or rejected.

@teh

teh Feb 12, 2017

I'd go even further and find a "shepherd" who has the implied right to pull in people who are currently blocking progress. I don't mean "blocking" in a bad way. AFAICT all PRs die due to indifference or lack of time, not because anyone is maliciously blocking.

My hope is that "ownership" will help avoiding no-one being responsible for moving things forward to either accepted or rejected.

This comment has been minimized.

@zimbatm

zimbatm Feb 13, 2017

Member

Yes that's what the Rust community is also using: https://github.com/rust-lang/rfcs#the-role-of-the-shepherd . I think it implies some form of structure like sub-teams and such which is why I didn't go with this, the nix community structure is much more amorphous. In my mind the "buddy" plays a similar role but depends on it's gravity, kudos, community credits, to make things happen.

@zimbatm

zimbatm Feb 13, 2017

Member

Yes that's what the Rust community is also using: https://github.com/rust-lang/rfcs#the-role-of-the-shepherd . I think it implies some form of structure like sub-teams and such which is why I didn't go with this, the nix community structure is much more amorphous. In my mind the "buddy" plays a similar role but depends on it's gravity, kudos, community credits, to make things happen.

This comment has been minimized.

@moretea

moretea Feb 16, 2017

So is it OK to create a PR first, and then find a buddy (by e.g. sending an email to the list)?

@moretea

moretea Feb 16, 2017

So is it OK to create a PR first, and then find a buddy (by e.g. sending an email to the list)?

This comment has been minimized.

@regnat

regnat Feb 16, 2017

I don't really understand the exact role of the buddy in our case. For the rust community it makes sense because of the structure of the project (the shepherd belongs to Rust's development team which is a well-defined subset of the community), but as nix community is far less structured, it seems to me that the person submitting the RFC will de facto be his own buddy

@regnat

regnat Feb 16, 2017

I don't really understand the exact role of the buddy in our case. For the rust community it makes sense because of the structure of the project (the shepherd belongs to Rust's development team which is a well-defined subset of the community), but as nix community is far less structured, it seems to me that the person submitting the RFC will de facto be his own buddy

This comment has been minimized.

@zimbatm

zimbatm Feb 16, 2017

Member

Maybe "co-author" is more accurate?

The goal is multifold. I believe that having someone with whom the author can work more closely with would help to advance the RFC. If the author is not embedded in community, the co-author can lend some credence to the proposal. He can also help respond to other people's question as he hopefully shares enough context with the author. And also help out weed the usually typos and just provide a quicker iteration speed in general.

Ideally the author and "buddy" would have a closer relationship, maybe over IRC, voice or video.

@zimbatm

zimbatm Feb 16, 2017

Member

Maybe "co-author" is more accurate?

The goal is multifold. I believe that having someone with whom the author can work more closely with would help to advance the RFC. If the author is not embedded in community, the co-author can lend some credence to the proposal. He can also help respond to other people's question as he hopefully shares enough context with the author. And also help out weed the usually typos and just provide a quicker iteration speed in general.

Ideally the author and "buddy" would have a closer relationship, maybe over IRC, voice or video.

This comment has been minimized.

@nbp

nbp Feb 25, 2017

Member

"peer", "co-author", "contradictor", "guide", "mentor", "buddy", ...

I think "buddy" is not formal enough, and confusing as well. I think we need a better name, and a better bullet-list description of what these persons are responsible for, and what they are not responsible for:

  • improve changes of getting the RFC accepted.
  • Stay in contact, and query for progress?
  • Request changes and request analysis of alternatives?
  • Bring alternative to the currently proposed design?
  • Help implement the idea when the RFC is accepted?
  • Suggest implementation ideas?
@nbp

nbp Feb 25, 2017

Member

"peer", "co-author", "contradictor", "guide", "mentor", "buddy", ...

I think "buddy" is not formal enough, and confusing as well. I think we need a better name, and a better bullet-list description of what these persons are responsible for, and what they are not responsible for:

  • improve changes of getting the RFC accepted.
  • Stay in contact, and query for progress?
  • Request changes and request analysis of alternatives?
  • Bring alternative to the currently proposed design?
  • Help implement the idea when the RFC is accepted?
  • Suggest implementation ideas?

This comment has been minimized.

@zimbatm

zimbatm Mar 1, 2017

Member

Renamed buddy to co-author in 2d315c6. I agree that it would be nice to refine the co-author's responsibilities but it's another thing to reach consensus on. Would it be alright to leave it ambiguous for now?

@zimbatm

zimbatm Mar 1, 2017

Member

Renamed buddy to co-author in 2d315c6. I agree that it would be nice to refine the co-author's responsibilities but it's another thing to reach consensus on. Would it be alright to leave it ambiguous for now?

@zimbatm

This comment has been minimized.

Show comment
Hide comment
@zimbatm

zimbatm Feb 13, 2017

Member

Thanks all for your reviews. I am still looking for a "buddy" for this RFC to adhere to it's own saying, anyone interested?

Member

zimbatm commented Feb 13, 2017

Thanks all for your reviews. I am still looking for a "buddy" for this RFC to adhere to it's own saying, anyone interested?

Show outdated Hide outdated rfcs/0000-rfc-process.md
- Adding, updating and removing packages in nixpkgs
- Additions only likely to be _noticed by_ other developers-of-nix,
invisible to users-of-nix.

This comment has been minimized.

@edolstra

edolstra Feb 13, 2017

Member

What are "users" and "developers" in this context?

@edolstra

edolstra Feb 13, 2017

Member

What are "users" and "developers" in this context?

This comment has been minimized.

@zimbatm

zimbatm Feb 15, 2017

Member

That was imported from the Rust RFC where developers and users are more clearly defined I think. I will remove that for now.

@zimbatm

zimbatm Feb 15, 2017

Member

That was imported from the Rust RFC where developers and users are more clearly defined I think. I will remove that for now.

This comment has been minimized.

Show outdated Hide outdated rfcs/0000-rfc-process.md
rubber stamp, and in particular still does not mean the feature will
ultimately be merged; it does mean that in principle all the major
stakeholders have agreed to the feature and are amenable to merging it.

This comment has been minimized.

@edolstra

edolstra Feb 13, 2017

Member

This needs some more info about the lifecycle. See e.g. https://www.python.org/dev/peps/pep-0001/. For example, what's the status of a finalized RFC? Once PEPs reach "final" state, they're no longer modified and are mostly of historic interest - they're not primary documentation because any relevant doc changes should be made to the manual. This is in contrast to IETF Standards Track RFCs which are primary documentation.

@edolstra

edolstra Feb 13, 2017

Member

This needs some more info about the lifecycle. See e.g. https://www.python.org/dev/peps/pep-0001/. For example, what's the status of a finalized RFC? Once PEPs reach "final" state, they're no longer modified and are mostly of historic interest - they're not primary documentation because any relevant doc changes should be made to the manual. This is in contrast to IETF Standards Track RFCs which are primary documentation.

This comment has been minimized.

@zimbatm

zimbatm Feb 15, 2017

Member

I don't really know what's the best solution. I agree that RFCs shouldn't have to be updated but things might come up during the implementation that might trigger another round of discussion.

@zimbatm

zimbatm Feb 15, 2017

Member

I don't really know what's the best solution. I agree that RFCs shouldn't have to be updated but things might come up during the implementation that might trigger another round of discussion.

This comment has been minimized.

@moretea

moretea Feb 16, 2017

What about having the following state machine:

new -> proposed ->  accepted -> implemented
                    |     ^
                    v     |
                    revising
       
and: new -> closed, proposed -> closed, revising -> closed, accepted -> closed
(but not implemented -> closed)

If a RFC has been accepted, but not implemented yet, we could start revising it if there are issues that need RFC level discussions.

@moretea

moretea Feb 16, 2017

What about having the following state machine:

new -> proposed ->  accepted -> implemented
                    |     ^
                    v     |
                    revising
       
and: new -> closed, proposed -> closed, revising -> closed, accepted -> closed
(but not implemented -> closed)

If a RFC has been accepted, but not implemented yet, we could start revising it if there are issues that need RFC level discussions.

This comment has been minimized.

@zimbatm

zimbatm Feb 16, 2017

Member

Most of the value of the RFC is derived from having developers being forced to serialise their thoughts to human language instead of code. It's mainly a communication tool. Unless the RFC gets largely discarded when faced with implementation realities it doesn't need to be amended after merge.

RFCs should probably be updated with the relevant implementation PRs for developer to be able to follow the process.

@zimbatm

zimbatm Feb 16, 2017

Member

Most of the value of the RFC is derived from having developers being forced to serialise their thoughts to human language instead of code. It's mainly a communication tool. Unless the RFC gets largely discarded when faced with implementation realities it doesn't need to be amended after merge.

RFCs should probably be updated with the relevant implementation PRs for developer to be able to follow the process.

This comment has been minimized.

@ttuegel

ttuegel Feb 17, 2017

Member

I think revision after implementation is more important than before. Everybody always has a favorite bikeshed color, so it's a real pain when you reach a consensus after weeks of discussion only to find that what you need to build isn't a bikeshed at all!

To put it less colorfully, there needs to be space to experiment, especially when it comes to changes that affect a wide section of our project. There are always unknowns, and there are always unknown-unknowns. It's important to get feedback from people who are actually using an implementation before setting that implementation in stone. Projects that insist on one-way innovation with no room for experimentation end up strangling themselves with bad decisions that seemed ingenious at the time. The core Haskell projects are a great example of this. If you can't fix a severe security vulnerability without a multi-year deprecation period, something has gone horribly wrong!

I'm not suggesting that this proposal is rushing down that path, but I think there should explicitly be room for experimentation in the proposal lifecycle. Leaving room explicitly is why C4 has a "draft" status for public contracts. I'm thinking along these lines:

new -> proposed -> accepted -> implemented (draft) -> final
                       ^                |
                       |                |
                       +--  revision  --+

The draft stage should be a "handshake agreement": the user understands that the feature may change in response to data gathered from use, but the implementer understands this should only be done with adequate warning and for a really good reason. The final stage would be regarded as "set in stone": this feature will only change following a new RFC and an extended deprecation period.

Well, I wanted to give my two cents, but it looks like I dropped a buck-fifty on the table; sorry about that!

@ttuegel

ttuegel Feb 17, 2017

Member

I think revision after implementation is more important than before. Everybody always has a favorite bikeshed color, so it's a real pain when you reach a consensus after weeks of discussion only to find that what you need to build isn't a bikeshed at all!

To put it less colorfully, there needs to be space to experiment, especially when it comes to changes that affect a wide section of our project. There are always unknowns, and there are always unknown-unknowns. It's important to get feedback from people who are actually using an implementation before setting that implementation in stone. Projects that insist on one-way innovation with no room for experimentation end up strangling themselves with bad decisions that seemed ingenious at the time. The core Haskell projects are a great example of this. If you can't fix a severe security vulnerability without a multi-year deprecation period, something has gone horribly wrong!

I'm not suggesting that this proposal is rushing down that path, but I think there should explicitly be room for experimentation in the proposal lifecycle. Leaving room explicitly is why C4 has a "draft" status for public contracts. I'm thinking along these lines:

new -> proposed -> accepted -> implemented (draft) -> final
                       ^                |
                       |                |
                       +--  revision  --+

The draft stage should be a "handshake agreement": the user understands that the feature may change in response to data gathered from use, but the implementer understands this should only be done with adequate warning and for a really good reason. The final stage would be regarded as "set in stone": this feature will only change following a new RFC and an extended deprecation period.

Well, I wanted to give my two cents, but it looks like I dropped a buck-fifty on the table; sorry about that!

This comment has been minimized.

@zimbatm

zimbatm Feb 19, 2017

Member

No worries :)

How I see it, the RFC process is more about doing a project proposal. Right now our de-facto "project manager", the person who can make wide decisions is Eelco, and he doesn't have time to extract meaning from reading code on large pull-requests. The goal here is to push some of that decision-making upfront, before all the work is done. It's more costly to the developer but should help Eelco. It doesn't mean that everything has to be decided upfront though. I agree that we want to avoid doing waterfall design.

If that's not clear from the existing wording then it should be revised. Maybe "RFC" is a bad term because it's too close to IETF RFCs. How about I rename them to NIP (Nix Improvement Proposals)? I think that was @moretea's idea. (danger: bikeshed ahead :)

@zimbatm

zimbatm Feb 19, 2017

Member

No worries :)

How I see it, the RFC process is more about doing a project proposal. Right now our de-facto "project manager", the person who can make wide decisions is Eelco, and he doesn't have time to extract meaning from reading code on large pull-requests. The goal here is to push some of that decision-making upfront, before all the work is done. It's more costly to the developer but should help Eelco. It doesn't mean that everything has to be decided upfront though. I agree that we want to avoid doing waterfall design.

If that's not clear from the existing wording then it should be revised. Maybe "RFC" is a bad term because it's too close to IETF RFCs. How about I rename them to NIP (Nix Improvement Proposals)? I think that was @moretea's idea. (danger: bikeshed ahead :)

This comment has been minimized.

@nbp

nbp Feb 25, 2017

Member

Ok, I thought that a graphviz document, with comment would be easier to follow. There is one thing which remains to be determine in the following, which is the set of person responsible for accepting or rejecting proposals.

digraph rfc-state {
  /* Draft stage, any newly create RFC is in a draft stage. Provide draft implementation for the project, such as
   *  Nix, Nixpkgs without adding pull request to other repository, but refer to the draft-ed implementation in forked
   *  version of the projects. */
  draft;

  /* Submitted stage, a comity of persons (to be defined) evaluates the feasibility and compare benefits against the
   * drawbacks.  Ideally the peers (buddy, mentors, ...) should have help clear-up the ground for any questions that
   * might be asked by the comity. */
  submitted;

  /* Accepted stage, a comity of persons, agreed with the feasibility and that benefit outweigh the drawback and that a
   * complete implementation would be implemented in the projects. */
  accepted;

  /* Rejected stage, a comity of persons, disagree with the feasibility and/or that the drawbacks outweigh the benefit.
   * The comity should provide a comments explaining the choice. Any reject draft should not be submitted until all 
   * comments are addressed, and not within a period of 3 months (in order to prevent recurrent submissions) */
  rejected;

  /* Abandoned stage, nor the authors nor the peers (buddy, mentor, ...) can think of an alternative to compensate for
   * the rejection comments. */
  abandoned;

  /* Implemented stage, the proposal is available main-stream, and should be the default way of doing. */
  implemented;

  /* Replaced stage, another proposal is implemented and the content of this proposal should be ignored, unless
   * explicitly mentioned by an implemented proposal. */
  replaced;

  draft -> submitted [label="submitted by the author"];
  submitted -> accepted [label="validated by comity"];
  submitted -> rejected [label="rejected by comity"];
  rejected -> draft;

  draft -> abandoned [label="no alternative, or person to pursue"];

  accepted -> implemented [label="all components merged, and the feature is usable"];
  accepted -> replaced [label="better alternative found before the implementation"];
  implemented -> replaced [label="better alternative found after the implementation"];
}
@nbp

nbp Feb 25, 2017

Member

Ok, I thought that a graphviz document, with comment would be easier to follow. There is one thing which remains to be determine in the following, which is the set of person responsible for accepting or rejecting proposals.

digraph rfc-state {
  /* Draft stage, any newly create RFC is in a draft stage. Provide draft implementation for the project, such as
   *  Nix, Nixpkgs without adding pull request to other repository, but refer to the draft-ed implementation in forked
   *  version of the projects. */
  draft;

  /* Submitted stage, a comity of persons (to be defined) evaluates the feasibility and compare benefits against the
   * drawbacks.  Ideally the peers (buddy, mentors, ...) should have help clear-up the ground for any questions that
   * might be asked by the comity. */
  submitted;

  /* Accepted stage, a comity of persons, agreed with the feasibility and that benefit outweigh the drawback and that a
   * complete implementation would be implemented in the projects. */
  accepted;

  /* Rejected stage, a comity of persons, disagree with the feasibility and/or that the drawbacks outweigh the benefit.
   * The comity should provide a comments explaining the choice. Any reject draft should not be submitted until all 
   * comments are addressed, and not within a period of 3 months (in order to prevent recurrent submissions) */
  rejected;

  /* Abandoned stage, nor the authors nor the peers (buddy, mentor, ...) can think of an alternative to compensate for
   * the rejection comments. */
  abandoned;

  /* Implemented stage, the proposal is available main-stream, and should be the default way of doing. */
  implemented;

  /* Replaced stage, another proposal is implemented and the content of this proposal should be ignored, unless
   * explicitly mentioned by an implemented proposal. */
  replaced;

  draft -> submitted [label="submitted by the author"];
  submitted -> accepted [label="validated by comity"];
  submitted -> rejected [label="rejected by comity"];
  rejected -> draft;

  draft -> abandoned [label="no alternative, or person to pursue"];

  accepted -> implemented [label="all components merged, and the feature is usable"];
  accepted -> replaced [label="better alternative found before the implementation"];
  implemented -> replaced [label="better alternative found after the implementation"];
}
Show outdated Hide outdated rfcs/0000-rfc-process.md
1. Does this RFC strike a favorable balance between formality and agility?
2. Does this RFC successfully address the aforementioned issues with the current
informal RFC process?
3. Should we retain rejected RFCs in the archive?

This comment has been minimized.

@edolstra

edolstra Feb 13, 2017

Member

I would say "yes", they can just be marked as "rejected" like PEPs.

@edolstra

edolstra Feb 13, 2017

Member

I would say "yes", they can just be marked as "rejected" like PEPs.

This comment has been minimized.

@zimbatm

zimbatm Feb 15, 2017

Member

Okay so it means adding a status metadata

@zimbatm

zimbatm Feb 15, 2017

Member

Okay so it means adding a status metadata

This comment has been minimized.

@zimbatm

zimbatm Feb 15, 2017

Member

Another line of reasoning would be that closed PRs are still available on github and the repo only includes things we intend to implement, which are probably more relevant to users.

@zimbatm

zimbatm Feb 15, 2017

Member

Another line of reasoning would be that closed PRs are still available on github and the repo only includes things we intend to implement, which are probably more relevant to users.

This comment has been minimized.

@zimbatm

zimbatm Feb 15, 2017

Member

It also means that closed PRs can get resurrected more easily in case our opinion changes over time.

@zimbatm

zimbatm Feb 15, 2017

Member

It also means that closed PRs can get resurrected more easily in case our opinion changes over time.

This comment has been minimized.

@regnat

regnat Feb 16, 2017

I think, rejected RFCs should be kept in the git history − at least the ones that raised some discussion from the community. The history of closed PRs isn't as convenient to browse as the actual git repo and is less reliable (the code of a PR can easily disappear or change if the submitter deletes or overwrites his branch iirc).

@regnat

regnat Feb 16, 2017

I think, rejected RFCs should be kept in the git history − at least the ones that raised some discussion from the community. The history of closed PRs isn't as convenient to browse as the actual git repo and is less reliable (the code of a PR can easily disappear or change if the submitter deletes or overwrites his branch iirc).

This comment has been minimized.

@nbp

nbp Feb 25, 2017

Member

If so, maybe we should make a directory for draft proposal, in which people work on, and accepting or rejecting would imply moving these files to the proper directory.

-- update: replaced repository by directory

@nbp

nbp Feb 25, 2017

Member

If so, maybe we should make a directory for draft proposal, in which people work on, and accepting or rejecting would imply moving these files to the proper directory.

-- update: replaced repository by directory

This comment has been minimized.

@zimbatm

zimbatm Mar 1, 2017

Member

The interesting bit about rejected PRs is the discussion that's happening around it, which is currently tied to github. Presuming the desire to merge is to keep the history of it, I'm not convinced that a closed PR would be much worse than a merge. It also means that it's one less thing to manage as a maintainer.

@zimbatm

zimbatm Mar 1, 2017

Member

The interesting bit about rejected PRs is the discussion that's happening around it, which is currently tied to github. Presuming the desire to merge is to keep the history of it, I'm not convinced that a closed PR would be much worse than a merge. It also means that it's one less thing to manage as a maintainer.

This comment has been minimized.

@FRidh

FRidh Mar 10, 2017

Member

When a RFC is rejected, it would be stored in the repo, and a section would be added explaining why it was rejected. In this section we could refer to discussions, but obviously those references may break.

@FRidh

FRidh Mar 10, 2017

Member

When a RFC is rejected, it would be stored in the repo, and a section would be added explaining why it was rejected. In this section we could refer to discussions, but obviously those references may break.

This comment has been minimized.

@zimbatm

zimbatm Mar 11, 2017

Member

Alright, all rejected RFCs will be moved to the ./rejected folder for now 9830d2d

At some point we'll be able to use the metadata to generate a website to list all the RFCs, at that point we can merge the folder back and add a "status" header.

@zimbatm

zimbatm Mar 11, 2017

Member

Alright, all rejected RFCs will be moved to the ./rejected folder for now 9830d2d

At some point we'll be able to use the metadata to generate a website to list all the RFCs, at that point we can merge the folder back and add a "status" header.

Show outdated Hide outdated rfcs/0000-rfc-process.md
- Removing language features
- Big restructuring of nixpkgs
- Introduction of new interfaces or functions
- A controversial change

This comment has been minimized.

@edolstra

edolstra Feb 13, 2017

Member

Also, anything that expands the scope of the project in a significant way. This includes adding support for new platforms or adding major subprojects (think NixUP, nix-make, ...).

Really, anything that has the potential of inflicting a lot of crosscutting technical debt or maintenance cost.

@edolstra

edolstra Feb 13, 2017

Member

Also, anything that expands the scope of the project in a significant way. This includes adding support for new platforms or adding major subprojects (think NixUP, nix-make, ...).

Really, anything that has the potential of inflicting a lot of crosscutting technical debt or maintenance cost.

This comment has been minimized.

@edolstra

edolstra Feb 13, 2017

Member

Also, adding new package abstractions or idioms (think various auto-updaters, callPackages, composableDerivation, builderDefs, language-specific functions, ...). Deviations from the standard style make it harder for other people to understand / modify a package, so there should be a good reason for introducing them.

Of course, we should probably also better document what the standard style is :-)

@edolstra

edolstra Feb 13, 2017

Member

Also, adding new package abstractions or idioms (think various auto-updaters, callPackages, composableDerivation, builderDefs, language-specific functions, ...). Deviations from the standard style make it harder for other people to understand / modify a package, so there should be a good reason for introducing them.

Of course, we should probably also better document what the standard style is :-)

This comment has been minimized.

@zimbatm

zimbatm Feb 15, 2017

Member

added 1a37875. I'm trying to avoid over-specifying the rules. Potentially we could add a BDFL line like: if @edolstra says so :-)

@zimbatm

zimbatm Feb 15, 2017

Member

added 1a37875. I'm trying to avoid over-specifying the rules. Potentially we could add a BDFL line like: if @edolstra says so :-)

@teh

This comment has been minimized.

Show comment
Hide comment
@teh

teh Feb 14, 2017

I think this is a good test case. Let's say I want to be your RFC-buddy, what can I do? The text says "that will help him bring the RFC to reality" - what kind of actions are expected of me?

(unrelated, maybe use the gender-neutral them, i.e. "will help them bring")

teh commented Feb 14, 2017

I think this is a good test case. Let's say I want to be your RFC-buddy, what can I do? The text says "that will help him bring the RFC to reality" - what kind of actions are expected of me?

(unrelated, maybe use the gender-neutral them, i.e. "will help them bring")

@zimbatm

This comment has been minimized.

Show comment
Hide comment
@zimbatm

zimbatm Feb 15, 2017

Member

@teh I'm proposing 08b081a as the definition of the role, what do you think? If you still agree of being the buddy for the RFC it would make sense to catch up using a higher throughput protocol like voice, video or IRL :)

Member

zimbatm commented Feb 15, 2017

@teh I'm proposing 08b081a as the definition of the role, what do you think? If you still agree of being the buddy for the RFC it would make sense to catch up using a higher throughput protocol like voice, video or IRL :)

Show outdated Hide outdated rfcs/0000-rfc-process.md
### Role of the "buddy"
To goal for assigning a "buddy" to the RFC is multifold. The main
responsability is to make himself available for to the author to move the RFC

This comment has been minimized.

@teh

teh Feb 15, 2017

"make themselves" :) & "with them"

@teh

teh Feb 15, 2017

"make themselves" :) & "with them"

This comment has been minimized.

@zimbatm

zimbatm Feb 15, 2017

Member

Fixed in 65d32e1, keep them coming :)

@zimbatm

zimbatm Feb 15, 2017

Member

Fixed in 65d32e1, keep them coming :)

Show outdated Hide outdated rfcs/0000-rfc-process.md
Here are roughly the steps that one would take:
* Fork the RFC repo https://github.com/NixOS/rfcs
* Copy `0000-template.md` to `rfcs/0000-my-feature.md` (where

This comment has been minimized.

@danbst

danbst Feb 16, 2017

Where can I find this template?

@danbst

danbst Feb 16, 2017

Where can I find this template?

This comment has been minimized.

@zimbatm

zimbatm Feb 16, 2017

Member

It's in #2 for now. I thought it would make sense to have the implementation separate.

@zimbatm

zimbatm Feb 16, 2017

Member

It's in #2 for now. I thought it would make sense to have the implementation separate.

Show outdated Hide outdated rfcs/0000-rfc-process.md
Some changes though are "substantial", and we ask that these be put through a
bit of a design process and produce a consensus among the Nix community and
the core team.

This comment has been minimized.

@regnat

regnat Feb 16, 2017

Does the distinction between the community and a "core team" makes sense for nix ?

@regnat

regnat Feb 16, 2017

Does the distinction between the community and a "core team" makes sense for nix ?

This comment has been minimized.

@zimbatm

zimbatm Feb 16, 2017

Member

Probably not. We have a "core team" but the notion is a bit fuzzy and probably changes from person to person. Removed in 48e3cef

@zimbatm

zimbatm Feb 16, 2017

Member

Probably not. We have a "core team" but the notion is a bit fuzzy and probably changes from person to person. Removed in 48e3cef

This comment has been minimized.

@copumpkin

copumpkin Mar 9, 2017

Member

For nixpkgs, probably true, but for Nix the program there is certainly a core team, that consists mostly of @edolstra, with a bit of @shlevy 😄 it'd be nice to expand that group, but we might as well be explicit about it until then

@copumpkin

copumpkin Mar 9, 2017

Member

For nixpkgs, probably true, but for Nix the program there is certainly a core team, that consists mostly of @edolstra, with a bit of @shlevy 😄 it'd be nice to expand that group, but we might as well be explicit about it until then

Show outdated Hide outdated rfcs/0000-rfc-process.md
are much more likely to make progress than those that don't receive any
comments.
At this point, the person submitting the RFC should find at least one "buddy"

This comment has been minimized.

@regnat

regnat Feb 16, 2017

I don't really understand the exact role of the buddy in our case. For the rust community it makes sense because of the structure of the project (the shepherd belongs to Rust's development team which is a well-defined subset of the community), but as nix community is far less structured, it seems to me that the person submitting the RFC will de facto be his own buddy

@regnat

regnat Feb 16, 2017

I don't really understand the exact role of the buddy in our case. For the rust community it makes sense because of the structure of the project (the shepherd belongs to Rust's development team which is a well-defined subset of the community), but as nix community is far less structured, it seems to me that the person submitting the RFC will de facto be his own buddy

Show outdated Hide outdated rfcs/0000-rfc-process.md
the original pull request(s) and the newly created issue.
* Commit everything.
Once an RFC becomes active then authors may implement it and submit the

This comment has been minimized.

@regnat

regnat Feb 16, 2017

Many changes won't probably drain an unconditional approval from everyone in the community − see the everlasting discussion about the wiki for example ;).

It should be useful to have a well-defined notion of when a RFC is accepted for cases where it is not obvious ( Sufficient consensus between a few selected members of the community ? Vote ? Call for @edolstra's decision ?)

@regnat

regnat Feb 16, 2017

Many changes won't probably drain an unconditional approval from everyone in the community − see the everlasting discussion about the wiki for example ;).

It should be useful to have a well-defined notion of when a RFC is accepted for cases where it is not obvious ( Sufficient consensus between a few selected members of the community ? Vote ? Call for @edolstra's decision ?)

This comment has been minimized.

@zimbatm

zimbatm Feb 16, 2017

Member

Totally agreed. One of the reason for going though the RFC process is to avoid everlasting PRs that don't get consensus. The idea is that the RFC will allow to expose the underlying problem and thinking without getting drowned in implementation details. But we could have a similar issue on the RFC submission for sure.

As usual @edolstra is the BDFL. Because of the concurrency limit, hopefully RFCs will be quicker for him to evaluate and take an executive decision. I don't have a perfect answer for that as it's a human problem. Some people want perfect solutions while others are willing to accept a compromise as long as the proposed approach improves on what we have already.

@zimbatm

zimbatm Feb 16, 2017

Member

Totally agreed. One of the reason for going though the RFC process is to avoid everlasting PRs that don't get consensus. The idea is that the RFC will allow to expose the underlying problem and thinking without getting drowned in implementation details. But we could have a similar issue on the RFC submission for sure.

As usual @edolstra is the BDFL. Because of the concurrency limit, hopefully RFCs will be quicker for him to evaluate and take an executive decision. I don't have a perfect answer for that as it's a human problem. Some people want perfect solutions while others are willing to accept a compromise as long as the proposed approach improves on what we have already.

Show outdated Hide outdated rfcs/0000-rfc-process.md
1. Does this RFC strike a favorable balance between formality and agility?
2. Does this RFC successfully address the aforementioned issues with the current
informal RFC process?
3. Should we retain rejected RFCs in the archive?

This comment has been minimized.

@regnat

regnat Feb 16, 2017

I think, rejected RFCs should be kept in the git history − at least the ones that raised some discussion from the community. The history of closed PRs isn't as convenient to browse as the actual git repo and is less reliable (the code of a PR can easily disappear or change if the submitter deletes or overwrites his branch iirc).

@regnat

regnat Feb 16, 2017

I think, rejected RFCs should be kept in the git history − at least the ones that raised some discussion from the community. The history of closed PRs isn't as convenient to browse as the actual git repo and is less reliable (the code of a PR can easily disappear or change if the submitter deletes or overwrites his branch iirc).

Remove the notion of "core team"
We don't have a definiton of who is part of the "core team"
Show outdated Hide outdated rfcs/0000-rfc-process.md
You need to follow this process if you intend to make "substantial" changes to
the Nix ecosystem. What constitutes a "substantial" change is evolving based
on community norms, but may include the following.

This comment has been minimized.

@nbp

nbp Feb 22, 2017

Member

nit: This should as well include making a RFC to describe the processes by which the community interact around the projects.

@nbp

nbp Feb 22, 2017

Member

nit: This should as well include making a RFC to describe the processes by which the community interact around the projects.

This comment has been minimized.

@zimbatm

zimbatm Mar 1, 2017

Member

One thing at a time :)

@zimbatm

zimbatm Mar 1, 2017

Member

One thing at a time :)

help contribution, not an end in itself.
# Alternatives
[alternatives]: #alternatives

This comment has been minimized.

@nbp

nbp Feb 25, 2017

Member

I do not understand why Alternatives is even a section in an RFC. What purpose does it serve?

If I understand correctly, when we are discussing about designs, we want explore multiple alternatives, including the first Design & drawbacks, and have one for each alternative. Or we should discuss the alternatives as part of the pull request for adding modifications to the RFC.

@nbp

nbp Feb 25, 2017

Member

I do not understand why Alternatives is even a section in an RFC. What purpose does it serve?

If I understand correctly, when we are discussing about designs, we want explore multiple alternatives, including the first Design & drawbacks, and have one for each alternative. Or we should discuss the alternatives as part of the pull request for adding modifications to the RFC.

This comment has been minimized.

@zimbatm

zimbatm Mar 1, 2017

Member

The idea is to list prior-art. This mainly shows that the author has done research. I agree that it would be nice to also have a justification of why those aren't adequate but that's not a strict requirement. Some of them might be obvious (eg: already discarded).

@zimbatm

zimbatm Mar 1, 2017

Member

The idea is to list prior-art. This mainly shows that the author has done research. I agree that it would be nice to also have a justification of why those aren't adequate but that's not a strict requirement. Some of them might be obvious (eg: already discarded).

This comment has been minimized.

@FRidh

FRidh Mar 10, 2017

Member

If its for prior-art then I'm of the opinion it should be mentioned before the actual proposal, and should be discussed at that point.

@nbp
If I would write a report where I investigate possible solutions, then I would do also as you say, have a section per alternative, and then a discussion where one (or none) is chosen. I can imagine that in a NEP (that's how we're going to call them, right? Nix Enhancement Proposal) that choice has already been made by the authors of the NEP and therefore they're only discussed briefly either before or after the actual proposal.

@FRidh

FRidh Mar 10, 2017

Member

If its for prior-art then I'm of the opinion it should be mentioned before the actual proposal, and should be discussed at that point.

@nbp
If I would write a report where I investigate possible solutions, then I would do also as you say, have a section per alternative, and then a discussion where one (or none) is chosen. I can imagine that in a NEP (that's how we're going to call them, right? Nix Enhancement Proposal) that choice has already been made by the authors of the NEP and therefore they're only discussed briefly either before or after the actual proposal.

This comment has been minimized.

@zimbatm

zimbatm Mar 11, 2017

Member

Submitting a RFC is already a pretty big barrier for community work, I'm a bit concerned of putting a too formal process in place.

@zimbatm

zimbatm Mar 11, 2017

Member

Submitting a RFC is already a pretty big barrier for community work, I'm a bit concerned of putting a too formal process in place.

Show outdated Hide outdated rfcs/0000-rfc-process.md
are much more likely to make progress than those that don't receive any
comments.
At this point, the person submitting the RFC should find at least one "buddy"

This comment has been minimized.

@nbp

nbp Feb 25, 2017

Member

"peer", "co-author", "contradictor", "guide", "mentor", "buddy", ...

I think "buddy" is not formal enough, and confusing as well. I think we need a better name, and a better bullet-list description of what these persons are responsible for, and what they are not responsible for:

  • improve changes of getting the RFC accepted.
  • Stay in contact, and query for progress?
  • Request changes and request analysis of alternatives?
  • Bring alternative to the currently proposed design?
  • Help implement the idea when the RFC is accepted?
  • Suggest implementation ideas?
@nbp

nbp Feb 25, 2017

Member

"peer", "co-author", "contradictor", "guide", "mentor", "buddy", ...

I think "buddy" is not formal enough, and confusing as well. I think we need a better name, and a better bullet-list description of what these persons are responsible for, and what they are not responsible for:

  • improve changes of getting the RFC accepted.
  • Stay in contact, and query for progress?
  • Request changes and request analysis of alternatives?
  • Bring alternative to the currently proposed design?
  • Help implement the idea when the RFC is accepted?
  • Suggest implementation ideas?
Show outdated Hide outdated rfcs/0000-rfc-process.md
* Assign an id, using the PR number of the RFC pull request. (If the RFC
has multiple pull requests associated with it, choose one PR number,
preferably the minimal one.)

This comment has been minimized.

@nbp

nbp Feb 25, 2017

Member

If it is going to be numbered after the PR, maybe this can be done by the original author, as the PR number is fixed once the PR is submitted. Thus instead of leaving that to the person who merges it, it can be fixed up by the authors.

*  Copy `0000-template.md` to `rfcs/0000-my-feature.md`
@nbp

nbp Feb 25, 2017

Member

If it is going to be numbered after the PR, maybe this can be done by the original author, as the PR number is fixed once the PR is submitted. Thus instead of leaving that to the person who merges it, it can be fixed up by the authors.

*  Copy `0000-template.md` to `rfcs/0000-my-feature.md`

This comment has been minimized.

@zimbatm

zimbatm Mar 1, 2017

Member

Good point. Fixed in b3db396

@zimbatm

zimbatm Mar 1, 2017

Member

Good point. Fixed in b3db396

This comment has been minimized.

@zimbatm

zimbatm Mar 1, 2017

Member

Ok that's the reason why the RFC needs to be either renamed at the very start or very end: otherwise all the existing comments are being hidden by github. This will be part of the CONTRIBUTING.md or PULL_REQUEST.md so users do the right thing.

@zimbatm

zimbatm Mar 1, 2017

Member

Ok that's the reason why the RFC needs to be either renamed at the very start or very end: otherwise all the existing comments are being hidden by github. This will be part of the CONTRIBUTING.md or PULL_REQUEST.md so users do the right thing.

Show outdated Hide outdated rfcs/0000-rfc-process.md
rubber stamp, and in particular still does not mean the feature will
ultimately be merged; it does mean that in principle all the major
stakeholders have agreed to the feature and are amenable to merging it.

This comment has been minimized.

@nbp

nbp Feb 25, 2017

Member

Ok, I thought that a graphviz document, with comment would be easier to follow. There is one thing which remains to be determine in the following, which is the set of person responsible for accepting or rejecting proposals.

digraph rfc-state {
  /* Draft stage, any newly create RFC is in a draft stage. Provide draft implementation for the project, such as
   *  Nix, Nixpkgs without adding pull request to other repository, but refer to the draft-ed implementation in forked
   *  version of the projects. */
  draft;

  /* Submitted stage, a comity of persons (to be defined) evaluates the feasibility and compare benefits against the
   * drawbacks.  Ideally the peers (buddy, mentors, ...) should have help clear-up the ground for any questions that
   * might be asked by the comity. */
  submitted;

  /* Accepted stage, a comity of persons, agreed with the feasibility and that benefit outweigh the drawback and that a
   * complete implementation would be implemented in the projects. */
  accepted;

  /* Rejected stage, a comity of persons, disagree with the feasibility and/or that the drawbacks outweigh the benefit.
   * The comity should provide a comments explaining the choice. Any reject draft should not be submitted until all 
   * comments are addressed, and not within a period of 3 months (in order to prevent recurrent submissions) */
  rejected;

  /* Abandoned stage, nor the authors nor the peers (buddy, mentor, ...) can think of an alternative to compensate for
   * the rejection comments. */
  abandoned;

  /* Implemented stage, the proposal is available main-stream, and should be the default way of doing. */
  implemented;

  /* Replaced stage, another proposal is implemented and the content of this proposal should be ignored, unless
   * explicitly mentioned by an implemented proposal. */
  replaced;

  draft -> submitted [label="submitted by the author"];
  submitted -> accepted [label="validated by comity"];
  submitted -> rejected [label="rejected by comity"];
  rejected -> draft;

  draft -> abandoned [label="no alternative, or person to pursue"];

  accepted -> implemented [label="all components merged, and the feature is usable"];
  accepted -> replaced [label="better alternative found before the implementation"];
  implemented -> replaced [label="better alternative found after the implementation"];
}
@nbp

nbp Feb 25, 2017

Member

Ok, I thought that a graphviz document, with comment would be easier to follow. There is one thing which remains to be determine in the following, which is the set of person responsible for accepting or rejecting proposals.

digraph rfc-state {
  /* Draft stage, any newly create RFC is in a draft stage. Provide draft implementation for the project, such as
   *  Nix, Nixpkgs without adding pull request to other repository, but refer to the draft-ed implementation in forked
   *  version of the projects. */
  draft;

  /* Submitted stage, a comity of persons (to be defined) evaluates the feasibility and compare benefits against the
   * drawbacks.  Ideally the peers (buddy, mentors, ...) should have help clear-up the ground for any questions that
   * might be asked by the comity. */
  submitted;

  /* Accepted stage, a comity of persons, agreed with the feasibility and that benefit outweigh the drawback and that a
   * complete implementation would be implemented in the projects. */
  accepted;

  /* Rejected stage, a comity of persons, disagree with the feasibility and/or that the drawbacks outweigh the benefit.
   * The comity should provide a comments explaining the choice. Any reject draft should not be submitted until all 
   * comments are addressed, and not within a period of 3 months (in order to prevent recurrent submissions) */
  rejected;

  /* Abandoned stage, nor the authors nor the peers (buddy, mentor, ...) can think of an alternative to compensate for
   * the rejection comments. */
  abandoned;

  /* Implemented stage, the proposal is available main-stream, and should be the default way of doing. */
  implemented;

  /* Replaced stage, another proposal is implemented and the content of this proposal should be ignored, unless
   * explicitly mentioned by an implemented proposal. */
  replaced;

  draft -> submitted [label="submitted by the author"];
  submitted -> accepted [label="validated by comity"];
  submitted -> rejected [label="rejected by comity"];
  rejected -> draft;

  draft -> abandoned [label="no alternative, or person to pursue"];

  accepted -> implemented [label="all components merged, and the feature is usable"];
  accepted -> replaced [label="better alternative found before the implementation"];
  implemented -> replaced [label="better alternative found after the implementation"];
}
Show outdated Hide outdated rfcs/0000-rfc-process.md
1. Does this RFC strike a favorable balance between formality and agility?
2. Does this RFC successfully address the aforementioned issues with the current
informal RFC process?
3. Should we retain rejected RFCs in the archive?

This comment has been minimized.

@nbp

nbp Feb 25, 2017

Member

If so, maybe we should make a directory for draft proposal, in which people work on, and accepting or rejecting would imply moving these files to the proper directory.

-- update: replaced repository by directory

@nbp

nbp Feb 25, 2017

Member

If so, maybe we should make a directory for draft proposal, in which people work on, and accepting or rejecting would imply moving these files to the proper directory.

-- update: replaced repository by directory

@nbp

This comment has been minimized.

Show comment
Hide comment
@nbp

nbp Feb 26, 2017

Member

Just a note, people seems to have started annotating their pull request / issues with the RFC tag:
https://github.com/NixOS/nixpkgs/issues?utf8=%E2%9C%93&q=RFC%20in%3Atitle

I took the current list and sorted the issues / pull requests in 3 categories: Submittable, Draft, and Rejected. I evaluated these based on my personal opinion and the following criteria:

  • the quality of the first comment. (detailed with motivation & others)
  • the impact of the changes. (number of files modified or number of person impacted is high)

Submittable as RFC:

Draft (not actionable, or not described enough) RFC:

Rejected as RFC (should be an ordinary PR):

I also added NixOS/nixpkgs#10851 (submittable) and NixOS/nixpkgs#14000 (rejected) as additional examples. I classified NixOS/nixpkgs#14000 as rejected, even if the change might have been controversial, it did not had impact out-side the limited set of developers/reviewers of this code. It would have been a good RFC, but only as part of a larger plan to introduce overlays, or to add a better cross-compilation support, but not as a single set of commits.

I think this list is a good starting point to qualify precisely what belongs as an RFC or not, and help remove these RFC tags from existing pull requests / issues.

Member

nbp commented Feb 26, 2017

Just a note, people seems to have started annotating their pull request / issues with the RFC tag:
https://github.com/NixOS/nixpkgs/issues?utf8=%E2%9C%93&q=RFC%20in%3Atitle

I took the current list and sorted the issues / pull requests in 3 categories: Submittable, Draft, and Rejected. I evaluated these based on my personal opinion and the following criteria:

  • the quality of the first comment. (detailed with motivation & others)
  • the impact of the changes. (number of files modified or number of person impacted is high)

Submittable as RFC:

Draft (not actionable, or not described enough) RFC:

Rejected as RFC (should be an ordinary PR):

I also added NixOS/nixpkgs#10851 (submittable) and NixOS/nixpkgs#14000 (rejected) as additional examples. I classified NixOS/nixpkgs#14000 as rejected, even if the change might have been controversial, it did not had impact out-side the limited set of developers/reviewers of this code. It would have been a good RFC, but only as part of a larger plan to introduce overlays, or to add a better cross-compilation support, but not as a single set of commits.

I think this list is a good starting point to qualify precisely what belongs as an RFC or not, and help remove these RFC tags from existing pull requests / issues.

@aneeshusa

This comment has been minimized.

Show comment
Hide comment
@aneeshusa

aneeshusa Feb 26, 2017

👍 from me for this effort! Can we please add a LICENSE (say Apache 2) up front? It's a lot harder to do down the line (see rust-lang/rfcs#1259 for example).

👍 from me for this effort! Can we please add a LICENSE (say Apache 2) up front? It's a lot harder to do down the line (see rust-lang/rfcs#1259 for example).

Show outdated Hide outdated rfcs/0000-rfc-process.md
the Nix ecosystem. What constitutes a "substantial" change is evolving based
on community norms, but may include the following.
- Any semantic or syntactic change to the language that is not a bugfix.

This comment has been minimized.

@aneeshusa

aneeshusa Feb 26, 2017

style nit: remove trailing period for consistency

@aneeshusa

aneeshusa Feb 26, 2017

style nit: remove trailing period for consistency

This comment has been minimized.

@zimbatm

zimbatm Mar 1, 2017

Member

thanks, fixed as part of 983dca3

@zimbatm

zimbatm Mar 1, 2017

Member

thanks, fixed as part of 983dca3

zimbatm added some commits Mar 1, 2017

Temporary Revert "Fix RFC number"
This reverts commit f85da8d.

This is to avoid hiding all the existing comments on github
@zimbatm

This comment has been minimized.

Show comment
Hide comment
@zimbatm

zimbatm Mar 1, 2017

Member

Please vote: is AsciiDoctor an acceptable alternative text format on top of Markdown? In some cases like here it would be nice to have a bit more markup to express things like diagrams and list definitions.

Member

zimbatm commented Mar 1, 2017

Please vote: is AsciiDoctor an acceptable alternative text format on top of Markdown? In some cases like here it would be nice to have a bit more markup to express things like diagrams and list definitions.

@aneeshusa

This comment has been minimized.

Show comment
Hide comment
@aneeshusa

aneeshusa Mar 1, 2017

I'm not sure about how one would layer AsciiDoctor on top of Markdown (i.e. in .md files), but I'd definitely like it as an alternative (i.e. .adoc files).

I'm not sure about how one would layer AsciiDoctor on top of Markdown (i.e. in .md files), but I'd definitely like it as an alternative (i.e. .adoc files).

@zimbatm

This comment has been minimized.

Show comment
Hide comment
@zimbatm

zimbatm Mar 1, 2017

Member

Yes that would be as an alternative. The downside would be to maintain two template files.

Member

zimbatm commented Mar 1, 2017

Yes that would be as an alternative. The downside would be to maintain two template files.

@nbp

This comment has been minimized.

Show comment
Hide comment
@nbp

nbp Mar 4, 2017

Member

I would prefer a single format, in order to avoid having to define one reference, and potentially have different versions. Do we expect much RFC to have content which is defined graphically? Could we just provided an image as part of the RFC?

Member

nbp commented Mar 4, 2017

I would prefer a single format, in order to avoid having to define one reference, and potentially have different versions. Do we expect much RFC to have content which is defined graphically? Could we just provided an image as part of the RFC?

@FRidh

This comment has been minimized.

Show comment
Hide comment
@FRidh

FRidh Mar 10, 2017

Member

@abbradar not if you go to the tab "Files changed" https://github.com/zimbatm/rfcs/pull/1/files

Member

FRidh commented Mar 10, 2017

@abbradar not if you go to the tab "Files changed" https://github.com/zimbatm/rfcs/pull/1/files

@zimbatm zimbatm removed the need co-author label Mar 11, 2017

@vcunat

I'd really prefer to avoid voting (more in comments).

Otherwise I think we should cut this (soon); improvements can come later.

@zimbatm

This comment has been minimized.

Show comment
Hide comment
@zimbatm

zimbatm Mar 11, 2017

Member

Please review c28db71 which removes the voting condition. For now let's aim for a general consensus instead.

Member

zimbatm commented Mar 11, 2017

Please review c28db71 which removes the voting condition. For now let's aim for a general consensus instead.

@zimbatm

This comment has been minimized.

Show comment
Hide comment
@zimbatm

zimbatm Mar 11, 2017

Member

Thanks @vcunat @FRidh and @abbradar for the new comments, it definitely made the RFC better.

Unless some major objections come up I hope that next week will see the RFC officially merged.

Member

zimbatm commented Mar 11, 2017

Thanks @vcunat @FRidh and @abbradar for the new comments, it definitely made the RFC better.

Unless some major objections come up I hope that next week will see the RFC officially merged.

@zimbatm zimbatm added status: ready and removed status: draft labels Mar 11, 2017

Show outdated Hide outdated rfcs/0000-rfc-process.md
that will help them bring the RFC to completion. The goal is to improve the
chances that the RFC is both desired and likely to be implemented.
Once the author is happy with the state of the RFC, she/he should seek for

This comment has been minimized.

@FRidh

FRidh Mar 16, 2017

Member

she/he -> they

@FRidh

FRidh Mar 16, 2017

Member

she/he -> they

This comment has been minimized.

Show outdated Hide outdated rfcs/0000-rfc-process.md
the mailing-list and IRC is an acceptable way of doing that.
After a number of rounds of review the discussion should settle and a general
consensus should emerge. This bit is left intentionnaly vague and should be

This comment has been minimized.

@FRidh

FRidh Mar 16, 2017

Member

intentionally

@FRidh

FRidh Mar 16, 2017

Member

intentionally

This comment has been minimized.

* Commit everything.
If a RFC is rejected, whoever merges the RFC should do the following:
* Move the rfc to the rejected folder

This comment has been minimized.

@FRidh

FRidh Mar 16, 2017

Member

If the status is rejected then what's the point of putting it in a separate folder? And how about other statuses? Will they also be put in separate folders?

@FRidh

FRidh Mar 16, 2017

Member

If the status is rejected then what's the point of putting it in a separate folder? And how about other statuses? Will they also be put in separate folders?

This comment has been minimized.

@vcunat

vcunat Mar 16, 2017

Member

What other statuses? In the beginning they're unmerged and they should get either merged (among accepted) or "merged" into the rejected folder.

@vcunat

vcunat Mar 16, 2017

Member

What other statuses? In the beginning they're unmerged and they should get either merged (among accepted) or "merged" into the rejected folder.

This comment has been minimized.

@vcunat

vcunat Mar 16, 2017

Member

From previous discussion it seemed useful that we somehow "permanently record" each rejected proposal with a summary of arguments, including why it was rejected. Keeping all the information just in PR discussion threads has some disadvantages.

@vcunat

vcunat Mar 16, 2017

Member

From previous discussion it seemed useful that we somehow "permanently record" each rejected proposal with a summary of arguments, including why it was rejected. Keeping all the information just in PR discussion threads has some disadvantages.

This comment has been minimized.

@zimbatm

zimbatm Mar 18, 2017

Member

Just to restate the goal: the goal is to keep a record of any unsuccessful PRs because on github it's possible for the submitter of the PR to remove the original code and then the context is lost.

In that regards, the rejected folder should contain any RFC that is not accepted. It would also include abandoned RFCs. If you have a better name for it I'm happy to change it.

@zimbatm

zimbatm Mar 18, 2017

Member

Just to restate the goal: the goal is to keep a record of any unsuccessful PRs because on github it's possible for the submitter of the PR to remove the original code and then the context is lost.

In that regards, the rejected folder should contain any RFC that is not accepted. It would also include abandoned RFCs. If you have a better name for it I'm happy to change it.

This comment has been minimized.

@FRidh

FRidh Mar 18, 2017

Member

I'm of the opinion we should merge RFC's sooner and assign them a draft status.

@FRidh

FRidh Mar 18, 2017

Member

I'm of the opinion we should merge RFC's sooner and assign them a draft status.

Show outdated Hide outdated rfcs/0000-rfc-process.md
## Role of the "co-author"
To goal for assigning a "co-author" is to help move the RFC along.

This comment has been minimized.

@FRidh

FRidh Mar 16, 2017

Member

The goal

@FRidh

FRidh Mar 16, 2017

Member

The goal

This comment has been minimized.

@zimbatm

zimbatm Mar 18, 2017

Member

thanks, fixed in 0b188c5

@zimbatm

zimbatm Mar 18, 2017

Member

thanks, fixed in 0b188c5

@edolstra

This comment has been minimized.

Show comment
Hide comment
@edolstra

edolstra Mar 17, 2017

Member

Looks good to me. The main remaining issue is that it leaves the decision procedure unspecified, but I agree we can leave that for now. The risk is that it creates the same problem as the current PR system (i.e. that PRs stay in limbo with no clear decision), but at least it's an improvement to require a general consensus, instead of the current situation where any of a few dozen committer can merge controversial changes.

Who should have write access to the rfcs repo?

Member

edolstra commented Mar 17, 2017

Looks good to me. The main remaining issue is that it leaves the decision procedure unspecified, but I agree we can leave that for now. The risk is that it creates the same problem as the current PR system (i.e. that PRs stay in limbo with no clear decision), but at least it's an improvement to require a general consensus, instead of the current situation where any of a few dozen committer can merge controversial changes.

Who should have write access to the rfcs repo?

@vcunat

This comment has been minimized.

Show comment
Hide comment
@vcunat

vcunat Mar 17, 2017

Member

any of a few dozen committer can merge controversial changes

This will still be able to, technically, but I think everyone has been following an implicit rule that controversial changes aren't merged without wider approval.

Member

vcunat commented Mar 17, 2017

any of a few dozen committer can merge controversial changes

This will still be able to, technically, but I think everyone has been following an implicit rule that controversial changes aren't merged without wider approval.

@layus

This comment has been minimized.

Show comment
Hide comment
@layus

layus Mar 17, 2017

Contributor

[...], but I think everyone has been following an implicit rule that controversial changes aren't merged without wider approval.

Yes and not. For two different PR introducing similar changes, I have seen one stalling under controversial discussions, and the second one getting merged by another committer unaware of the discussion.

Contributor

layus commented Mar 17, 2017

[...], but I think everyone has been following an implicit rule that controversial changes aren't merged without wider approval.

Yes and not. For two different PR introducing similar changes, I have seen one stalling under controversial discussions, and the second one getting merged by another committer unaware of the discussion.

@vcunat

This comment has been minimized.

Show comment
Hide comment
@vcunat

vcunat Mar 18, 2017

Member

I suppose it was a case not considered controversial by the merging side, but it's still good to get things a bit more standardized. (I personally tend to be more careful with my merges than what's usual, I think, even if the changes aren't "controversial".)

Member

vcunat commented Mar 18, 2017

I suppose it was a case not considered controversial by the merging side, but it's still good to get things a bit more standardized. (I personally tend to be more careful with my merges than what's usual, I think, even if the changes aren't "controversial".)

@zimbatm

This comment has been minimized.

Show comment
Hide comment
@zimbatm

zimbatm Mar 18, 2017

Member

Alright, I think all the remaining issues have been fixed now. Time for merging!!!

Member

zimbatm commented Mar 18, 2017

Alright, I think all the remaining issues have been fixed now. Time for merging!!!

@zimbatm zimbatm merged commit b682a8d into master Mar 18, 2017

zimbatm added a commit that referenced this pull request Mar 18, 2017

@zimbatm

This comment has been minimized.

Show comment
Hide comment
@zimbatm

zimbatm Mar 18, 2017

Member

@edolstra I sent you an invite for the repo, this will let you move it to the NixOS org.

In regards to access, since RFCs are mainly a communication tool I would suggest just giving the same access as nixpkgs. I think that having a core team would be helpful to make executive decisions when necessary but that can be defined in another RFC along with their responsibilities and process to join/leave the core team.

Member

zimbatm commented Mar 18, 2017

@edolstra I sent you an invite for the repo, this will let you move it to the NixOS org.

In regards to access, since RFCs are mainly a communication tool I would suggest just giving the same access as nixpkgs. I think that having a core team would be helpful to make executive decisions when necessary but that can be defined in another RFC along with their responsibilities and process to join/leave the core team.

@fpletz

This comment has been minimized.

Show comment
Hide comment
@fpletz

fpletz Mar 25, 2017

Member

Ping. What's the problem in migrating this to the NixOS organization? We have reached a rough consensus in the community for the RFC process. This should be a good start.

cc @rbvermaa

Member

fpletz commented Mar 25, 2017

Ping. What's the problem in migrating this to the NixOS organization? We have reached a rough consensus in the community for the RFC process. This should be a good start.

cc @rbvermaa

@domenkozar

This comment has been minimized.

Show comment
Hide comment
@domenkozar

domenkozar Mar 25, 2017

Member

I can migrate if @edolstra agrees :)

Member

domenkozar commented Mar 25, 2017

I can migrate if @edolstra agrees :)

@edolstra

This comment has been minimized.

Show comment
Hide comment
@edolstra

edolstra Mar 27, 2017

Member

@domenkozar Yes please do.

Member

edolstra commented Mar 27, 2017

@domenkozar Yes please do.

@domenkozar

This comment has been minimized.

Show comment
Hide comment
@domenkozar

domenkozar Mar 27, 2017

Member

@zimbatm can you give me admin access to this repo?

Member

domenkozar commented Mar 27, 2017

@zimbatm can you give me admin access to this repo?

@domenkozar

This comment has been minimized.

Show comment
Hide comment
@domenkozar

domenkozar Mar 27, 2017

Member

Done.

Member

domenkozar commented Mar 27, 2017

Done.

@vcunat

This comment has been minimized.

Show comment
Hide comment
@vcunat

vcunat Mar 27, 2017

Member

GitHub now nicely redirects from the old links :-)

Member

vcunat commented Mar 27, 2017

GitHub now nicely redirects from the old links :-)

dtzWill referenced this pull request in dtzWill/rfcs Feb 22, 2018

rfc: weaken claim about glibc future direction
I'm not sure about the political stances implied,
and regardless as the #1 glibc there is a huge amount
of software that isn't going to change between now and
any reasonably near future :).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment