Alternative voting reform: Streamlining the RFC process

5 years ago by Nikita Popov — view source

unread

Hi internals,

After discussing the topic with a number of current and former
contributors, I feel that the workflow & voting RFC currently under
discussion is moving us in the wrong direction. I will not comment on the
rather questionable proposed changes to voting eligibility, as these are
already extensively discussed in the RFC thread.

The remainder of the workflow & voting RFC is mostly concerned with
defining stricter rules and more rigid procedures for the RFC process. It
increases the amount of bureaucracy and overhead involved in the RFC
process, making the RFC processes even less suitable for smaller changes
than it already is.

The proposal I would like to present in the following is not my own idea,
it has been suggested by Anthony Ferrara. Because I found the idea very
compelling, I'm presenting it to the list now.

Instead of making the RFC process more complex and rigid, we should
simplify and streamline it. The RFC process is reduced to only two rules:

All primary RFC votes require a 2/3 majority, while secondary votes
resolving implementation details may use a simple majority. (This is
already proposed in the voting margins RFC, so discussion about this point
should be directed into the corresponding RFC thread.)
All RFCs must have a voting period of at least 14 days, announced in a
separate [VOTE] thread.

That's it. More notable than the rules itself are probably the two main
omissions:

There is no required discussion period. However, if an RFC vote is
opened without leaving enough time for discussion, then voters can and
should vote the RFC down on the grounds of insufficient discussion.

The motivation for not having a fixed discussion period (but a longer
minimum voting period) is that RFCs come in many different forms and sizes.
Some RFCs are long and complex (such as the recent typed properties RFC)
and require more time for an adequate discussion. Other RFCs are simple and
of limited scope (such as an extension function addition) and do not
require extensive discussion.

While a two week discussion period should remain a good guideline for
language-related RFCs, it is up to the RFC author to decide when opening an
RFC vote is appropriate. This will depend both on the scope of the RFC
itself and the activity of the discussion. (It is an unfortunate fact that
many RFCs receive their first meaningful feedback during the voting period.)

There is no moratorium period after an RFC vote fails. If you think that
you have made significant progress on an RFC and resolved the issues that
made the previous vote fail, you can give it another shot at any time,
without having to wait out some fixed period.

A failed vote does not (necessarily) mean that a feature is not wanted. It
is quite common for significant changes to fail on first vote, due to
issues in the initial proposal. A failed vote should not be a
discouragement, but a motivation to address problems expressed during
discussion or voting.

It should go without saying that if you restart a failed RFC vote without
making substantial changes to the RFC, the result is unlikely to change in
your favor, and that continued misbehavior might be seen as spam.

Essentially, this is about making the RFC process more suitable for changes
small and large, and empowering both RFC authors and the voter base to make
decisions that are appropriate for each RFC.

What do you think?

Regards,
Nikita

5 years ago by Joe Watkins — view source

unread

Afternoon Nikita, internals,

In stark contrast to the proposals being made to make contributing to PHP
more complex, slower, and burdened with bureaucracy: These are elegant
proposals that I think will invite new contributors to join our ranks,
which we no doubt need. They will allow current contributors to work faster
on PHP without reducing the quality of their work or the input the rest of
internals has on their contributions. I would hope that it would reduce the
number of RFC that sit on the Wiki for years at a time also, but this is
only my hope.

While these are quite drastic changes, let us try to resist a knee jerk
response to them.

From me, it's +1

Cheers
Joe

Hi internals,

After discussing the topic with a number of current and former
contributors, I feel that the workflow & voting RFC currently under
discussion is moving us in the wrong direction. I will not comment on the
rather questionable proposed changes to voting eligibility, as these are
already extensively discussed in the RFC thread.

The remainder of the workflow & voting RFC is mostly concerned with
defining stricter rules and more rigid procedures for the RFC process. It
increases the amount of bureaucracy and overhead involved in the RFC
process, making the RFC processes even less suitable for smaller changes
than it already is.

The proposal I would like to present in the following is not my own idea,
it has been suggested by Anthony Ferrara. Because I found the idea very
compelling, I'm presenting it to the list now.

Instead of making the RFC process more complex and rigid, we should
simplify and streamline it. The RFC process is reduced to only two rules:

All primary RFC votes require a 2/3 majority, while secondary votes
resolving implementation details may use a simple majority. (This is
already proposed in the voting margins RFC, so discussion about this point
should be directed into the corresponding RFC thread.)

All RFCs must have a voting period of at least 14 days, announced in a
separate [VOTE] thread.

That's it. More notable than the rules itself are probably the two main
omissions:

There is no required discussion period. However, if an RFC vote is
opened without leaving enough time for discussion, then voters can and
should vote the RFC down on the grounds of insufficient discussion.

The motivation for not having a fixed discussion period (but a longer
minimum voting period) is that RFCs come in many different forms and sizes.
Some RFCs are long and complex (such as the recent typed properties RFC)
and require more time for an adequate discussion. Other RFCs are simple and
of limited scope (such as an extension function addition) and do not
require extensive discussion.

While a two week discussion period should remain a good guideline for
language-related RFCs, it is up to the RFC author to decide when opening an
RFC vote is appropriate. This will depend both on the scope of the RFC
itself and the activity of the discussion. (It is an unfortunate fact that
many RFCs receive their first meaningful feedback during the voting
period.)

There is no moratorium period after an RFC vote fails. If you think that
you have made significant progress on an RFC and resolved the issues that
made the previous vote fail, you can give it another shot at any time,
without having to wait out some fixed period.

A failed vote does not (necessarily) mean that a feature is not wanted. It
is quite common for significant changes to fail on first vote, due to
issues in the initial proposal. A failed vote should not be a
discouragement, but a motivation to address problems expressed during
discussion or voting.

It should go without saying that if you restart a failed RFC vote without
making substantial changes to the RFC, the result is unlikely to change in
your favor, and that continued misbehavior might be seen as spam.

Essentially, this is about making the RFC process more suitable for changes
small and large, and empowering both RFC authors and the voter base to make
decisions that are appropriate for each RFC.

What do you think?

Regards,
Nikita

5 years ago by Arvids Godjuks — view source

unread

сб, 2 февр. 2019 г. в 18:24, Nikita Popov nikita.ppv@gmail.com:

Hi internals,

After discussing the topic with a number of current and former
contributors, I feel that the workflow & voting RFC currently under
discussion is moving us in the wrong direction. I will not comment on the
rather questionable proposed changes to voting eligibility, as these are
already extensively discussed in the RFC thread.

The remainder of the workflow & voting RFC is mostly concerned with
defining stricter rules and more rigid procedures for the RFC process. It
increases the amount of bureaucracy and overhead involved in the RFC
process, making the RFC processes even less suitable for smaller changes
than it already is.

The proposal I would like to present in the following is not my own idea,
it has been suggested by Anthony Ferrara. Because I found the idea very
compelling, I'm presenting it to the list now.

Instead of making the RFC process more complex and rigid, we should
simplify and streamline it. The RFC process is reduced to only two rules:

All primary RFC votes require a 2/3 majority, while secondary votes
resolving implementation details may use a simple majority. (This is
already proposed in the voting margins RFC, so discussion about this point
should be directed into the corresponding RFC thread.)

All RFCs must have a voting period of at least 14 days, announced in a
separate [VOTE] thread.

That's it. More notable than the rules itself are probably the two main
omissions:

There is no required discussion period. However, if an RFC vote is
opened without leaving enough time for discussion, then voters can and
should vote the RFC down on the grounds of insufficient discussion.

The motivation for not having a fixed discussion period (but a longer
minimum voting period) is that RFCs come in many different forms and sizes.
Some RFCs are long and complex (such as the recent typed properties RFC)
and require more time for an adequate discussion. Other RFCs are simple and
of limited scope (such as an extension function addition) and do not
require extensive discussion.

While a two week discussion period should remain a good guideline for
language-related RFCs, it is up to the RFC author to decide when opening an
RFC vote is appropriate. This will depend both on the scope of the RFC
itself and the activity of the discussion. (It is an unfortunate fact that
many RFCs receive their first meaningful feedback during the voting
period.)

There is no moratorium period after an RFC vote fails. If you think that
you have made significant progress on an RFC and resolved the issues that
made the previous vote fail, you can give it another shot at any time,
without having to wait out some fixed period.

A failed vote does not (necessarily) mean that a feature is not wanted. It
is quite common for significant changes to fail on first vote, due to
issues in the initial proposal. A failed vote should not be a
discouragement, but a motivation to address problems expressed during
discussion or voting.

It should go without saying that if you restart a failed RFC vote without
making substantial changes to the RFC, the result is unlikely to change in
your favor, and that continued misbehavior might be seen as spam.

Essentially, this is about making the RFC process more suitable for changes
small and large, and empowering both RFC authors and the voter base to make
decisions that are appropriate for each RFC.

What do you think?

Regards,
Nikita

Hello Nikita, internals,

as a user-land developer and at least a decade reader of internals (and
basically seen it all on here) and occasional poster, I highly approve of
your proposal. I like it very much.

To me, this represents a great move towards a less bureaucratic and
edge-case prone process, that requires a high bar of approval from the
internal's community and ability to iterate on complex RFC's at a decent
pace and not hinder small easy changes that are relatively a no-brainer
like it is right now.

I literally see no holes or edge cases in this proposal. Though I can't
vote, this is a big +1 from me and a hope that this will calm down
internals list going forward after what has happened this past week.

--
Arvīds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

5 years ago by Legale Legage — view source

unread

Hello, internals.
I am with you recently. But as a person with a fresh look, let me insert my
5 penny coin.
About half a year ago, I knew about the C language only that such a
language exists.
The reason I decided to contribute is curiosity. So I'm probably not as
motivated
as some of other internals. I want to say that even a small and fairly
simple code change,
which I proposed to push through the bureaucracy, was difficult. So If RFC
process
becomes more difficult this "road" will be closed for some sort of random
people like me.
I hope this doesn't happen.

Best regards, Ruslan

Hi internals,

After discussing the topic with a number of current and former
contributors, I feel that the workflow & voting RFC currently under
discussion is moving us in the wrong direction. I will not comment on the
rather questionable proposed changes to voting eligibility, as these are
already extensively discussed in the RFC thread.

The remainder of the workflow & voting RFC is mostly concerned with
defining stricter rules and more rigid procedures for the RFC process. It
increases the amount of bureaucracy and overhead involved in the RFC
process, making the RFC processes even less suitable for smaller changes
than it already is.

The proposal I would like to present in the following is not my own idea,
it has been suggested by Anthony Ferrara. Because I found the idea very
compelling, I'm presenting it to the list now.

Instead of making the RFC process more complex and rigid, we should
simplify and streamline it. The RFC process is reduced to only two rules:

All primary RFC votes require a 2/3 majority, while secondary votes
resolving implementation details may use a simple majority. (This is
already proposed in the voting margins RFC, so discussion about this point
should be directed into the corresponding RFC thread.)

All RFCs must have a voting period of at least 14 days, announced in a
separate [VOTE] thread.

That's it. More notable than the rules itself are probably the two main
omissions:

There is no required discussion period. However, if an RFC vote is
opened without leaving enough time for discussion, then voters can and
should vote the RFC down on the grounds of insufficient discussion.

The motivation for not having a fixed discussion period (but a longer
minimum voting period) is that RFCs come in many different forms and sizes.
Some RFCs are long and complex (such as the recent typed properties RFC)
and require more time for an adequate discussion. Other RFCs are simple and
of limited scope (such as an extension function addition) and do not
require extensive discussion.

While a two week discussion period should remain a good guideline for
language-related RFCs, it is up to the RFC author to decide when opening an
RFC vote is appropriate. This will depend both on the scope of the RFC
itself and the activity of the discussion. (It is an unfortunate fact that
many RFCs receive their first meaningful feedback during the voting
period.)

There is no moratorium period after an RFC vote fails. If you think that
you have made significant progress on an RFC and resolved the issues that
made the previous vote fail, you can give it another shot at any time,
without having to wait out some fixed period.

A failed vote does not (necessarily) mean that a feature is not wanted. It
is quite common for significant changes to fail on first vote, due to
issues in the initial proposal. A failed vote should not be a
discouragement, but a motivation to address problems expressed during
discussion or voting.

It should go without saying that if you restart a failed RFC vote without
making substantial changes to the RFC, the result is unlikely to change in
your favor, and that continued misbehavior might be seen as spam.

Essentially, this is about making the RFC process more suitable for changes
small and large, and empowering both RFC authors and the voter base to make
decisions that are appropriate for each RFC.

What do you think?

Regards,
Nikita

5 years ago by Joe Watkins — view source

unread

Hi Legale, internals,

I want to say that even a small and fairly
simple code change,
which I proposed to push through the bureaucracy, was difficult.

This, I am afraid is all too common. Many many times, while working through
github issues, I will be uncomfortable with making a merge for someone
without input from internals. I would tell that person to start a
discussion on internals and they would be flat ignored, their change dead
in the water, and their reason to continue contributing evaporates.

I think these proposals have a chance of reducing the occurrences of those
situations: We all know that for less interesting topics, vote time is
crunch time and that is when internals pays attention. If there is no
necessity to wait for X weeks between proposing a change that nobody really
has a desire to discuss, and opening a vote, that person can move forward
quickly, we get our bug/quick fix faster, everyone is happy, especially
that contributor who feels valued, and who feels that PHP's development
process is geared toward actual development of PHP.

Cheers
Joe

Hello, internals.
I am with you recently. But as a person with a fresh look, let me insert my
5 penny coin.
About half a year ago, I knew about the C language only that such a
language exists.
The reason I decided to contribute is curiosity. So I'm probably not as
motivated
as some of other internals. I want to say that even a small and fairly
simple code change,
which I proposed to push through the bureaucracy, was difficult. So If RFC
process
becomes more difficult this "road" will be closed for some sort of random
people like me.
I hope this doesn't happen.

Best regards, Ruslan

Hi internals,

After discussing the topic with a number of current and former
contributors, I feel that the workflow & voting RFC currently under
discussion is moving us in the wrong direction. I will not comment on the
rather questionable proposed changes to voting eligibility, as these are
already extensively discussed in the RFC thread.

The remainder of the workflow & voting RFC is mostly concerned with
defining stricter rules and more rigid procedures for the RFC process. It
increases the amount of bureaucracy and overhead involved in the RFC
process, making the RFC processes even less suitable for smaller changes
than it already is.

The proposal I would like to present in the following is not my own idea,
it has been suggested by Anthony Ferrara. Because I found the idea very
compelling, I'm presenting it to the list now.

Instead of making the RFC process more complex and rigid, we should
simplify and streamline it. The RFC process is reduced to only two rules:

All primary RFC votes require a 2/3 majority, while secondary votes
resolving implementation details may use a simple majority. (This is
already proposed in the voting margins RFC, so discussion about this
point
should be directed into the corresponding RFC thread.)

All RFCs must have a voting period of at least 14 days, announced in a
separate [VOTE] thread.

That's it. More notable than the rules itself are probably the two main
omissions:

There is no required discussion period. However, if an RFC vote is
opened without leaving enough time for discussion, then voters can and
should vote the RFC down on the grounds of insufficient discussion.

The motivation for not having a fixed discussion period (but a longer
minimum voting period) is that RFCs come in many different forms and
sizes.
Some RFCs are long and complex (such as the recent typed properties RFC)
and require more time for an adequate discussion. Other RFCs are simple
and
of limited scope (such as an extension function addition) and do not
require extensive discussion.

While a two week discussion period should remain a good guideline for
language-related RFCs, it is up to the RFC author to decide when opening
an
RFC vote is appropriate. This will depend both on the scope of the RFC
itself and the activity of the discussion. (It is an unfortunate fact
that
many RFCs receive their first meaningful feedback during the voting
period.)

There is no moratorium period after an RFC vote fails. If you think
that
you have made significant progress on an RFC and resolved the issues that
made the previous vote fail, you can give it another shot at any time,
without having to wait out some fixed period.

A failed vote does not (necessarily) mean that a feature is not wanted.
It
is quite common for significant changes to fail on first vote, due to
issues in the initial proposal. A failed vote should not be a
discouragement, but a motivation to address problems expressed during
discussion or voting.

It should go without saying that if you restart a failed RFC vote without
making substantial changes to the RFC, the result is unlikely to change
in
your favor, and that continued misbehavior might be seen as spam.

Essentially, this is about making the RFC process more suitable for
changes
small and large, and empowering both RFC authors and the voter base to
make
decisions that are appropriate for each RFC.

What do you think?

Regards,
Nikita

5 years ago by Joe Watkins — view source

unread

Just a quick note ...

I should say that bug fixes should not require an RFC at all, but the line
between bug, quick fix and feature is blurry. Sometimes it is necessary to
gather consensus and voting is the most effective way we have to do that.

Cheers
Joe

Hi Legale, internals,

I want to say that even a small and fairly
simple code change,
which I proposed to push through the bureaucracy, was difficult.

This, I am afraid is all too common. Many many times, while working
through github issues, I will be uncomfortable with making a merge for
someone without input from internals. I would tell that person to start a
discussion on internals and they would be flat ignored, their change dead
in the water, and their reason to continue contributing evaporates.

I think these proposals have a chance of reducing the occurrences of those
situations: We all know that for less interesting topics, vote time is
crunch time and that is when internals pays attention. If there is no
necessity to wait for X weeks between proposing a change that nobody really
has a desire to discuss, and opening a vote, that person can move forward
quickly, we get our bug/quick fix faster, everyone is happy, especially
that contributor who feels valued, and who feels that PHP's development
process is geared toward actual development of PHP.

Cheers
Joe

On Sat, 2 Feb 2019 at 18:02, Legale Legage legale.legale@gmail.com
wrote:

Hello, internals.
I am with you recently. But as a person with a fresh look, let me insert
my
5 penny coin.
About half a year ago, I knew about the C language only that such a
language exists.
The reason I decided to contribute is curiosity. So I'm probably not as
motivated
as some of other internals. I want to say that even a small and fairly
simple code change,
which I proposed to push through the bureaucracy, was difficult. So If RFC
process
becomes more difficult this "road" will be closed for some sort of random
people like me.
I hope this doesn't happen.

Best regards, Ruslan

Hi internals,

After discussing the topic with a number of current and former
contributors, I feel that the workflow & voting RFC currently under
discussion is moving us in the wrong direction. I will not comment on
the
rather questionable proposed changes to voting eligibility, as these are
already extensively discussed in the RFC thread.

The remainder of the workflow & voting RFC is mostly concerned with
defining stricter rules and more rigid procedures for the RFC process.
It
increases the amount of bureaucracy and overhead involved in the RFC
process, making the RFC processes even less suitable for smaller changes
than it already is.

The proposal I would like to present in the following is not my own
idea,
it has been suggested by Anthony Ferrara. Because I found the idea very
compelling, I'm presenting it to the list now.

Instead of making the RFC process more complex and rigid, we should
simplify and streamline it. The RFC process is reduced to only two
rules:

All primary RFC votes require a 2/3 majority, while secondary votes
resolving implementation details may use a simple majority. (This is
already proposed in the voting margins RFC, so discussion about this
point
should be directed into the corresponding RFC thread.)

All RFCs must have a voting period of at least 14 days, announced in
a
separate [VOTE] thread.

That's it. More notable than the rules itself are probably the two main
omissions:

There is no required discussion period. However, if an RFC vote is
opened without leaving enough time for discussion, then voters can and
should vote the RFC down on the grounds of insufficient discussion.

The motivation for not having a fixed discussion period (but a longer
minimum voting period) is that RFCs come in many different forms and
sizes.
Some RFCs are long and complex (such as the recent typed properties RFC)
and require more time for an adequate discussion. Other RFCs are simple
and
of limited scope (such as an extension function addition) and do not
require extensive discussion.

While a two week discussion period should remain a good guideline for
language-related RFCs, it is up to the RFC author to decide when
opening an
RFC vote is appropriate. This will depend both on the scope of the RFC
itself and the activity of the discussion. (It is an unfortunate fact
that
many RFCs receive their first meaningful feedback during the voting
period.)

There is no moratorium period after an RFC vote fails. If you think
that
you have made significant progress on an RFC and resolved the issues
that
made the previous vote fail, you can give it another shot at any time,
without having to wait out some fixed period.

A failed vote does not (necessarily) mean that a feature is not wanted.
It
is quite common for significant changes to fail on first vote, due to
issues in the initial proposal. A failed vote should not be a
discouragement, but a motivation to address problems expressed during
discussion or voting.

It should go without saying that if you restart a failed RFC vote
without
making substantial changes to the RFC, the result is unlikely to change
in
your favor, and that continued misbehavior might be seen as spam.

Essentially, this is about making the RFC process more suitable for
changes
small and large, and empowering both RFC authors and the voter base to
make
decisions that are appropriate for each RFC.

What do you think?

Regards,
Nikita

5 years ago by Stanislav Malyshev — view source

unread

Hi!

I want to say that even a small and fairly
simple code change,
which I proposed to push through the bureaucracy, was difficult.

We're discussing RFCs. Small and fairly simple code change does not need
an RFC. So either:

a) this change is indeed small and simple, and does not belong to the
topic about RFC process, maybe about code review process, which is no
less important, but different talk.

b) this change wasn't as small and simple as it appeared, it did require
the RFC, but you didn't know that. It's not your fault, no shame here -
but this shows the process worked as it should have.

This, I am afraid is all too common. Many many times, while working through
github issues, I will be uncomfortable with making a merge for someone
without input from internals. I would tell that person to start a
discussion on internals and they would be flat ignored, their change dead
in the water, and their reason to continue contributing evaporates.

But how this relates to RFCs? Certainly not every patch needs an RFC.

--
Stas Malyshev
smalyshev@gmail.com

5 years ago by Benjamin Eberlei — view source

unread

On Mon, Feb 4, 2019 at 9:00 AM Stanislav Malyshev smalyshev@gmail.com
wrote:

Hi!

I want to say that even a small and fairly
simple code change,
which I proposed to push through the bureaucracy, was difficult.

We're discussing RFCs. Small and fairly simple code change does not need
an RFC.

I think this is what Nikita wants to change with this simpler procedure.
More RFCs even on smaller changes, so that more broad input can be gathered
before doing any kind of change.

So either:

a) this change is indeed small and simple, and does not belong to the
topic about RFC process, maybe about code review process, which is no
less important, but different talk.

b) this change wasn't as small and simple as it appeared, it did require
the RFC, but you didn't know that. It's not your fault, no shame here -
but this shows the process worked as it should have.

This, I am afraid is all too common. Many many times, while working
through
github issues, I will be uncomfortable with making a merge for someone
without input from internals. I would tell that person to start a
discussion on internals and they would be flat ignored, their change dead
in the water, and their reason to continue contributing evaporates.

But how this relates to RFCs? Certainly not every patch needs an RFC.

--
Stas Malyshev
smalyshev@gmail.com

5 years ago by Stanislav Malyshev — view source

unread

Hi!

I want to say that even a small and fairly
simple code change,
which I proposed to push through the bureaucracy, was difficult.

I think this is what Nikita wants to change with this simpler procedure.
More RFCs even on smaller changes, so that more broad input can be
gathered before doing any kind of change.

If so, this is IMO a bad idea. We don't need to make contributing
harder, and have a formal two-week vote on each change.
But, since the original quote talks about the past, then it can't be
about RFCs, because in the past we didn't require RFCs for small changes
(and shouldn't in the future).

--
Stas Malyshev
smalyshev@gmail.com

5 years ago by Kris Craig — view source

unread

Now THIS is a sensible proposal! It resolves the biggest issues in a very
simple and straightforward manner. And unlike the other RFC, this proposal
does not feel like an exclusionary power grab.

--Kris

Hi internals,

After discussing the topic with a number of current and former
contributors, I feel that the workflow & voting RFC currently under
discussion is moving us in the wrong direction. I will not comment on the
rather questionable proposed changes to voting eligibility, as these are
already extensively discussed in the RFC thread.

The remainder of the workflow & voting RFC is mostly concerned with
defining stricter rules and more rigid procedures for the RFC process. It
increases the amount of bureaucracy and overhead involved in the RFC
process, making the RFC processes even less suitable for smaller changes
than it already is.

The proposal I would like to present in the following is not my own idea,
it has been suggested by Anthony Ferrara. Because I found the idea very
compelling, I'm presenting it to the list now.

Instead of making the RFC process more complex and rigid, we should
simplify and streamline it. The RFC process is reduced to only two rules:

All primary RFC votes require a 2/3 majority, while secondary votes
resolving implementation details may use a simple majority. (This is
already proposed in the voting margins RFC, so discussion about this point
should be directed into the corresponding RFC thread.)

All RFCs must have a voting period of at least 14 days, announced in a
separate [VOTE] thread.

That's it. More notable than the rules itself are probably the two main
omissions:

There is no required discussion period. However, if an RFC vote is
opened without leaving enough time for discussion, then voters can and
should vote the RFC down on the grounds of insufficient discussion.

The motivation for not having a fixed discussion period (but a longer
minimum voting period) is that RFCs come in many different forms and sizes.
Some RFCs are long and complex (such as the recent typed properties RFC)
and require more time for an adequate discussion. Other RFCs are simple and
of limited scope (such as an extension function addition) and do not
require extensive discussion.

While a two week discussion period should remain a good guideline for
language-related RFCs, it is up to the RFC author to decide when opening an
RFC vote is appropriate. This will depend both on the scope of the RFC
itself and the activity of the discussion. (It is an unfortunate fact that
many RFCs receive their first meaningful feedback during the voting
period.)

There is no moratorium period after an RFC vote fails. If you think that
you have made significant progress on an RFC and resolved the issues that
made the previous vote fail, you can give it another shot at any time,
without having to wait out some fixed period.

A failed vote does not (necessarily) mean that a feature is not wanted. It
is quite common for significant changes to fail on first vote, due to
issues in the initial proposal. A failed vote should not be a
discouragement, but a motivation to address problems expressed during
discussion or voting.

It should go without saying that if you restart a failed RFC vote without
making substantial changes to the RFC, the result is unlikely to change in
your favor, and that continued misbehavior might be seen as spam.

Essentially, this is about making the RFC process more suitable for changes
small and large, and empowering both RFC authors and the voter base to make
decisions that are appropriate for each RFC.

What do you think?

Regards,
Nikita

5 years ago by Zeev Suraski — view source

unread

-----Original Message-----
From: Nikita Popov nikita.ppv@gmail.com
Sent: Saturday, February 2, 2019 6:24 PM
To: PHP internals internals@lists.php.net
Subject: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

Hi internals,

After discussing the topic with a number of current and former contributors, I
feel that the workflow & voting RFC currently under discussion is moving us in
the wrong direction. I will not comment on the rather questionable proposed
changes to voting eligibility, as these are already extensively discussed in the
RFC thread.

Personally, I find any proposal that does not deal with clearly defining voting eligibility not only questionable, but a non-starter, that has no parallels in any other major Open Source projects.

The suggestion that the new RFC makes life more difficult, compared to the current Voting RFC, is simply wrong. It is, in fact, very much the same - except it's a lot more well defined in terms of 'what happens if' - which in the years since the 2011 Voting RFC was enacted became a de-facto wild-west.

It may initially feel warm & fuzzy to have vague, fluid rules that are remarkably open to interpretation. But it's not a good idea at all.

Zeev

5 years ago by Bob Weinand — view source

unread

Am 03.02.2019 um 06:18 schrieb Zeev Suraski vsuraski@gmail.com:

-----Original Message-----
From: Nikita Popov nikita.ppv@gmail.com
Sent: Saturday, February 2, 2019 6:24 PM
To: PHP internals internals@lists.php.net
Subject: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

Hi internals,

After discussing the topic with a number of current and former contributors, I
feel that the workflow & voting RFC currently under discussion is moving us in
the wrong direction. I will not comment on the rather questionable proposed
changes to voting eligibility, as these are already extensively discussed in the
RFC thread.

Personally, I find any proposal that does not deal with clearly defining voting eligibility not only questionable, but a non-starter, that has no parallels in any other major Open Source projects.

The suggestion that the new RFC makes life more difficult, compared to the current Voting RFC, is simply wrong. It is, in fact, very much the same - except it's a lot more well defined in terms of 'what happens if' - which in the years since the 2011 Voting RFC was enacted became a de-facto wild-west.

It may initially feel warm & fuzzy to have vague, fluid rules that are remarkably open to interpretation. But it's not a good idea at all.

Zeev

Hey Zeev,

why is dealing with voting eligibility a requirement for a new RFC dealing with the RFC process? Everything which is not dealt with, is simply inherited from status quo. And I personally don't think the current rules regarding voting eligibility, while possibly not perfect, are in such a bad state that they immediately need a rework. The door to concrete, separate proposals fixing voting eligibility is not closed with this RFC. You are always free to open a new specific RFC and discuss about a voting eligibility proposal.

In addition, the newly proposed RFC here is absolutely not vague. It is pretty well defined, showing a few clear boundaries. For everything else it is the task of the voter to establish whether a RFC is ready and shall be voted in as is. It's precisely that which makes a great voting process. In particular with a 2/3 required majority, I strongly doubt that bullshit RFCs which are quickly proposed and moved to vote, will ever be accepted. I trust our voters enough to know when something should definitely not be accepted.

And I strongly hope that you are not lacking faith in us PHP RFC voters, that you feel like you couldn't trust us to apply sensible judgement to each RFC.

Thanks,
Bob

5 years ago by Nikita Popov — view source

unread

-----Original Message-----
From: Nikita Popov nikita.ppv@gmail.com
Sent: Saturday, February 2, 2019 6:24 PM
To: PHP internals internals@lists.php.net
Subject: [PHP-DEV] Alternative voting reform: Streamlining the RFC
process

Hi internals,

After discussing the topic with a number of current and former
contributors, I
feel that the workflow & voting RFC currently under discussion is moving
us in
the wrong direction. I will not comment on the rather questionable
proposed
changes to voting eligibility, as these are already extensively
discussed in the
RFC thread.

Personally, I find any proposal that does not deal with clearly defining
voting eligibility not only questionable, but a non-starter, that has no
parallels in any other major Open Source projects.

Why? While I think the question of voting eligibility is worth discussing
(though I also don't consider the problem pressing in any way and think
that our current pool of voters works quite well, even if it may not be
what people had in mind back then), it is, just like the question of voting
margins, a rather independent issue from the remainder of the process. I
think that these discussions and RFC can and should be split up into the
question of voting margins, the question of voting eligibility and the
question of the RFC procedure itself. While these things are of course
related, they can also be decided independently.

The problem with bundling together these changes is, if you will excuse the
political parallel, akin to bundling changes to copyright enforcement
together with a free trade agreement. Those two things have nothing to do
with each other (though of course interested parties will argue that they
are inseparable), but combining them into a single agreement makes it
feasible to pass changes that would not otherwise be considered acceptable.
At the same time, it also puts the overall agreement at the danger of
failing, due to parts that are not related to its core purpose.

I understand that there is also benefit in deciding related questions in
conjunction, in that a decision in one area would only be acceptable
conditional on a decision in another area. However, to get back to the
specific topic here, this does not appear to be applicable. For example,
your changes to the RFC workflow could be implemented independently of the
voting eligibility changes and vice versa. The only possible dependency I
see is that all proposals benefit from having the 2/3 voting margin as a
baseline (which is consistent with that RFC proceeding first, of course).

The suggestion that the new RFC makes life more difficult, compared to the
current Voting RFC, is simply wrong. It is, in fact, very much the same -
except it's a lot more well defined in terms of 'what happens if' - which
in the years since the 2011 Voting RFC was enacted became a de-facto
wild-west.

As quite likely the single largest user of the RFC process, I beg to
differ. I think your perspective here comes about, because your use of the
RFC process is limited to rare, but large (in the sense of important)
proposals. However, that's not the case for all or even most RFCs. It is
already the case that RFCs are cumbersome for smaller changes, and all
active contributors I know (apart from cmb maybe) will go out of their way
to avoid going through the RFC process if it is at all avoidable. It is
something of a social faux pas to tell another core contributor on a PR
that their change might benefit from an RFC, because that generally means
that the change will be dropped dead in the water instead.

I think that we should encourage the use of RFCs for less significant
changes, because it is useful to have design considerations spelled out in
more detail than a two line commit message. Your proposal does not make
things much more complicated, and doesn't make the RFC process take much
more time. But it increases the marginal costs just enough to make RFCs
even more annoying than they already are. You edit your proposal a few
times at inopportune moments and bam, you have to wait one and a half
months before it can land. That's okay if you're trying to introduce a JIT
in PHP, but if you just want to add a function, that's the point where you
say "Why do I even bother with this?"

Regards,
Nikita

5 years ago by Larry Garfield — view source

unread

The suggestion that the new RFC makes life more difficult, compared to the
current Voting RFC, is simply wrong. It is, in fact, very much the same -
except it's a lot more well defined in terms of 'what happens if' - which
in the years since the 2011 Voting RFC was enacted became a de-facto
wild-west.

As quite likely the single largest user of the RFC process, I beg to
differ. I think your perspective here comes about, because your use of the
RFC process is limited to rare, but large (in the sense of important)
proposals. However, that's not the case for all or even most RFCs. It is
already the case that RFCs are cumbersome for smaller changes, and all
active contributors I know (apart from cmb maybe) will go out of their way
to avoid going through the RFC process if it is at all avoidable. It is
something of a social faux pas to tell another core contributor on a PR
that their change might benefit from an RFC, because that generally means
that the change will be dropped dead in the water instead.

I think that we should encourage the use of RFCs for less significant
changes, because it is useful to have design considerations spelled out in
more detail than a two line commit message. Your proposal does not make
things much more complicated, and doesn't make the RFC process take much
more time. But it increases the marginal costs just enough to make RFCs
even more annoying than they already are. You edit your proposal a few
times at inopportune moments and bam, you have to wait one and a half
months before it can land. That's okay if you're trying to introduce a JIT
in PHP, but if you just want to add a function, that's the point where you
say "Why do I even bother with this?"

Regards,
Nikita

If I may, it seems like the intended goal is to ensure that a proposal gets
"enough" attention, "enough" time for people with other priorities to find,
read, digest, and decide on it, and to avoid last minute changes in the RFC so
that people don't fully realize what they're voting on (for some definition of
"enough").

To that end, what about simply a "fallow period" before a vote can be called?
To wit:

"Once an RFC has been announced, the proposal may call a vote on it at any
time provided that there have been no substantive changes within the past 2
weeks. If there is reasonable dispute over whether a change is 'substantive',
then it is assumed to be substantive."

That assures that there is always at least a 2 week discussion period, but you
could still go from proposal to vote in 2 weeks. It also ensures that if
you've read an RFC in the last 2 weeks when the vote is called that you're
still up to date. However, minor changes (wording, revising an argument for
something but not changing the actual thing, etc.) don't cause an RFC to sit
in limbo for months. Of course, if the RFC is still changing regularly then
that would continue to kick the voting period further down the line, which is
what you want in that case since it's still being revised.

It also has the advantage of being really short and easy to grok.

--Larry Garfield

5 years ago by Zeev Suraski — view source

unread

Personally, I find any proposal that does not deal with clearly defining
voting eligibility not only questionable, but a non-starter, that has no
parallels in any other major Open Source projects.

Why? While I think the question of voting eligibility is worth discussing
(though I also don't consider the problem pressing in any way and think
that our current pool of voters works quite well, even if it may not be
what people had in mind back then), it is, just like the question of voting
margins, a rather independent issue from the remainder of the process.

Kris's point made me think about this issue, and I may still need to do
some more thinking about whether the Workflow and Voting elements can be
separated. It may be that they can. However, I don't see how the Voting
element can be further separated into "voting eligibility" and "voting
threshold", and other surrounding elements like a quorum which we may want
to introduce. These are inherently interlinked. Moreover, there are
elements where even the substance of the given RFC has - or at least
should have - influence on the voting margins. Cases in point:

The PHP 6 vs PHP 7 naming RFC
The RFC to determine PHP 7's timeline
The PHP 5.6 EOL RFC
Any future RFC about timeline, naming, or other administrative,
non-policy-binding decision

These administrative decisions make no sense to require a 2/3 majority, but
rather - a simple majority of the eligible voters, as ultimately, it's down
to a matter of preference - without any long term (beyond a couple of
years) commitments.

The 2/3 majority was introduced to place a bias-towards-the-status-quo of
the language, and make sure we don't create long-term commitments based on
a temporary narrow majority. It simply does not apply in such cases.

Further, it's difficult to separate the question of "what requires a vote"
from a statement that "everything requires a 2/3 vote", although
technically not entirely impossible.

I'll do some more thinking about it and consider breaking the Workflow &
Voting into two different RFCs if I can find an elegant way to solve these
issues; But either way, focusing on the margins alone remains a
non-starter for me.

The problem with bundling together these changes is, if you will excuse the

political parallel, akin to bundling changes to copyright enforcement
together with a free trade agreement. Those two things have nothing to do
with each other (though of course interested parties will argue that they
are inseparable), but combining them into a single agreement makes it
feasible to pass changes that would not otherwise be considered acceptable.
At the same time, it also puts the overall agreement at the danger of
failing, due to parts that are not related to its core purpose.

As demonstrated above, they actually have a lot to do with each other, and
do have certain inter-dependencies. Thankfully, in our world, neither is a
series of books with countless chapters like free trade and copyright law
tend to be. I realize that there are some people here that want to simply
focus on the 2/3 margin issue and call it a day, but to me it remains a
very partial fix to a much bigger problem - that realistically, if we don't
tackle now while we've got people's attention - we'll likely never tackle.

The suggestion that the new RFC makes life more difficult, compared to the

current Voting RFC, is simply wrong. It is, in fact, very much the same -
except it's a lot more well defined in terms of 'what happens if' - which
in the years since the 2011 Voting RFC was enacted became a de-facto
wild-west.

As quite likely the single largest user of the RFC process, I beg to
differ. I think your perspective here comes about, because your use of the
RFC process is limited to rare, but large (in the sense of important)
proposals. However, that's not the case for all or even most RFCs. It is
already the case that RFCs are cumbersome for smaller changes, and all
active contributors I know (apart from cmb maybe) will go out of their way
to avoid going through the RFC process if it is at all avoidable. It is
something of a social faux pas to tell another core contributor on a PR
that their change might benefit from an RFC, because that generally means
that the change will be dropped dead in the water instead.

I think that we should encourage the use of RFCs for less significant
changes, because it is useful to have design considerations spelled out in
more detail than a two line commit message. Your proposal does not make
things much more complicated, and doesn't make the RFC process take much
more time. But it increases the marginal costs just enough to make RFCs
even more annoying than they already are. You edit your proposal a few
times at inopportune moments and bam, you have to wait one and a half
months before it can land. That's okay if you're trying to introduce a JIT
in PHP, but if you just want to add a function, that's the point where you
say "Why do I even bother with this?"

That's extremely fair feedback re the marginal cost of editing, and I think
going along what Larry proposed later on this thread would make a lot of
sense. It would balance your feedback with the need to avoid overburdening
the RFC authors, while at the same time providing RFC voters with the time
they need to analyze and discuss the merits of (and changes to) RFCs - as
well as preventing any sort of foul-play. Essentially, "whenever's there's
doubt, there is no doubt", but at the same time - if nobody raises doubts
(which they shouldn't for small changes) - things can proceed without
interruption. I'll try to embed it into the RFC.

I still think that the new workflow proposed would keep the burden roughly
the same as it is today (with the above fix factored in).

Zeev

5 years ago by Dan Ackroyd — view source

unread

What do you think?

All RFCs must have a voting period of at least 14 days, announced in a
separate [VOTE] thread.

That sounds mostly good to me. My feedback would be:

First, I wish people (including RFC authors) took more time to think
about other people's feedback before replying.

There have been some discussions around RFCs where people appear to be
sending email responses within minutes of receiving them, which gives
the appearance of not carefully evaluating that feedback, and trying
to dominate a conversation through volume.

Without a required discussion period, there could be slightly more
'incentive' for RFC authors to respond as quickly as possible, to 'get
the discussion out the way'.

I can't think of a way to codify rules against this behaviour. But
perhaps it could be noted in an updated RFC document something like
"to allow careful consideration, discussions should be allowed to take
time to resolve. It is more appropriate to send a carefully considered
response the next day, than to send a quick response."

Second, two weeks minimum is still quite short.

This may astound people, but I often go weeks at a time without
wondering what is happening in PHP internals. I believe other people
might also have a life outside of PHP internals.

It should be made really clear to people raising RFCs, that choosing
to have the minimum voting time, particularly if the discussion didn't
seem to produce a clear consensus can be, and possibly should be,
interpreted by voters as a reason to vote against an RFC.

cheers
Dan
Ack

5 years ago by Stanislav Malyshev — view source

unread

Hi!

Without a required discussion period, there could be slightly more
'incentive' for RFC authors to respond as quickly as possible, to 'get
the discussion out the way'.

I see it exactly opposite - since we have no quorum requirement,
declaring the vote as soon as possible if a couple of people like your
proposal and nobody objected yet seems to be winning strategy. By the
time people analyze it more in detail and decide to voice objections the
vote would be half done, and by the time they read the answers and want
to continue the discussion, the vote would be finished. The right thing
in this scenario would be to vote "no" immediately to any RFC that you
didn't read yet and then start the discussion. This looks like rather
wrong process.

It should be made really clear to people raising RFCs, that choosing
to have the minimum voting time, particularly if the discussion didn't
seem to produce a clear consensus can be, and possibly should be,
interpreted by voters as a reason to vote against an RFC.

The problem, again, is, as you said, you don't read internals for weeks.
I may also have periods where this happens, and I suspect others too.
Now you come back and discover a blitz RFC already in the second week of
voting, and you don't even know what it's about. So your choice is -
read it and ask questions now, and take chance that the vote would be
done before you even get an answer, or immediately vote "no" on all
unknown RFCs and then maybe change your vote later. I don't think
encouraging such things would create a good process or be encouraging to
new RFC authors.

--
Stas Malyshev
smalyshev@gmail.com

5 years ago by Stanislav Malyshev — view source

unread

Hi!

There is no required discussion period. However, if an RFC vote is
opened without leaving enough time for discussion, then voters can and
should vote the RFC down on the grounds of insufficient discussion.

I don't think this is a good idea. I see no scenario it improves -
there's nothing in any RFC that can't wait for a week or two. However,
there can be then a situation where somebody sees something as obvious
and declares immediate vote, while others think it's not obvious at all
but by the time they get there the vote is already done. I see
absolutely no need to speed it up - the RFCs that ever got stalled
didn't get stalled because of mandatory discussion period. This tries to
solve a problem we don't have with something that may have bad
consequences.

and require more time for an adequate discussion. Other RFCs are simple and
of limited scope (such as an extension function addition) and do not
require extensive discussion.

Yes, some RFCs are simple. But none of them are urgent. And frankly if
the proposed can't stay on track for two weeks

While a two week discussion period should remain a good guideline for
language-related RFCs, it is up to the RFC author to decide when opening an
RFC vote is appropriate. This will depend both on the scope of the RFC

This is also not a good idea - I can easily see unexperienced RFC author
setting discussion period too short, because it's obviously a good idea,
people that didn't have time to understand the RFC vote no, as you
recommended, and then RFC fails not on merits but because of easily
avoidable process issue. Better to avoid it upfront.

There is no moratorium period after an RFC vote fails. If you think that
you have made significant progress on an RFC and resolved the issues that
made the previous vote fail, you can give it another shot at any time,
without having to wait out some fixed period.

Obvious failure scenario is to submit the same RFC with minimal cosmetic
changes in hope detractors gave up or don't pay attention (either
explicit or implicit - i.e. genuinely thinking the RFC was fixed but not
actually fixing it) and essentially subverting the consensus. Coupled
with no minimum discussion period I think this can happen a lot,
especially given that many people don't have time to read all discussion
on all topics on the list in real time (I don't for example).

A failed vote does not (necessarily) mean that a feature is not wanted. It
is quite common for significant changes to fail on first vote, due to
issues in the initial proposal. A failed vote should not be a
discouragement, but a motivation to address problems expressed during
discussion or voting.

True, but I don't see how having cooldown period contradicts this.
That's exactly when the problems have to be fixed. What's the point of
putting up for vote an RFC that just yesterday have failed a vote (your
reform allows this)?

Essentially, this is about making the RFC process more suitable for changes
small and large, and empowering both RFC authors and the voter base to make
decisions that are appropriate for each RFC.

I do not see which decisions it enables that will improve the process.
So far I only see the decisions that if enabled would likely to lead to
more controversial decisions passing and more people being left behind
or unable to properly participate in the process.

--
Stas Malyshev
smalyshev@gmail.com