Without further ado, an RFC that’s attempting to comprehensively solve many of the issues that have plagued our RFC process since it was hastily introduced in 2011:
https://wiki.php.net/rfc/voting2019
Emphasis on ‘attempting’. I’m sure there are still a lot of holes in it that should be plugged before we vote on it, but instead of waiting indefinitely – I’d like us to start discussing it.
Comments and suggestions welcome.
Zeev
I think you may be over-reaching a bit on the eligible voters part. Keep
in mind that all those who would be affected would still be able to vote on
this RFC. I think it's too restrictive on that part.
Also, why does FIG get special treatment?
--Kris
Without further ado, an RFC that’s attempting to comprehensively solve
many of the issues that have plagued our RFC process since it was hastily
introduced in 2011:https://wiki.php.net/rfc/voting2019
Emphasis on ‘attempting’. I’m sure there are still a lot of holes in it
that should be plugged before we vote on it, but instead of waiting
indefinitely – I’d like us to start discussing it.Comments and suggestions welcome.
Zeev
I think you may be over-reaching a bit on the eligible voters part. Keep
in mind that all those who would be affected would still be able to vote on
this RFC. I think it's too restrictive on that part.
I realized that this part of the RFC is likely to be challenging. I'm open
to additional ideas (or tweaking of existing ones) - but at the same time,
I think the current situation is not sustainable - nor can I think about
any other (large) Open Source project that employs anything similar.
Today, any person can become a voter, with identical rights to long time,
committed contributors - virtually overnight, with very little (or
virtually no) commitment on their part. Open Source project governance
tends to be a meritocracy - and even this proposal sets a fairly low bar to
having the very same voting rights as Rasmus, me, Nikita or Dmitry. Again,
I'm very open to ideas on how to improve on it, it's not an easy task to
tackle.
For the record, something like this was in fact the thinking behind the
language in https://wiki.php.net/rfc/voting - but much like other parts of
the RFC, it was poorly written, and in this case - even more poorly
implemented.
Also, why does FIG get special treatment?
The list can (and probably should) be amended; The goal here is to bring
in additional, non-source-contributors to the mix that are at the same time
experienced PHP developers that can represent a large number of
developers. PHP-FIG seemed to be a good fit for that bill, but there are
probably others that should be added as well.
Zeev
I think you may be over-reaching a bit on the eligible voters part. Keep
in mind that all those who would be affected would still be able to vote
on
this RFC. I think it's too restrictive on that part.I realized that this part of the RFC is likely to be challenging. I'm open
to additional ideas (or tweaking of existing ones) - but at the same time,
I think the current situation is not sustainable - nor can I think about
any other (large) Open Source project that employs anything similar.
Today, any person can become a voter, with identical rights to long time,
committed contributors - virtually overnight, with very little (or
virtually no) commitment on their part. Open Source project governance
tends to be a meritocracy - and even this proposal sets a fairly low bar to
having the very same voting rights as Rasmus, me, Nikita or Dmitry. Again,
I'm very open to ideas on how to improve on it, it's not an easy task to
tackle.
I favor changing how we vote, but I disagree with the proposed unilateral
vote stripping. As requested, I will offer an idea.
We have two disparate groups contributing to PHP. One the one hand, we have
the "core developers" who disproportionally carry the most burden to build
and maintain the source. On the other hand, we have "the community" who
consume, organize, and evangelize PHP (and who may, or may not, commit).
Both of these groups change over time.
What outcomes do we desire?
- A change Wanted by the simple majority of Both core developers and the
community should Pass. - A change Unwanted by the simple majority of Both should Fail.
- We require a higher standard of consensus when the majority of Either
cannot agree.
I counter-propose the following voting rules, modeled after Robert's Rules
for voice and rising votes, which encourages a wider audience to join and
vote or to strive to contribute more to the engine:
- Anyone can register as a community member, and can vote on any RFC as
a community member. - Core developers are defined as the top 13 committers within the
period of two years since voting began. A core developer is a de facto
community member, but caucuses as a core developer. - Voting occur in rounds.
- Round one is the opening vote. If the simple majority of both parties
consents, the vote passes. If the simple majority of both parties dissents,
the vote fails. In either of these cases, the vote ends as consensus has
been reached. - Round two occurs when there is disagreement between parties. In this
round, a 2/3 super-majority consent from one party carries the vote, unless
there is a 2/3 super-majority dissent from the other party. If carried, the
vote ends as "sufficient" consensus has been reached. - Round three occurs when there is "excessive" disagreement on the
topic. In this round, the elected tie-breaking member shall cast the
deciding vote. If there is no elected tie-breaking member in service, the
vote fails.
Administrative miscellany:
- Core developers' vote requires a quorum.
- Community members' voting does not require quorum.
- Voting rounds are open for one week from the opening date time. If a
round times out without decision, the vote fails. - The definition of core developers may itself be voted upon under
these rules. - The tie-breaking member shall be elected every two years under these
rules.
I believe these rules respect the order we have now, while evening out the
representation and raising the bar on contentious votes. As with Zeev's
proposal, gone is the idea that RFC authors choose the bar, but instead of
mandating 2/3, this proposal focuses on the idea of consensus, and what it
means quantitatively. Added, as mentioned in Zeev's proposal as a Todo is
quorum, which protects the language from changes snuck in without the
explicit review of at least those who will be most responsible for it. Of
course unlike Zeev's proposal this encourages more involvement from the
community by saying "yes you have a vote".
Diverse representation, quantitative consensus, and mandatory quorum work
together to ensure we can continue collaboration under a rational framework
where everyone's voice is recorded and the majority does become tyrannical.
Thanks everyone for all you do and your consideration of this alternative,
bishop
2. Core developers are defined as the top 13 committers within the
period of two years since voting began. A core developer is a de
facto
community member, but caucuses as a core developer.
How do you define "top 13 committers"? How do you prevent people from
playing the system by committing typo changes in comments etc.? Will
somebody who rewrites a larger change into a single commit be
negatively ranked compared to somebody who creates a small fix which
requires multiple small fixes afterwards?
I don't think quantity of anything (lines changed, commits, ..) is a
good metric in any way.
Either the list of contributors has to be inclusive or people have to
be elected (with all the issues of electing people)
johanes
On Fri, Feb 1, 2019 at 8:41 PM Johannes Schlüter johannes@schlueters.de
wrote:
- Core developers are defined as the top 13 committers within the
period of two years since voting began. A core developer is a de
facto
community member, but caucuses as a core developer.How do you define "top 13 committers"? How do you prevent people from
playing the system by committing typo changes in comments etc.? Will
somebody who rewrites a larger change into a single commit be
negatively ranked compared to somebody who creates a small fix which
requires multiple small fixes afterwards?
I don't think quantity of anything (lines changed, commits, ..) is a
good metric in any way.
Either the list of contributors has to be inclusive or people have to
be elected (with all the issues of electing people)
TL;DR: I don't think it matters. Any quantitative measure identifying those
with the highest skill, accomplishment, availability, and belief in the
community will suffice. The combined effect of a multi-cameral system,
quorum, and super-majority override will minimize the effects of gaming.
Identifying those who can vote requires a "selection metric". Our current
unicameral voting system has a "low bar" selection metric. The voting
eligibility portion of Zeev's proposal changes the selection metric, but
keeps the unicameral body. I feel formally identifying the top contributors
and giving them a separate say is an important step toward reform, but
retaining a unicameral body is not, in my opinion, progress.
So, how do we identify those who are currently the most contributory?
Commits mostly, though we can't ignore other qualities. In a 2003 paper
1, Scacchi (UC Irvine) defined a F/OSS meritocracy pyramid in which those
at the top had the highest perceived authority. Kaats (Utrecht
University) et. al. in 2014 2 built on Scacchi's research saying:
"In order to assess the merits [of those at the pyramid top] one
cannot simply measure one aspect... while most had a good commit
track-record, there were also a fair amount that had barely written any
code... yet those individuals might contribute in other ways."
Scacchi's research cautions, in counterpoint, that SCM write access is a
form of potentially damaging control:
"The ability for the eyes of many developers to review or look over source
code, system build and preliminary test results, and response to bug
reports also realizes peer review and the potential for embarrassment as a
form of indirect social control over the timely actions of contributing
F/OSS developers. Thus, F/OSS development allows for ... manipulation by
the core developers, so as to encourage certain patterns of software
development and social control, and to discourage others that may not
advance the collective needs"
That is, git is a mechanism for control. Be that gaming to enter the
selection metric, or by rejecting contributions of others, it's a means for
those who can contribute to control those who only might contribute.
So while a selection metric based on commits is a robust means of
identifying top contributors, it's necessary - but not sufficient - and may
even be damaging. For this reason I suggest the safer strategy of a
multi-cameral system that includes the voices of those who don't commit, or
commit substantially less than those selected as top.
Let us imagine a faction that games git and seizes majority control over
the core contributors metric. Under Zeev's voting eligibility proposal, yes
it'd be harder to game the contingency of 175 members. But, that large a
group also can't reasonably form a quorum, which means we have no assurance
those that vote speak for the group. Under my counter-proposal, with only 7
members to quorum, it's statistically easier to game. But those that are
bumped out still have a vote in the community, so the effect of gaming is
effectively cancelled. Further, the community does not have to form a
quorum, so it's statistically easier for the community to counter a 2/3
super-majority of core developers. Which is why, in all likelihood, the
tie-breaking member would typically be a top committer or a grand-elder.
In short, the balance from a multi-cameral system limits the effects of
gaming git and gives a vote to those who contribute in ways other than
writing huge amounts of code.
So, how do we identify those who are currently the most contributory?
Commits mostly, though we can't ignore other qualities. In a 2003
paper[1], Scacchi (UC Irvine) defined a F/OSS meritocracy pyramid in
which those at the top had the highest perceived authority. Kaats
(Utrecht University) et. al. in 2014 [2] built on Scacchi's research
saying:
The issue with such a study is that typically the motivation for doing
commits or changing lines of code changes is to improve the code base,
not to gain power.
By giving power based on such a metric you change the motivation for
doing changes.
And also mind: You don't need many people doing this to have an impact.
This can also have different effect: Image we say "top 13 comitters"
gain voting power. Now a few days before the evaluation point somebody
commits some "unimportant" (subjectively) changes ad therefore gains
voting seat 13. Then the person on rank 14 will be unhappy that there
(subjectively) important changes are less valuable.
I think there is a value in kicking people with hardly any contribution
(like myself these days) out to avoid "old friendships" to play a role
(over the last few years I had some cases where more active people
pointed me to RFCs ... which I interpreted as a question for my
opinion, not for a vote, but who knows)
In general I prefer consensus over voting, as voting produces "losers"
and voting was introduced when we didn't have a decision process in
multiple heated debates.
https://tools.ietf.org/html/rfc7282 is a relevant RFC for consensus.
johannes
2. Core developers are defined as the top 13 committers within the
period of two years since voting began. A core developer is a de
facto
community member, but caucuses as a core developer.How do you define "top 13 committers"? How do you prevent people from
playing the system by committing typo changes in comments etc.? Will
somebody who rewrites a larger change into a single commit be
negatively ranked compared to somebody who creates a small fix which
requires multiple small fixes afterwards?I don't think quantity of anything (lines changed, commits, ..) is a
good metric in any way.Either the list of contributors has to be inclusive or people have to
be elected (with all the issues of electing people)johanes
--- a.txt 2019-02-02 12:09:50.405436313 +0200
+++ b.txt 2019-02-02 12:09:46.733163725 +0200
@@ -1 +1 @@
-johanes
+johannes
you mean?
Cheers,
Andrey
Hi Zeev
Den tor. 31. jan. 2019 kl. 15.44 skrev Zeev Suraski zeev@php.net:
Without further ado, an RFC that’s attempting to comprehensively solve many of the issues that have plagued our RFC process since it was hastily introduced in 2011:
I wholeheartedly disagree with the PHP-FIG special exception to who
can vote, call me biased but I do not believe it serves any purpose
and is absurd. People who actively work on PHP, should be the ones to
be able to have a choice, I think that should be reserved for any
contributor who puts effort working on PHP.
I do understand that we are the language and our work affects the
others the most. However making special exceptions for who can vote
and essentially having a say from an external source in what I in
theory need to help maintain as a PHP Core Developer is terrible. Why
not allow WordPress Core Developers to have a say instead, as their
work has a larger impact on the usage of PHP? (That was obviously a
bit of sarcasm, the last part). We are not allowed to vote at their
individual projects features (nor do we need to have a say if we are
not actively involved in the development of said projects or
organizations) and I stand very strongly behind that belief.
Besides this, it also creates uncertainty about who elects such, and
simply should be dropped from the voting RFC as it was already fairly
unclear from the original one.
The contributors appendix also lists ChangeLog, SVN Migration etc,
something to keep in mind if this RFC is moved forward to filter the
list.
Do I understand the PHP Packaging Decisions right that it requires to
vote for a timeline for each version? I remember we have different
opinions raised regarding the time to a new major version (should we
have 7.4 vs go to 8.0, same for the 5 to 7 transition back then
regarding a 5.7). This is the only issue I can think of and should be
changed to requiring a vote if there is a dispute in regards to what
the next version should be. As I don't really wanna vote just to vote
for each of the minor versions of 8 once a year when its the most
logical reason to go to 8.1 from 8.0, and so on until we reach the
point where the next major is considerable.
I think changes like the requiring a patch for RFCs is a very welcomed addition.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Hi Zeev
Den tor. 31. jan. 2019 kl. 15.44 skrev Zeev Suraski zeev@php.net:
Without further ado, an RFC that’s attempting to comprehensively solve
many of the issues that have plagued our RFC process since it was hastily
introduced in 2011:I wholeheartedly disagree with the PHP-FIG special exception to who
can vote, call me biased but I do not believe it serves any purpose
and is absurd. People who actively work on PHP, should be the ones to
be able to have a choice, I think that should be reserved for any
contributor who puts effort working on PHP.I do understand that we are the language and our work affects the
others the most. However making special exceptions for who can vote
and essentially having a say from an external source in what I in
theory need to help maintain as a PHP Core Developer is terrible. Why
not allow WordPress Core Developers to have a say instead, as their
work has a larger impact on the usage of PHP? (That was obviously a
bit of sarcasm, the last part). We are not allowed to vote at their
individual projects features (nor do we need to have a say if we are
not actively involved in the development of said projects or
organizations) and I stand very strongly behind that belief.Besides this, it also creates uncertainty about who elects such, and
simply should be dropped from the voting RFC as it was already fairly
unclear from the original one.The contributors appendix also lists ChangeLog, SVN Migration etc,
something to keep in mind if this RFC is moved forward to filter the
list.Do I understand the PHP Packaging Decisions right that it requires to
vote for a timeline for each version? I remember we have different
opinions raised regarding the time to a new major version (should we
have 7.4 vs go to 8.0, same for the 5 to 7 transition back then
regarding a 5.7). This is the only issue I can think of and should be
changed to requiring a vote if there is a dispute in regards to what
the next version should be. As I don't really wanna vote just to vote
for each of the minor versions of 8 once a year when its the most
logical reason to go to 8.1 from 8.0, and so on until we reach the
point where the next major is considerable.I think changes like the requiring a patch for RFCs is a very welcomed
addition.--
regards,Kalle Sommer Nielsen
kalle@php.net--
Given how complex and controversial this question of restricting who can
vote is, I propose that it be moved to its own RFC instead of being bundled
with this one. It would certainly boost likelihood of passage, if nothing
else, as there are a lot of good ideas in this RFC.
--Kris
Hi Kris
Den tor. 31. jan. 2019 kl. 18.03 skrev Kris Craig kris.craig@gmail.com:
Given how complex and controversial this question of restricting who can vote is, I propose that it be moved to its own RFC instead of being bundled with this one. It would certainly boost likelihood of passage, if nothing else, as there are a lot of good ideas in this RFC.
While that makes sense, I do believe it should be sorted at the same
time. This can be solved by secondary votes on how to approach it
within the RFC.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Hi Zeev
Den tor. 31. jan. 2019 kl. 15.44 skrev Zeev Suraski zeev@php.net:
Without further ado, an RFC that’s attempting to comprehensively solve
many of the issues that have plagued our RFC process since it was hastily
introduced in 2011:I wholeheartedly disagree with the PHP-FIG special exception to who
can vote, call me biased but I do not believe it serves any purpose
and is absurd. People who actively work on PHP, should be the ones to
be able to have a choice, I think that should be reserved for any
contributor who puts effort working on PHP.I do understand that we are the language and our work affects the
others the most. However making special exceptions for who can vote
and essentially having a say from an external source in what I in
theory need to help maintain as a PHP Core Developer is terrible. Why
not allow WordPress Core Developers to have a say instead, as their
work has a larger impact on the usage of PHP? (That was obviously a
bit of sarcasm, the last part). We are not allowed to vote at their
individual projects features (nor do we need to have a say if we are
not actively involved in the development of said projects or
organizations) and I stand very strongly behind that belief.
That's a very fair point. I'm personally undecided on this. It's fair to
say that in 2011, my thinking was that voting rights should be given pretty
much exclusively to contributors. It may sound like overreaching, but the
reality is that this is pretty much how ALL open source projects work (and
have been working). The reason it sounds overreaching, is that over the
several years following the ratification of the 2011 Voting RFC - a status
quo of "virtually anybody can vote" took hold, and it's now fairly
entrenched in people's minds. It's still very, very awkward when taken in
the context of how OS projects behave in general.
The thinking behind PHP-FIG (and for that matter, having some
representation from WordPress, yes, I'm not kidding...) was to create
something which goes a bit farther than what's usual in an OS project -
because of the status quo we have today. Making it a bit easier to
digest. But it may be that it's the wrong approach. I'll be interested to
see what others think about it as well. I'm personally open both for
extending that list further - or potentially trimming it down - making it
more of a meritocracy, as is customary in virtually all other OS projects.
Do I understand the PHP Packaging Decisions right that it requires to
vote for a timeline for each version? I remember we have different
opinions raised regarding the time to a new major version (should we
have 7.4 vs go to 8.0, same for the 5 to 7 transition back then
regarding a 5.7). This is the only issue I can think of and should be
changed to requiring a vote if there is a dispute in regards to what
the next version should be. As I don't really wanna vote just to vote
for each of the minor versions of 8 once a year when its the most
logical reason to go to 8.1 from 8.0, and so on until we reach the
point where the next major is considerable.
I agree. I'll look at the text and clarify it as needed. Of course it
makes no sense to have to vote on every version from scratch every time.
I think changes like the requiring a patch for RFCs is a very welcomed
addition.
Thanks for the feedback!
Zeev
On Thu, Jan 31, 2019 at 5:58 PM Kalle Sommer Nielsen kalle@php.net
wrote:Hi Zeev
Den tor. 31. jan. 2019 kl. 15.44 skrev Zeev Suraski zeev@php.net:
Without further ado, an RFC that’s attempting to comprehensively solve
many of the issues that have plagued our RFC process since it was hastily
introduced in 2011:I wholeheartedly disagree with the PHP-FIG special exception to who
can vote, call me biased but I do not believe it serves any purpose
and is absurd. People who actively work on PHP, should be the ones to
be able to have a choice, I think that should be reserved for any
contributor who puts effort working on PHP.I do understand that we are the language and our work affects the
others the most. However making special exceptions for who can vote
and essentially having a say from an external source in what I in
theory need to help maintain as a PHP Core Developer is terrible. Why
not allow WordPress Core Developers to have a say instead, as their
work has a larger impact on the usage of PHP? (That was obviously a
bit of sarcasm, the last part). We are not allowed to vote at their
individual projects features (nor do we need to have a say if we are
not actively involved in the development of said projects or
organizations) and I stand very strongly behind that belief.That's a very fair point. I'm personally undecided on this. It's fair to
say that in 2011, my thinking was that voting rights should be given pretty
much exclusively to contributors. It may sound like overreaching, but the
reality is that this is pretty much how ALL open source projects work (and
have been working). The reason it sounds overreaching, is that over the
several years following the ratification of the 2011 Voting RFC - a status
quo of "virtually anybody can vote" took hold, and it's now fairly
entrenched in people's minds. It's still very, very awkward when taken in
the context of how OS projects behave in general.
The thinking behind PHP-FIG (and for that matter, having some
representation from WordPress, yes, I'm not kidding...) was to create
something which goes a bit farther than what's usual in an OS project -
because of the status quo we have today. Making it a bit easier to
digest. But it may be that it's the wrong approach. I'll be interested to
see what others think about it as well. I'm personally open both for
extending that list further - or potentially trimming it down - making it
more of a meritocracy, as is customary in virtually all other OS projects.I don't know if there is a good way to implement it, but I definitely
think there is value in some sort of voice being given to those that use
PHP to build things, but don't contribute to the actual source.
I think it's important, though, to make sure that developers that are out
there actually developing things with PHP (not to say that contributors
don't belong to that group) have a voice - I'm just wondering if that needs
to be defined in a more formal way. One statistic I just found says that
almost 6 million websites are running PHP7. Even if we assume that it
averages out to where there is 1 developer for every 100 sites, that's
still 60,000 developers being represented by 175 voters.
Maybe the voice that we currently have in the form of being able to
participate in these discussions is enough. I'd be interested in knowing
how often voters are persuaded to take a position on an issue after
discussing it with non-voting developers - whether via these discussion
lists or on other mediums.
Maybe instead of giving all members of PHP-FIG a vote, the RFC can be
amended to specify that PHP related groups with a certain number of active
members are given a single vote. Or, instead of membership numbers, an
application process of some sort can be put in place for various groups to
petition for representation. If accepted, that group is given a single
vote. A committee can be put together that is in charge of addressing the
applications.
Do I understand the PHP Packaging Decisions right that it requires to
vote for a timeline for each version? I remember we have different
opinions raised regarding the time to a new major version (should we
have 7.4 vs go to 8.0, same for the 5 to 7 transition back then
regarding a 5.7). This is the only issue I can think of and should be
changed to requiring a vote if there is a dispute in regards to what
the next version should be. As I don't really wanna vote just to vote
for each of the minor versions of 8 once a year when its the most
logical reason to go to 8.1 from 8.0, and so on until we reach the
point where the next major is considerable.I agree. I'll look at the text and clarify it as needed. Of course it
makes no sense to have to vote on every version from scratch every time.I think changes like the requiring a patch for RFCs is a very welcomed
addition.Thanks for the feedback!
Zeev
--
-- Chase
chasepeeler@gmail.com
Den tor. 31. jan. 2019 kl. 20.17 skrev Chase Peeler chasepeeler@gmail.com:
I don't know if there is a good way to implement it, but I definitely think there is value in some sort of voice being given to those that use PHP to build things, but don't contribute to the actual source.
I think it's important, though, to make sure that developers that are out there actually developing things with PHP (not to say that contributors don't belong to that group) have a voice - I'm just wondering if that needs to be defined in a more formal way. One statistic I just found says that almost 6 million websites are running PHP7. Even if we assume that it averages out to where there is 1 developer for every 100 sites, that's still 60,000 developers being represented by 175 voters.
I do believe that the right to vote is a privilege of actually
contributing to the project, which in our case is seen by code as we
are a scripting language project, I think that is a fair definition.
However I do believe that because it is also a privilege it should be
considered as something you earn by dedicating yourself to the
project, if you are dedicated to the project then I would assume (and
I'm certain that I speak for most core developers) when I say that
those voting for changes in PHP does it in PHP's best interest.
Because they understand the complications and impact changing things
have.
We can take an example by looking at some of the more recent change
proposals for PHP8 that goes to show that not a lot of thought about
the implications and effect changing a few functions may have. For
your open source framework that have lets say maybe 10.000 users, that
is not a big deal, but when you take that number and maybe multiply it
by 1.000 (or you can swap around the zeros), then the impact of which
we change things are set in a very different perspective. Okay we do
have procedures for how to deal with some of these things for what can
and can't go into a branch. My point here is that when you are apart
of the project and more or less integrated with it, you would also
understand the ramifications on a project of the scale.
I do not want this to sound unwelcoming or so at all, I would like
more to join the project and put effort into improving our code base.
However like Johannes said in a mail earlier in this thread, if the
maintainers (core developers) are overruled by a third party, then a
point they simply loose interest and stop contributing and the project
will begin to halt. I would feel that same way myself.
Maybe the voice that we currently have in the form of being able to participate in these discussions is enough. I'd be interested in knowing how often voters are persuaded to take a position on an issue after discussing it with non-voting developers - whether via these discussion lists or on other mediums.
I think the AFUP did something rather interesting, which we could use
as a model; If you are not familiar with the AFUP (Association
Française des Utilisateurs de PHP), then it is the french usergroup
for PHP. Every now and then, we used to get emails from a member of
their group that would post a small summary of their thoughts
regarding a certain RFC, whether they were infavor of it or not and
potential problems they see as userland.
That I believe could work much better, as in giving external projects
or organization a way to comment on an RFC (which I would hope more
would have done instead of just being silent) about the pros and cons.
As core developers we take comments and feedback (Yes we have heard
the striking feedback about the standard library) as close as we can
to make sure that we don't just do something that would literally
render a PHP based project unusable by a change we have done.
Maybe instead of giving all members of PHP-FIG a vote, the RFC can be amended to specify that PHP related groups with a certain number of active members are given a single vote. Or, instead of membership numbers, an application process of some sort can be put in place for various groups to petition for representation. If accepted, that group is given a single vote. A committee can be put together that is in charge of addressing the applications.
Please no committee or more bureaucracy as it just makes everything so
much more political and complicated for no satisfying reason.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
On Thu, Jan 31, 2019 at 5:58 PM Kalle Sommer Nielsen kalle@php.net
wrote:
Hi Zeev
Den tor. 31. jan. 2019 kl. 15.44 skrev Zeev Suraski zeev@php.net:
Without further ado, an RFC that’s attempting to comprehensively solve
many of the issues that have plagued our RFC process since it was
hastilyintroduced in 2011:
I wholeheartedly disagree with the PHP-FIG special exception to who
can vote, call me biased but I do not believe it serves any purpose
and is absurd. People who actively work on PHP, should be the ones to
be able to have a choice, I think that should be reserved for any
contributor who puts effort working on PHP.I do understand that we are the language and our work affects the
others the most. However making special exceptions for who can vote
and essentially having a say from an external source in what I in
theory need to help maintain as a PHP Core Developer is terrible. Why
not allow WordPress Core Developers to have a say instead, as their
work has a larger impact on the usage of PHP? (That was obviously a
bit of sarcasm, the last part). We are not allowed to vote at their
individual projects features (nor do we need to have a say if we are
not actively involved in the development of said projects or
organizations) and I stand very strongly behind that belief.That's a very fair point. I'm personally undecided on this. It's fair to
say that in 2011, my thinking was that voting rights should be given
pretty
much exclusively to contributors. It may sound like overreaching, but the
reality is that this is pretty much how ALL open source projects work (and
have been working). The reason it sounds overreaching, is that over the
several years following the ratification of the 2011 Voting RFC - a status
quo of "virtually anybody can vote" took hold, and it's now fairly
entrenched in people's minds. It's still very, very awkward when taken in
the context of how OS projects behave in general.
The thinking behind PHP-FIG (and for that matter, having some
representation from WordPress, yes, I'm not kidding...) was to create
something which goes a bit farther than what's usual in an OS project -
because of the status quo we have today. Making it a bit easier to
digest. But it may be that it's the wrong approach. I'll be interested
to
see what others think about it as well. I'm personally open both for
extending that list further - or potentially trimming it down - making it
more of a meritocracy, as is customary in virtually all other OS projects.I don't know if there is a good way to implement it, but I definitely
think there is value in some sort of voice being given to those that use
PHP to build things, but don't contribute to the actual source.I think it's important, though, to make sure that developers that are out
there actually developing things with PHP (not to say that contributors
don't belong to that group) have a voice - I'm just wondering if that needs
to be defined in a more formal way. One statistic I just found says that
almost 6 million websites are running PHP7. Even if we assume that it
averages out to where there is 1 developer for every 100 sites, that's
still 60,000 developers being represented by 175 voters.Maybe the voice that we currently have in the form of being able to
participate in these discussions is enough. I'd be interested in knowing
how often voters are persuaded to take a position on an issue after
discussing it with non-voting developers - whether via these discussion
lists or on other mediums.Maybe instead of giving all members of PHP-FIG a vote, the RFC can be
amended to specify that PHP related groups with a certain number of active
members are given a single vote. Or, instead of membership numbers, an
application process of some sort can be put in place for various groups to
petition for representation. If accepted, that group is given a single
vote. A committee can be put together that is in charge of addressing the
applications.
Disclosure: I am a long-time member of PHP-FIG, but I am NOT speaking on
behalf of FIG in this post, only for myself.
As Zeev noted, I think it's very good to have some mechanism for formal
involvement from people who aren't C coders. Currently, in order to vote
(have a direct impact) you need to be a C developer; you technically don't
need to even know how to write PHP, just C. :-) That's a very different
mindset and perspective than people who write PHP all day, and both are
valuable. The PHP community is much, much larger than the PHP Internals C
developer community.
At the same time, I fully agree with Kalle and Johannes that it would be a
very bad idea for the Internals/C developers to be "forced" to maintain
something they think is a bad feature because the great unwashed masses (who
by nature don't realize just how terrible an idea is for the parser, for
instance) thought it was cool and trendy. Yet the fact that the unwashed
masses think something is useful is relevant and a point that should be
considered.
So I would support a mechanism of some sort to give formal voting rights to
non-internals-C-developers who are still significant-PHP-contributors, as long
as the number of people involved is relatively low compared to the direct-
contributor number. With a contributor voting pool of ~175 (which would no
doubt vary but let's assume stays in vaguely the same range), an "at large
voter" population of 5, 10, or 15 people would provide direct representation
without a meaningful risk of swamping the direct contributors, who I agree
should remain the overwhelming majority of eligible voters.
Whether FIG is the best way to select that community-voter constituency I'm
not sure. Or rather... I don't see any alternative mechanism that wouldn't
involve, essentially, replicating the work FIG has done to determine
appropriate "leading members of the community at large". So if tapping FIG
isn't the preferred way, the alternative would involve, essentially,
duplicating at least a large part of FIG's process.
This would be the first formal recognition of FIG by PHP Internals. I am
completely OK with that, and personally would love to see Internals and FIG
collaborate more; I'm just noting it for completeness.
Another point there is that the RFC doesn't specify what "member of FIG"
means. FIG currently has 3 defined groups of people: Secretaries (3 people),
the Core Committee (12 people), and Project Representatives (36 people at
Zeev, which group is intended?
To provide some insight (with a little over-simplification):
-
Project Representatives are appointed by their respective projects, and are
usually but not always project leads. The bar for membership is extremely
low, by design, and most in practice most project representatives are inactive
99.99% of the time. -
The Core Committee is elected by Project Representatives, and are at least
moderately active, much of the time. They're responsible for reviewing,
tracking, and approving PSR proposals, and are supposed to be active
generalist architects. -
The Secretaries are elected by Project Representatives, and keep the
machinery working but are not involved in spec development. They're basically
FIG's project managers.
If there's a concern about adding 50 "outsiders" to the voting rolls, I would
propose just inviting the 12 Core Committee members to vote. They're already
elected in an open process to represent/work for the PHP ecosystem as a whole,
with an eye toward compatibility, consistency, and all the same kind of stuff
that Internals cares about. And 12 people would not pose a threat of
overwhelming the direct contributors, especially as a handful of them are
already Internals contributors anyway.
(Disclosure: I am a member of the Core Committee so that would include me; I
hope that doesn't itself turn anyone off of the idea :-), but I mention it for
transparency and feel it would be a good approach even if I weren't.)
Any other selection process for outside voters would, I believe, essentially
duplicate what FIG already does. It's better to just outsource that selection
process to a known entity.
Again, I'm not speaking on behalf of FIG here in any way, so other FIG members
may have their own views on the subject.
--Larry Garfield
Den fre. 1. feb. 2019 kl. 02.42 skrev Larry Garfield larry@garfieldtech.com:
Disclosure: I am a long-time member of PHP-FIG, but I am NOT speaking on
behalf of FIG in this post, only for myself.As Zeev noted, I think it's very good to have some mechanism for formal
involvement from people who aren't C coders. Currently, in order to vote
(have a direct impact) you need to be a C developer; you technically don't
need to even know how to write PHP, just C. :-) That's a very different
mindset and perspective than people who write PHP all day, and both are
valuable. The PHP community is much, much larger than the PHP Internals C
developer community.At the same time, I fully agree with Kalle and Johannes that it would be a
very bad idea for the Internals/C developers to be "forced" to maintain
something they think is a bad feature because the great unwashed masses (who
by nature don't realize just how terrible an idea is for the parser, for
instance) thought it was cool and trendy. Yet the fact that the unwashed
masses think something is useful is relevant and a point that should be
considered.So I would support a mechanism of some sort to give formal voting rights to
non-internals-C-developers who are still significant-PHP-contributors, as long
as the number of people involved is relatively low compared to the direct-
contributor number. With a contributor voting pool of ~175 (which would no
doubt vary but let's assume stays in vaguely the same range), an "at large
voter" population of 5, 10, or 15 people would provide direct representation
without a meaningful risk of swamping the direct contributors, who I agree
should remain the overwhelming majority of eligible voters.
So while you fully agree with its a bad idea that us the Core
Developers have to maintain code that is decided by external, non
contributing parties, still you think there should be a way for non
Core Developers to vote? That is kinda absurd.
Whether FIG is the best way to select that community-voter constituency I'm
not sure. Or rather... I don't see any alternative mechanism that wouldn't
involve, essentially, replicating the work FIG has done to determine
appropriate "leading members of the community at large". So if tapping FIG
isn't the preferred way, the alternative would involve, essentially,
duplicating at least a large part of FIG's process.
Any project that would like a say in something related to PHP as a
language, should, much like yourself, contribute to discussions. We as
developers do listen to feedback and take that into account when
designing and implementing features for the language, as it is
naturally made for our users, we value that input a lot and I use that
often as a determining factor to whether or not I vote yes to an RFC,
and I'm certain that I'm not the only one that puts personal bias a
little to the side in that scenario.
This would be the first formal recognition of FIG by PHP Internals. I am
completely OK with that, and personally would love to see Internals and FIG
collaborate more; I'm just noting it for completeness.
I'm not okay with that at all. I accept and respect what you as a
project do, but because of that it doesn't mean you (you as in a
project) should have a special right over our project because you
represent some of the most used userland projects. Besides the very
high profile projects like Laravel and Symfony (even projects like
Doctrine and Guzzle) is no longer represented, WordPress is not even a
part of the FIG.
The moment we as The PHP Project collaborate with you as the FIG, it
means that we will be seen as promoting FIG, and therefore it means
there is a certain favoritism towards picking what the FIG does
because the PHP project collaborates with them, essentially not
allowing competing projects or initiatives to have a space there, or
it would mean we also would have to take them aboard etc. That is a
mess and something we should avoid and why we do not use others
packages and projects for building our own web infrastructure. We need
to be neutral and transparent as a project because of the scale that
is PHP.
Another point there is that the RFC doesn't specify what "member of FIG"
means. FIG currently has 3 defined groups of people: Secretaries (3 people),
the Core Committee (12 people), and Project Representatives (36 people at
Zeev, which group is intended?To provide some insight (with a little over-simplification):
Project Representatives are appointed by their respective projects, and are
usually but not always project leads. The bar for membership is extremely
low, by design, and most in practice most project representatives are inactive
99.99% of the time.The Core Committee is elected by Project Representatives, and are at least
moderately active, much of the time. They're responsible for reviewing,
tracking, and approving PSR proposals, and are supposed to be active
generalist architects.The Secretaries are elected by Project Representatives, and keep the
machinery working but are not involved in spec development. They're basically
FIG's project managers.If there's a concern about adding 50 "outsiders" to the voting rolls, I would
propose just inviting the 12 Core Committee members to vote. They're already
elected in an open process to represent/work for the PHP ecosystem as a whole,
with an eye toward compatibility, consistency, and all the same kind of stuff
that Internals cares about. And 12 people would not pose a threat of
overwhelming the direct contributors, especially as a handful of them are
already Internals contributors anyway.
Should this insane idea of allowing FIG members to vote pass, does
that also mean that the ~175 members of PHP get an equal voting right
in line with a so called Core Committee member? I doubt that. Reading
the FIG personnel page, I can spot 4 members that currently have
voting right because of their contributions to the project. Should
this RFC pass without allowing outsiders to vote, that would most
likely be down to 2 (Sara and Lukas). Besides that I spot an
additional 5 project members that can already vote or have contributed
back to PHP by code, obviously I'm only a human so my memory with the
names may be vague but there is already a presence because those
people are contributors to PHP.
In theory you already got a large say in voting on an individual
basis, even if the contributions to PHP itself is sparse.
Given the volume of people who currently votes on RFCs on average,
that would literally mean that we would increase our average voting
pool by 25%, something to consider as by then the FIG would
essentially sit with about a 20% say in whether or not something
should go in and their hands will stay clean because we as maintainers
will have to do the dirty work and that is without projects like
Laravel, Symfony and WordPress having a say, just the FIG.
What about when your Core Committee members change, that means we need
to change karma granted because your process changes? No thank you.
(Disclosure: I am a member of the Core Committee so that would include me; I
hope that doesn't itself turn anyone off of the idea :-), but I mention it for
transparency and feel it would be a good approach even if I weren't.)
That itself worries me, because you are represent a part of the
community using the language, but you are not a language designer. You
are active with input on internals and RFCs etc, which I respect a
lot, but without any interest in actually writing code (I can't really
say if its true or not regarding the interest or its because of C
know-how) or because of time schedules like we all have, I don't see
why a special exception should be granted. No offense.
Any other selection process for outside voters would, I believe, essentially
duplicate what FIG already does. It's better to just outsource that selection
process to a known entity.
Any presence from an outside group means we need to have a much
different process and a lot more political babble, which quite
frankly, most other Core Developers don't really care THAT much about
unlike the FIG. Something we shouldn't have a need for, despite (to
use your own word), chaotic, nature of how internals is at times. All
we want to is to write code and enjoy it like we have done for almost
25 years this year, while the internals is no longer the "closed
gentle mans club" as it was when I joined 11 years ago, it still is
quite distinct from other OSS projects and one of the reasons why I
personally stick around, as I like that spirit the project has, which
is why I'm very protective of that as I'm certain you must have
noticed.
Again, I'm not speaking on behalf of FIG here in any way, so other FIG members
may have their own views on the subject.--Larry Garfield
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Den fre. 1. feb. 2019 kl. 02.42 skrev Larry Garfield
So I would support a mechanism of some sort to give formal voting
rights
to
non-internals-C-developers who are still significant-PHP-contributors, as
long as the number of people involved is relatively low compared to the
direct- contributor number. With a contributor voting pool of ~175
(which would no doubt vary but let's assume stays in vaguely the same
range), an "at large voter" population of 5, 10, or 15 people would
provide direct representation without a meaningful risk of swamping the
direct contributors, who I agree should remain the overwhelming majority
of eligible voters.So while you fully agree with its a bad idea that us the Core
Developers have to maintain code that is decided by external, non
contributing parties, still you think there should be a way for non
Core Developers to vote? That is kinda absurd.
It's not absurd, it's a matter of degrees. As Zeev noted in a later email,
the current voting RFC already calls for some voting-level input from "major
customers", but not a controlling vote.
To use hyperbolic examples:
Would adding one single non-C-developer to the voting rolls mean that "the
Core Developers have to maintain code that is decided by external, non
contributing parties"? No, that's "kinda absurd" to call it that, because
that one voter is clearly swamped out by the many other Internals developers
that are also voting.
Would adding 200 non-C developers to the voting roll mean that? Certainly
yes, that would be an absurd situation. But no one that I've seen is
suggesting that at all, or anything close to it.
What's the threshold of absurdity here? That we could debate. However, it is
not 0. (I'd personally put it in the 10-20 range, bearing in mind that not
all of them would vote all the time anyway, just like core developers, but
others may feel differently.)
This would be the first formal recognition of FIG by PHP Internals. I am
completely OK with that, and personally would love to see Internals and
FIG
collaborate more; I'm just noting it for completeness.I'm not okay with that at all. I accept and respect what you as a
project do, but because of that it doesn't mean you (you as in a
project) should have a special right over our project because you
represent some of the most used userland projects. Besides the very
high profile projects like Laravel and Symfony (even projects like
Doctrine and Guzzle) is no longer represented, WordPress is not even a
part of the FIG.
The degree to which "participation in a big name project" correlates or has a
causal relationship with "is a significant voice and influencer in the
community" is a contentious question, and one that FIG has debated for years.
Without going too far down that rabbit hole I will only say "it's very
complicated" and not cut and dry either direction.
Given the volume of people who currently votes on RFCs on average,
that would literally mean that we would increase our average voting
pool by 25%, something to consider as by then the FIG would
essentially sit with about a 20% say in whether or not something
should go in and their hands will stay clean because we as maintainers
will have to do the dirty work and that is without projects like
Laravel, Symfony and WordPress having a say, just the FIG.
To answer both you and Sanislav here together, as he raised a similar point,
that presumes that 100% of the "invited outsiders" vote on every RFC. I think
that is unlikely, although I freely admit I have no real data to speculate
either way. Lacking any other evidence I'd say it would probably follow a
similar pattern to Internals day. (If we assume a 175 person voting pool and
a turnout of about 50, then that's in the neighborhood of 25-30%.)
Truthfully, though, none of us have any idea what the total impact would be.
That same point applies to any "invited outsiders", whether that's done
through FIG or otherwise. Per Zeev's email, it does seem like some mechanism
for invited-outsiders was always intended, even if it never materialized.
(Disclosure: I am a member of the Core Committee so that would include me;
I hope that doesn't itself turn anyone off of the idea :-), but I mention
it for transparency and feel it would be a good approach even if I
weren't.)
That itself worries me, because you are represent a part of the
community using the language, but you are not a language designer. You
are active with input on internals and RFCs etc, which I respect a
lot, but without any interest in actually writing code (I can't really
say if its true or not regarding the interest or its because of C
know-how) or because of time schedules like we all have, I don't see
why a special exception should be granted. No offense.
To clarify: I last wrote C code in 2004 for Palm OS. I am quite rusty; on top
of that I know just enough about Internals to say that it's not as much
written in C as it is in a macro language built in C, so the learning curve
would be rather high. My personal lack of involvement in actual Internals
code is mainly because the logistical barrier to re-learning enough tooling
and language to do so is too high given that I have no professional
justification for it. I try to contribute to the PHP ecosystem in other ways
instead, internals or otherwise.
Whether or not I am personally impacted, though, I do feel and have long felt
that a more direct mechanism for user-land developers to have some influence
on PHP would be beneficial. (Though, yes, considerably less than the direct
contributors working on the code base, who should still be the predominant
constituency.)
--Larry Garfield
Hi!
What's the threshold of absurdity here? That we could debate. However, it is
not 0. (I'd personally put it in the 10-20 range, bearing in mind that not
all of them would vote all the time anyway, just like core developers, but
others may feel differently.)
I am not sure defining it in numeric terms is the correct approach.
After all, the RFC doesn't say now "20 non-C developers", it says
"PHP-FIG members". We have no control (and no desire to control) what
that means, but we pre-commit to giving all these people, whoever they
are and will be, voting rights now and forever in the future. I'm not
sure that's the right approach.
In fact, I'm also not sure "20 non-C developers" would be the right
approach - why specifically 20? What if we need 21? What if we can't
find even 10 who are really qualified? (all hypothetical of course) That
just sounds so arbitrary.
So I think we need to find something that doesn't look arbitrary and
doesn't look like putting voting eligibility in the project outside of
project members' control.
Stas Malyshev
smalyshev@gmail.com
Den søn. 3. feb. 2019 kl. 19.29 skrev Larry Garfield larry@garfieldtech.com:
It's not absurd, it's a matter of degrees. As Zeev noted in a later email,
the current voting RFC already calls for some voting-level input from "major
customers", but not a controlling vote.
To use hyperbolic examples:Would adding one single non-C-developer to the voting rolls mean that "the
Core Developers have to maintain code that is decided by external, non
contributing parties"? No, that's "kinda absurd" to call it that, because
that one voter is clearly swamped out by the many other Internals developers
that are also voting.
You and I both know the average turn-out of people voting here on
RFCs, that I do not doubt you follow in anyway and then you know that
if we add that top plus additional projects not represented under the
FIG, then that is a large deciding factor and don't tell me that
everyone who could get the ability by getting a vote won't be doing so
for at least the first long while. I do believe it will decrease over
time yes, but anytime soon if it passes.
Would adding 200 non-C developers to the voting roll mean that? Certainly
yes, that would be an absurd situation. But no one that I've seen is
suggesting that at all, or anything close to it.
There has to a limit. Whether it is 1 or 200 or even 1000 doesn't
matter. As long as it is more than 0 externals that has a direct
deciding factor for a change. There is a fine line whether a non
project member should have a say in the voting which is apart of our
project management over actively listening and engaging with the
community and taking that feedback into shaping PHP. The line I'm
trying to write here in bold is that having a say doesn't mean voting
power by any means.
If you as userland believes that we as the language project do not
include your feedback, then let's have a discussion about that in a
thread and look at how we can make a more engaging and open way to
actively work on what the community would want to see coming into PHP.
I do not believe influence should be linked to voting power within the
project by any means, that is one of my main arguments against this.
What's the threshold of absurdity here? That we could debate. However, it is
not 0. (I'd personally put it in the 10-20 range, bearing in mind that not
all of them would vote all the time anyway, just like core developers, but
others may feel differently.)
As long as a non project contributor, as have the power in the form of
being able to vote and therefore directly affect the active ones. That
is my threshold of absurdity and in a way I'm baffled that you do not
seem to understand that.
To answer both you and Sanislav here together, as he raised a similar point,
that presumes that 100% of the "invited outsiders" vote on every RFC. I think
that is unlikely, although I freely admit I have no real data to speculate
either way. Lacking any other evidence I'd say it would probably follow a
similar pattern to Internals day. (If we assume a 175 person voting pool and
a turnout of about 50, then that's in the neighborhood of 25-30%.)
Truthfully, though, none of us have any idea what the total impact would be.
As a continuation of my answer above to this one; By looking at the
average turnout of people voting as it is now, there is a 50%+ of
people with just doc karma in one way or another (single translation),
just PEAR or even some without any form of karma voting. Looking at
the list of the 175 or so posted, it is a very small margin of those
on average that votes for RFCs, meaning that adding externals to the
top of that, that number in my original email is gonna be a lot larger
and therefore a lot more dangerous if we open the floodgates like
that.
That same point applies to any "invited outsiders", whether that's done
through FIG or otherwise. Per Zeev's email, it does seem like some mechanism
for invited-outsiders was always intended, even if it never materialized.
Back then I was also against that, and I'm happy it didn't materialize
further on the voting aspect. This gives us a chance to clean this
system up and streamline the processes.
To clarify: I last wrote C code in 2004 for Palm OS. I am quite rusty; on top
of that I know just enough about Internals to say that it's not as much
written in C as it is in a macro language built in C, so the learning curve
would be rather high. My personal lack of involvement in actual Internals
code is mainly because the logistical barrier to re-learning enough tooling
and language to do so is too high given that I have no professional
justification for it. I try to contribute to the PHP ecosystem in other ways
instead, internals or otherwise.Whether or not I am personally impacted, though, I do feel and have long felt
that a more direct mechanism for user-land developers to have some influence
on PHP would be beneficial. (Though, yes, considerably less than the direct
contributors working on the code base, who should still be the predominant
constituency.)
That I do agree with. But like I mention above in the reply, I do not
believe that influence should be on the behalf of voting power. The
PHP community is large, exceptionally large and while I wish there
were ways was more open for developers to join the "conversation", I
do not see how we can start tackling that, which itself is perhaps a
topic for another thread on its own.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Den søn. 3. feb. 2019 kl. 19.29 skrev Larry Garfield larry@garfieldtech.com:
To answer both you and Sanislav here together, as he raised a similar point,
that presumes that 100% of the "invited outsiders" vote on every RFC. I think
that is unlikely, although I freely admit I have no real data to speculate
either way. Lacking any other evidence I'd say it would probably follow a
similar pattern to Internals day. (If we assume a 175 person voting pool and
a turnout of about 50, then that's in the neighborhood of 25-30%.)
Truthfully, though, none of us have any idea what the total impact would be.As a continuation of my answer above to this one; By looking at the
average turnout of people voting as it is now, there is a 50%+ of
people with just doc karma in one way or another (single translation),
just PEAR or even some without any form of karma voting. Looking at
the list of the 175 or so posted, it is a very small margin of those
on average that votes for RFCs, meaning that adding externals to the
top of that, that number in my original email is gonna be a lot larger
and therefore a lot more dangerous if we open the floodgates like
that.
In my opinion, the question “who is eligible to vote” is closely tied to
the RFC at hand. For instance, str_begins() wouldn't be much of a
maintainance burden, and whether it should be included into the PHP core
could very well also be decided by some of those who won't contribute to
the implementation/maintainance. On the other hand, whether to add JIT
compilation may better only be decided by those who would have to
maintain the implementation and who can assess related issues and
pitfalls (I'm none of those), but not by those who only can fancy “hey,
JIT is cool – let's have it!” It's obviously hard to lay down
respective rules, though.
Anyhow, instead of suggesting some “general improvements/refinements” to
the RFC process, in my opinion, we should identify where exactly our
RFC process has failed, and why it did so. Then we should eliminate
the bugs (if there are any).
--
Christoph M. Becker
Den tir. 5. feb. 2019 kl. 02.10 skrev Christoph M. Becker cmbecker69@gmx.de:
In my opinion, the question “who is eligible to vote” is closely tied to
the RFC at hand. For instance, str_begins() wouldn't be much of a
maintainance burden, and whether it should be included into the PHP core
could very well also be decided by some of those who won't contribute to
the implementation/maintainance.
I agree with that as long as it is without the PHP Project boundaries,
as the deciding vote is done by actual active PHP.net contributors.
For me the line about who within project can vote is up for
discussion, tho somewhere I feel it should be those with php-src karma
but I do believe anyone actively contributing to PHP as a project by
code should have the ability to vote in one way or another as a
privilege of continuous effect put into the project as a whole. I do
not believe the deciding factor should be in the hands of people
outside the project but that we as developers of the project HEARS
them and respect their voice while putting a sense of personal bias
aside like I replied to Larry in my first mail.
On the other hand, whether to add JIT
compilation may better only be decided by those who would have to
maintain the implementation and who can assess related issues and
pitfalls (I'm none of those), but not by those who only can fancy “hey,
JIT is cool – let's have it!” It's obviously hard to lay down
respective rules, though.Anyhow, instead of suggesting some “general improvements/refinements” to
the RFC process, in my opinion, we should identify where exactly our
RFC process has failed, and why it did so. Then we should eliminate
the bugs (if there are any).
I think that is a healthy approach, and by reading parts of this RFC
it does sound like Zeev indeed did build on this. With the 3 current
threads we have going, despite a bit confusing, I do think we have
started to open up the can of worms that is our RFC process and slowly
work our way to see what we can do to improve that.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Den tir. 5. feb. 2019 kl. 02.22 skrev Kalle Sommer Nielsen kalle@php.net:
I agree with that as long as it is without the PHP Project boundaries,
s/without/within
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Without further ado, an RFC that’s attempting to comprehensively
solve many of the issues that have plagued our RFC process since it
was hastily introduced in 2011:
Being mostly outside I wonder a bit whether it would make sense that
inactive developers at some point lose their voting right.
Reasoning: If somebody is out of the project for 10 years they probably
lost track on how the language and needs evolved and just voting since
an old friend needed a deciding vote is bad.
For groups like FIG I am uncertain. I think it is a good thing if we
push more things out of PHP itself into the userspace (JIT, FFI, ...
allow more and more stuff to be done in userspace) and thus
coordinating with userspace developers and setting standards and
interoperability there is good. However it are the maintainers who
(often voluntarily) have to maintain these things and overruling actual
maintainers is bad as they lose interest.
johannes
Hi!
I haven't fully read the RFC yet, so I'll come back with more formed
opinion about it probably, but wanted to comment about a couple of
points here:
Reasoning: If somebody is out of the project for 10 years they probably
lost track on how the language and needs evolved and just voting since
an old friend needed a deciding vote is bad.
I agree, though "out of project" can differ... But I think if the person
had made no contribution for a decade, then probably he wouldn't be very
well informed voter. Easier way would be to make the list of such people
and let them ask on the list that their vote will be kept if they want
to, with explanation on how they plan to continue contribute (we don't
have to require actual contribution, just people promising to do so - we
are all volunteers here anyway). People that have long moved on would
just ignore that, and people who want to come back will do so.
For groups like FIG I am uncertain. I think it is a good thing if we
push more things out of PHP itself into the userspace (JIT, FFI, ...
allow more and more stuff to be done in userspace) and thus
coordinating with userspace developers and setting standards and
interoperability there is good. However it are the maintainers who
(often voluntarily) have to maintain these things and overruling actual
maintainers is bad as they lose interest.
Yeah I'm feeling a bit uneasy about the FIG part too. I mean, having
input from major userspace groups is great. But having input and having
deciding voice is a different thing. Discussion and vote are different
processes, both important but with different results. So I wonder if we
can't find some venue to collect this feedback without having people who
aren't core developers decide for core developers what should they do.
This sounds like something that won't be healthy.
Stas Malyshev
smalyshev@gmail.com
On Thu, Jan 31, 2019 at 11:57 PM Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
I haven't fully read the RFC yet, so I'll come back with more formed
opinion about it probably, but wanted to comment about a couple of
points here:Reasoning: If somebody is out of the project for 10 years they probably
lost track on how the language and needs evolved and just voting since
an old friend needed a deciding vote is bad.I agree, though "out of project" can differ... But I think if the person
had made no contribution for a decade, then probably he wouldn't be very
well informed voter. Easier way would be to make the list of such people
and let them ask on the list that their vote will be kept if they want
to, with explanation on how they plan to continue contribute (we don't
have to require actual contribution, just people promising to do so - we
are all volunteers here anyway). People that have long moved on would
just ignore that, and people who want to come back will do so.For groups like FIG I am uncertain. I think it is a good thing if we
push more things out of PHP itself into the userspace (JIT, FFI, ...
allow more and more stuff to be done in userspace) and thus
coordinating with userspace developers and setting standards and
interoperability there is good. However it are the maintainers who
(often voluntarily) have to maintain these things and overruling actual
maintainers is bad as they lose interest.Yeah I'm feeling a bit uneasy about the FIG part too. I mean, having
input from major userspace groups is great. But having input and having
deciding voice is a different thing. Discussion and vote are different
processes, both important but with different results. So I wonder if we
can't find some venue to collect this feedback without having people who
aren't core developers decide for core developers what should they do.
This sounds like something that won't be healthy.Stas Malyshev
smalyshev@gmail.com--
The more I think about this, the less I like it. According to the page
linked to from the RFC, there are 51 current FIG members who would gain a
vote. So this RFC would strip most contributers of their voting rights
(including me), while simultaneously adding 51 new voters, all from the
same external organization (one that has been aggressively gunning for
"official" recognition since its inception). In other words, this RFC, in
its current form, would have effectively handed control over the entire PHP
project to FIG. Though I'm sure it was never the intent, TBH, this does
feel like a bit of a slap in the face to past contributors who still have
good ideas to offer now and then and should still have a voice.
Furthermore, it seems strange to me that a provision with such massive and
far-reaching implications would be quietly buried at the bottom of an RFC
filled with otherwise popular, non-controversial ideas.
There are a lot of people like me who, while we may not be active core
contributors, we have contributed in different ways over the years and we
deserve better than to be pushed aside like this. I dedicated a full year
of my life to this project and made a number of contributions to our test
automation during that time, as well as put a lot of time into testing and
debugging during the 5.3.3 release cycle. To say that I should be denied a
vote now only serves to discourage me from being active again in the
future. While I agree that we should tighten-up our standards regarding
who gets to vote, I am increasingly convinced that attempting to apply it
retroactively to existing contributors at all would be a mistake. It just
looks like a solution in search of a problem, seeing as how most of those
inactive people don't vote anymore, anyway. Furthermore, having a more
diverse voter base that includes people not directly involved with the
day-to-day core work helps to prevent any changes that would be wildly
unpopular with the community from being rubber-stamped.
I'm sorry but I must repeat my request that this provision be removed and
placed in a separate RFC. I don't see how there's any way I'd be able to
support this otherwise. Are you outright refusing to split it up or are
you open to discussing it in light of these concerns that have been raised
by myself and others?
--Kris
The more I think about this, the less I like it. According to the page
linked to from the RFC, there are 51 current FIG members who would gain a
vote. So this RFC would strip most contributers of their voting rights
(including me), while simultaneously adding 51 new voters, all from the
same external organization (one that has been aggressively gunning for
"official" recognition since its inception). In other words, this RFC, in
its current form, would have effectively handed control over the entire PHP
project to FIG. Though I'm sure it was never the intent, TBH, this does
feel like a bit of a slap in the face to past contributors who still have
good ideas to offer now and then and should still have a voice.
The question of the whether FIG is to become a core standard and
everything is then based of it is perhaps the real RFC here? That move
would bring FIG developers in simply because their contributions would
be direct to the PHP code base? That it does now seem to be the de-facto
standard may detract from a formal discussion as to if it should be THE
roadmap moving forward? Much like composer is now so enshrined in new
projects but is at adds with much legacy code? Bringing in blocks of
'voters' who have a different development style before deciding if that
style is acceptable just seems wrong?
--
Lester Caine - G8HFL
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
On Thu, Jan 31, 2019 at 11:57 PM Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
I haven't fully read the RFC yet, so I'll come back with more formed
opinion about it probably, but wanted to comment about a couple ofpoints here:
Reasoning: If somebody is out of the project for 10 years they probably
lost track on how the language and needs evolved and just voting since
an old friend needed a deciding vote is bad.I agree, though "out of project" can differ... But I think if the person
had made no contribution for a decade, then probably he wouldn't be very
well informed voter. Easier way would be to make the list of such people
and let them ask on the list that their vote will be kept if they want
to, with explanation on how they plan to continue contribute (we don't
have to require actual contribution, just people promising to do so - we
are all volunteers here anyway). People that have long moved on would
just ignore that, and people who want to come back will do so.For groups like FIG I am uncertain. I think it is a good thing if we
push more things out of PHP itself into the userspace (JIT, FFI, ...
allow more and more stuff to be done in userspace) and thus
coordinating with userspace developers and setting standards and
interoperability there is good. However it are the maintainers who
(often voluntarily) have to maintain these things and overruling actual
maintainers is bad as they lose interest.Yeah I'm feeling a bit uneasy about the FIG part too. I mean, having
input from major userspace groups is great. But having input and having
deciding voice is a different thing. Discussion and vote are different
processes, both important but with different results. So I wonder if we
can't find some venue to collect this feedback without having people who
aren't core developers decide for core developers what should they do.
This sounds like something that won't be healthy.Stas Malyshev
smalyshev@gmail.com--
The more I think about this, the less I like it. According to the page
linked to from the RFC, there are 51 current FIG members who would gain a
vote. So this RFC would strip most contributers of their voting rights
(including me), while simultaneously adding 51 new voters, all from the
same external organization (one that has been aggressively gunning for
"official" recognition since its inception). In other words, this RFC, in
its current form, would have effectively handed control over the entire PHP
project to FIG. Though I'm sure it was never the intent, TBH, this does
feel like a bit of a slap in the face to past contributors who still have
good ideas to offer now and then and should still have a voice.
Furthermore, it seems strange to me that a provision with such massive and
far-reaching implications would be quietly buried at the bottom of an RFC
filled with otherwise popular, non-controversial ideas.
Two points here:
-
Please see my earlier message. The way FIG is structured, one could extend
voting rights to project representatives, the core committee, both, or
neither. The core committee is 12 people. Project reps are ~36 currently.
Adding 12 people to the voting pool would not "effectively hand control over
the entire PHP project to FIG". That's complete hyperbole. Even if it were
all 50 people, that's still less than a third the number of people that would
currently pass Zeev's proposed filter for direct contributors. It may be too
large an external constituency, but it's a long, long way from a controlling
majority. -
To say that FIG "has been aggressively gunning for "official" recognition
since its inception" is false. The "PHP Standards Group" that originally
self-formed in 2009, yes, presumed a lot more official status than it was due,
and was (rightly) thrown off of the php.net infrastructure as a result. That
was a decade ago and FIG today is a very different organization. It does not
claim any authority or official-ness beyond "a lot of people listen to our
recommendations", which is objectively true.
Using FIG as a proxy for community voters may or may not make sense in the
long run, but please do not misrepresent either FIG or Zeev's proposal.
--Larry Garfield
All,
I have managed to avoid commenting on PHP-FIG since the group was dissolved, then re-constituted under the same name, without my participation as one of its original founding members.
However, I cannot let this phrasing pass:
FIG today is a very different organization. It does not
claim any authority or official-ness beyond "a lot of people listen to our
recommendations", which is objectively true.
Larry is trying to play both sides here with plausible deniability. Quoting him from https://www.sitepoint.com/the-past-present-and-future-of-the-php-fig/ :
FIG has effectively become the standards body for PHP. It took time for it to earn it, but it did, thanks to the work of dozens of people, both FIG members and not. A Reddit thread started last January showed that, while not universal, there was a clear preference for FIG to step up and accept that role formally.
Either Larry feels that FIG is effectively a standards body, or he does not.
And now that I have spoken, I may be more to say on the matter -- but not just yet.
--
Paul M. Jones
pmjones@pmjones.io
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
Hi!
- Please see my earlier message. The way FIG is structured, one could extend
voting rights to project representatives, the core committee, both, or
neither. The core committee is 12 people. Project reps are ~36 currently.
Adding 12 people to the voting pool would not "effectively hand control over
the entire PHP project to FIG". That's complete hyperbole. Even if it were > all 50 people, that's still less than a third the number of people
that would
Please note that people eligible to vote and people actually voting are
very different. 39 people voted on FFI RFC, 71 people on properties RFC,
48 on preloading RFC. Adding 50 votes to that could significantly change
the dynamic (in fact, it would be possible to change an unanimously
passing RFC to a failed one). And as many of us who watched political
elections know, you don't always need controlling majority to wield very
significant influence - sometimes just being able to change a marginal
vote goes a long way.
Now, don't get me wrong - I do think group like FIG should have some
influence on what we decide, and an input from such a group would be
very valuable. However, I think that if there's a marginal vote and
votes from people who do not directly contribute to the project would be
instrumental to significantly changing the outcome, this would not make
a healthy community dynamic. There's a difference between providing
input and advice and having decisive power, and I think while the advice
is highly valuable and welcome, the decisive power should be with those
who actually implements and maintains stuff.
--
Stas Malyshev
smalyshev@gmail.com
Without further ado, an RFC that’s attempting to comprehensively solve many of the issues that have plagued our RFC process since it was hastily introduced in 2011:
Hi Zeev,
Please can you very clearly state what problem you are trying to solve
by changing the rules about who can vote.
Without presenting the problem, and why your solution is the correct
one, it's not obvious that the change being proposed is either needed
or the right one choice.
Additionally, giving a vote to members of PHP-Fig is not a good idea
for multiple reasons.
- They are not language designers and they do not know PHP internals.
They cannot evaluate the tradeoffs of changes. - The membership requirements of the FIG were 'gamed' by some projects
by using bots to create fake stars on Github and number of downloads
to meet the requirements for FIG membership. - Other members such as Symfony, Laravel and Doctine have left FIG.
btw, you seem to have completely overlooked extension maintainers from
your list of people who should have a vote on PHP internals.
cheers
Dan
Ack
btw, you seem to have completely overlooked extension maintainers from
your list of people who should have a vote on PHP internals.
And those who have involved themselves in writing tests for PHP through
events like TestFests, and who probably have more insight into the
internals of PHP than the average PHP developer, but sit astride the
fence between the core an duserland development
--
Mark Baker
|. \ -3
|J/ PHP |
|| | __ |
|| |m| |m|
I LOVE PHP
Without further ado, an RFC that’s attempting to comprehensively solve
many of the issues that have plagued our RFC process since it was hastily
introduced in 2011:Hi Zeev,
Please can you very clearly state what problem you are trying to solve
by changing the rules about who can vote.Without presenting the problem, and why your solution is the correct
one, it's not obvious that the change being proposed is either needed
or the right one choice.
Fair enough, I've heard that question from several others.
I'll use your email to clarify my motivation for the RFC, primarily on the
voting eligibility part - in slightly more detail than my reply to Nikita
on the other thread.
Beginning with the latter, the reality of things that the Voting RFC of
2011 was written in what was supposed to codify, and also structure a bit
more the already existing process of decision making that we had prior to
it. The structuring was mainly through the introduction of a voting
process, as well as some elements such as a mandatory discussion period.
However, it quickly became apparent that this RFC, that was written with a
certain 'working knowledge' of what was already happening de-facto, and
assuming these would continue - became treated as if it was the U.S.
constitution, and whatever wasn't in it - did not exist. Moreover - even
elements which were in fact in it (such as the voting eligibility), became
ignored - exclusively for the simple reason of the way the Wiki software,
used for voting, was implemented.
Edge cases came up over the years in all sorts of manners. The most recent
edge case which isn't handled by the terse, laconic 2011 Voting RFC is the
Abolishing Narrow Margins RFC, which went straight from de-facto
hibernation into a "we're about to vote" stage overnight. But there were
many others (and yes, one of the common ones was 'how do we choose between
50%+1 and 2/3', but it was by no means the only one). The goal here is to
provide clear cut answers to these cases, instead of leaving it up to the
RFC author to decide. Over the years, it became clear that RFC authors had
not only the ability to decide what goes into the RFC, but to also decide
much of the process surrounding the discussion and acceptance of the RFC -
filling the major voids that were present in the terse 2011 Voting RFC on
demand.
In terms of Voting Eligibility, here's what was written in the original RFC:
---quote---
There's no way around this 'small' issue. Changes made to the PHP language
will affect millions of people, and theoretically, each and every one of
them should have a say in what we do. For obvious reasons, though, this
isn't a practical approach.
The proposal here is for two audiences to participate in the voting process:
- People with php.net VCS accounts that have contributed code to PHP:
- Representatives from the PHP community, that will be chosen by those with
php.net VCS accounts- Lead developers of PHP based projects (frameworks, cms, tools, etc.)
- regular participant of internals discussions
---end quote---
Now, there are several things you can tell from the way this topic is
treated that are evident from this text. First, that the topic of Voting
Eligibility wasn't taken lightly, nor was there any intention to provide a
very low bar on who gets to vote. Secondly, which is a lot more
unfortunate, it's very terse and laconic - like the rest of the RFC - e.g.,
when stating how the folks from the the 2nd group of eligible voters will
be chosen - even though it's evident that the idea was that they will be
chosen, in one way or another; Heck, even the first group is open to
interpretation from the way it's written (although the intention was clear)
- code contributors to PHP - was supposed to mean folks that truly
contributed code to PHP, and not every person with a VCS account (it's
clearly a subset, even from the poor way it's written). Bear in mind that
Pierre Joye, that promoted this RFC - believed that we will be able to
figure these parts out as we go along. De-facto, what happened was very
different - overnight, because of the way the Wiki software was
implemented, anybody with a VCS account became an eligible voter, with the
same weight as Rasmus, myself, Nikita, or whomever else. This was never
the intention.
What was the intention? In a nutshell:
- Code contributors to php-src get a vote
- Everyone with a VCS account (wider audience) get the ability to choose
folks that are beyond the first group, that will also get a vote (with the
assumption that the number of folks elected in this way will not be nearly
as high as the number of folks with VCS accounts, and in fact, a lot lower
than the first group of code contributors - essentially, it was to bring
outside voices, but not effectively overtake and marginalize the voice of
the code contributors). Regrettably, how that was to take place was left
out of that laconic RFC - in the belief that "we'll figure it out".
The goal of the voting eligibility section in the updated RFC is to clarify
this. It's clear we have more work to do in this front here - but ignoring
this elephpant in the room shouldn't be an option anymore. It's just as
important, and arguably a lot more important, than the voting thresholds.
To me, the two are clearly interlinked, as is the potential question of a
quorum.
The barrier to obtaining a vote today is ridiculously low. Mostly anybody
I spoke with that I shared how easy it was to get a vote that's equal to a
person that's been contributing for years and has proven knowledge about
PHP for ages - was shocked. And indeed, our system where a person can
become an eligible voter almost overnight has no parallels (to the best of
my knowledge) in any other major OS project. Virtually all of them are
some form of meritocracy, and yes, that's despite all of them having impact
on millions of users. The situation where an open source project effects
millions of users isn't uncommon - it's standard in virtually all major OS
projects - and yet, none of them makes it this easy to have voting rights,
literally overnight, and with 100% equivalence to folks who have
contributed for years - the way PHP de-facto does.
We were supposed to be more advanced than other projects, by providing
folks that aren't code contributors with a way to also influence votes -
and I still think it's worth exploring ways of doing it. But at no point
was the intention to lower the bar so much, providing a vote for anybody
with a VCS account (which is very, very easy to get) with a vote. This is
unfair to ones who actually take the time and effort to work on the project
itself.
Additionally, giving a vote to members of PHP-Fig is not a good idea
for multiple reasons.
I'm not sold on it being a good idea either, especially seeing the level of
controversy it stirred here (by the way - it accounts for most of the
controversy on this thread, as far as I can tell - I think that the general
idea of voting eligibility was actually supported by many folks replying to
this thread, mainly because it's common sense and is present in all other
major OS projects).
I think we need to either come up with a mechanism - that's reasonably
well-defined - to bring the 'voice of the masses' into the voting process,
that would not be biased towards one particular group - or we simply stick
with the first group only, with the reasonable assumption that they'll
factor in what they hear from these masses during the discussion period as
they come to vote. That's mostly how all other major OS projects work.
Another option might be going back to elements in the 2011 RFC (while
clearly clarifying it). Perhaps, defining some sort of a voting/election
process where code-contributors can elect non-code-contributors that will
also have a vote is a way to go. What I definitely don't want to repeat,
though, is having open-ended definitions.
I'll reply to more elements in this thread later tonight - had an unusually
busy weekend...
Zeev
Without further ado, an RFC that’s attempting to comprehensively solve
many of the issues that have plagued our RFC process since it was hastily
introduced in 2011:Hi Zeev,
Please can you very clearly state what problem you are trying to solve
by changing the rules about who can vote.Without presenting the problem, and why your solution is the correct
one, it's not obvious that the change being proposed is either needed
or the right one choice.Fair enough, I've heard that question from several others.
I'll use your email to clarify my motivation for the RFC, primarily on the
voting eligibility part - in slightly more detail than my reply to Nikita
on the other thread.Beginning with the latter, the reality of things that the Voting RFC of
2011 was written in what was supposed to codify, and also structure a bit
more the already existing process of decision making that we had prior to
it. The structuring was mainly through the introduction of a voting
process, as well as some elements such as a mandatory discussion period.
However, it quickly became apparent that this RFC, that was written with a
certain 'working knowledge' of what was already happening de-facto, and
assuming these would continue - became treated as if it was the U.S.
constitution, and whatever wasn't in it - did not exist. Moreover - even
elements which were in fact in it (such as the voting eligibility), became
ignored - exclusively for the simple reason of the way the Wiki software,
used for voting, was implemented.Edge cases came up over the years in all sorts of manners. The most recent
edge case which isn't handled by the terse, laconic 2011 Voting RFC is the
Abolishing Narrow Margins RFC, which went straight from de-facto
hibernation into a "we're about to vote" stage overnight. But there were
many others (and yes, one of the common ones was 'how do we choose between
50%+1 and 2/3', but it was by no means the only one). The goal here is to
provide clear cut answers to these cases, instead of leaving it up to the
RFC author to decide. Over the years, it became clear that RFC authors had
not only the ability to decide what goes into the RFC, but to also decide
much of the process surrounding the discussion and acceptance of the RFC -
filling the major voids that were present in the terse 2011 Voting RFC on
demand.In terms of Voting Eligibility, here's what was written in the original
RFC:---quote---
There's no way around this 'small' issue. Changes made to the PHP language
will affect millions of people, and theoretically, each and every one of
them should have a say in what we do. For obvious reasons, though, this
isn't a practical approach.The proposal here is for two audiences to participate in the voting
process:
- People with php.net VCS accounts that have contributed code to PHP:
- Representatives from the PHP community, that will be chosen by those with
php.net VCS accounts
- Lead developers of PHP based projects (frameworks, cms, tools, etc.)
- regular participant of internals discussions
---end quote---Now, there are several things you can tell from the way this topic is
treated that are evident from this text. First, that the topic of Voting
Eligibility wasn't taken lightly, nor was there any intention to provide a
very low bar on who gets to vote. Secondly, which is a lot more
unfortunate, it's very terse and laconic - like the rest of the RFC - e.g.,
when stating how the folks from the the 2nd group of eligible voters will
be chosen - even though it's evident that the idea was that they will be
chosen, in one way or another; Heck, even the first group is open to
interpretation from the way it's written (although the intention was clear)
- code contributors to PHP - was supposed to mean folks that truly
contributed code to PHP, and not every person with a VCS account (it's
clearly a subset, even from the poor way it's written). Bear in mind that
Pierre Joye, that promoted this RFC - believed that we will be able to
figure these parts out as we go along. De-facto, what happened was very
different - overnight, because of the way the Wiki software was
implemented, anybody with a VCS account became an eligible voter, with the
same weight as Rasmus, myself, Nikita, or whomever else. This was never
the intention.What was the intention? In a nutshell:
- Code contributors to php-src get a vote
- Everyone with a VCS account (wider audience) get the ability to choose
folks that are beyond the first group, that will also get a vote (with the
assumption that the number of folks elected in this way will not be nearly
as high as the number of folks with VCS accounts, and in fact, a lot lower
than the first group of code contributors - essentially, it was to bring
outside voices, but not effectively overtake and marginalize the voice of
the code contributors). Regrettably, how that was to take place was left
out of that laconic RFC - in the belief that "we'll figure it out".The goal of the voting eligibility section in the updated RFC is to clarify
this. It's clear we have more work to do in this front here - but ignoring
this elephpant in the room shouldn't be an option anymore. It's just as
important, and arguably a lot more important, than the voting thresholds.
To me, the two are clearly interlinked, as is the potential question of a
quorum.The barrier to obtaining a vote today is ridiculously low. Mostly anybody
I spoke with that I shared how easy it was to get a vote that's equal to a
person that's been contributing for years and has proven knowledge about
PHP for ages - was shocked. And indeed, our system where a person can
become an eligible voter almost overnight has no parallels (to the best of
my knowledge) in any other major OS project. Virtually all of them are
some form of meritocracy, and yes, that's despite all of them having impact
on millions of users. The situation where an open source project effects
millions of users isn't uncommon - it's standard in virtually all major OS
projects - and yet, none of them makes it this easy to have voting rights,
literally overnight, and with 100% equivalence to folks who have
contributed for years - the way PHP de-facto does.We were supposed to be more advanced than other projects, by providing
folks that aren't code contributors with a way to also influence votes -
and I still think it's worth exploring ways of doing it. But at no point
was the intention to lower the bar so much, providing a vote for anybody
with a VCS account (which is very, very easy to get) with a vote. This is
unfair to ones who actually take the time and effort to work on the project
itself.Additionally, giving a vote to members of PHP-Fig is not a good idea
for multiple reasons.
I'm not sold on it being a good idea either, especially seeing the level of
controversy it stirred here (by the way - it accounts for most of the
controversy on this thread, as far as I can tell - I think that the general
idea of voting eligibility was actually supported by many folks replying to
this thread, mainly because it's common sense and is present in all other
major OS projects).I think we need to either come up with a mechanism - that's reasonably
well-defined - to bring the 'voice of the masses' into the voting process,
that would not be biased towards one particular group - or we simply stick
with the first group only, with the reasonable assumption that they'll
factor in what they hear from these masses during the discussion period as
they come to vote. That's mostly how all other major OS projects work.Another option might be going back to elements in the 2011 RFC (while
clearly clarifying it). Perhaps, defining some sort of a voting/election
process where code-contributors can elect non-code-contributors that will
also have a vote is a way to go. What I definitely don't want to repeat,
though, is having open-ended definitions.I'll reply to more elements in this thread later tonight - had an unusually
busy weekend...Zeev
I just want to reiterate that there are other good ideas in this RFC that
would probably pass easily. I strongly urge you to move the voting to a
separate RFC.
--Kris
Hi Zeev,
Please can you very clearly state what problem you are trying to solve
by changing the rules about who can vote.Fair enough, I've heard that question from several others.
I've read all 1200 words of your reply, which is quite a few words.
I still can't see a clear description of what problem you're trying to
solve by changing who can vote.
The reason I'm being pedantic about this, is that when people just
discuss possible solutions to a vague sense of "this situation isn't
perfect", they will often suggest things that don't actually address
the underlying problem. Or disagree about details that don't actually
matter.
We really can't have a clear conversation about what to change without
a clear description of the problem that ought to be solved.
For example, if the fundamental problem you are trying to address is
that it's too difficult for people to get a vote, then I would support
documenting what our current system is, and allowing people to know
what they need to do to acquire a vote. If the fundamental problem the
RFC is trying to address, is to bring in a whole load of new voters,
who don't know how PHP works internally, then I wouldn't be as
supportive.
cheers
Dan
Ack
-----Original Message-----
From: Dan Ackroyd Danack@basereality.com
Sent: Sunday, February 3, 2019 10:24 PM
To: Zeev Suraski zeev@php.net
Cc: PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)On Fri, Feb 1, 2019 at 7:14 PM Dan Ackroyd Danack@basereality.com
wrote:Hi Zeev,
Please can you very clearly state what problem you are trying to
solve by changing the rules about who can vote.Fair enough, I've heard that question from several others.
I've read all 1200 words of your reply, which is quite a few words.
I still can't see a clear description of what problem you're trying to solve by
changing who can vote.
To summarize the issues (all written in my response):
- Voting rights today are assigned in a way that isn't consistent with our current Voting RFC, nor that was ever intended in any point.
- Due to an unintended consequence of a Wiki implementation detail, the barrier to obtaining a vote is ridiculously low.
- The current system has no parallels in the world of major OS projects - which I do view as a problem, as I don't think we're inherently different from every other major OS project out there.
I realize we now have some sort of status quo that we're used to, but it does not mean it's a sensible status quo.
The reason I'm being pedantic about this, is that when people just discuss
possible solutions to a vague sense of "this situation isn't perfect", they will
often suggest things that don't actually address the underlying problem. Or
disagree about details that don't actually matter.We really can't have a clear conversation about what to change without a clear
description of the problem that ought to be solved.For example, if the fundamental problem you are trying to address is that it's too
difficult for people to get a vote, then I would support documenting what our
current system is, and allowing people to know what they need to do to acquire
a vote. If the fundamental problem the RFC is trying to address, is to bring in a
whole load of new voters, who don't know how PHP works internally, then I
wouldn't be as supportive.
I've been doing a horrible job at explaining myself if that's what you think I'm trying to do. I'm certainly not trying to address a(n IMHO) non-existent problem that it's too difficult to get a vote, or getting a whole load of new voters. Quite the opposite - I think we have way too many eligible voters today, roughly an order of magnitude greater than originally intended. It's way too easy to obtain voting credentials, in a way that is, in my opinion, both problematic and unfair to the main contributors. The goal is to go back to the original definition from 7.5 years ago, make it clearer (there's more work to be done here), and then stick to it - without letting implementation details in the Wiki be the judge of who gets to vote. If we do it - the voting base will actually shrink from around two thousand today - perhaps even slightly more - to around 150-200.
To put things in perspective - there was quite some backlash regarding providing PHP-FIG with voting rights, which is an entirely valid opinion. At the same time - any person that ever contributed to PEAR (and consequently has a php.net account) - has immediate full voting rights. The fact of the matter is that out of the ~2000 users we have on php.net, less than 200 actually clear the bar set in the RFC (which isn't particularly high - 25 commits, 500 lines of code added/changed in the project). Out of those, more than a thousand haven't submitted anything at all to php-src, but have potentially submitted to other php.net projects (e.g. PEAR, or the php.net website), and an additional ~200 have affected fewer than 10 lines in php-src. Personally, I think it does tell us something about the viability of the current voting qualifications, and I don't think what it's telling us is positive.
Whether or not contributions to php-src should be the only criteria by which we admit voters is a good question. I'm personally still undecided on it - whether we should find a mechanism to admit non php-src contributors as voters (like folks from PHP-FIG, major PHP OS projects, etc.), or whether we should rely on their voices being heard in the discussions and then represented by the php-src contribs. What I personally think is clear, though, that the awkward status quo we currently live in needs fixing - and it's a good time to do it, as we discuss other elements such as voting margins and workflow.
Zeev
Hi,
I was avoiding this, but since the discussion has already turned into
all about who gets to vote, I might as well ...
the barrier to obtaining a vote is ridiculously low.
You keep saying that, but it hasn't been explained how it is so.
Is it the PEAR-only contributors that you want to eliminate? The doc &
translations teams? Old-timers who are no longer interested in the
project? Is there a common occurrence of existing leaders granting VCS
accounts to friends for no reason?
I mean, if you want to reduce thousands to sub-200, you might as well
put down all your cards.
Aside from a couple of past cases where "ghost" voters were mobilized
for a huge, controversial RFCs, I haven't seen a problem with the
current voting pool members (and thus see little reason to attempt to
change it), but I also think it's sensible that e.g. translating a
couple of lines in the docs isn't enough. In any case however, the
criteria and metrics that you've chosen are, to me, quite arbitrary
and only appear fair while not actually being so, especially the 25
commit count.
Full disclosure - that last one is what disqualifies me. Although, I
certainly don't consider myself a "core" developer, so if your
intention is to limit voting power to only that group I guess it has
achieved the goal in my case.
On the other hand, I qualify under all the current status-quo criteria
- I've contributed some code, features, tests, docs; had a couple of
RFCs; am a lead framework developer; participate somewhat regularly in
internals discussions - yet obtaining voting privilege wasn't as easy
as a "ridiculously low bar" would make you believe.
Anyone who has ever attempted to use such metrics for evaluation would
tell you that commit count is a horrible one. It makes no difference
between 25 and 25k lines, quality or significance.
It doesn't give any weight to participation in discussions either,
whether its on this list or code reviews, both of which I believe are
influential and valuable.
Some squash commits, some don't; I've had my own commits squashed AND
authored by the person who merged them, meaning my name isn't attached
to them at all. This is an example of a previously meaningless factor
all of a sudden becoming a deciding one.
There are some well-known names that don't make the cut in Appendix A
and that does raise an eyebrow.
If you want to say that there are people with voting privileges that
haven't earned them, that's one thing, but (and I'm not assuming bad
intentions with this) as it stands it looks like you just wanted to
cut as much as possible and only looked for a metric that wasn't going
to eliminate the very top contributors, whom you can't afford to lose.
Cheers,
Andrey.
Hi,
I was avoiding this, but since the discussion has already turned into
all about who gets to vote, I might as well ...the barrier to obtaining a vote is ridiculously low.
You keep saying that, but it hasn't been explained how it is so.
Is it the PEAR-only contributors that you want to eliminate? The doc &
translations teams? Old-timers who are no longer interested in the
project? Is there a common occurrence of existing leaders granting VCS
accounts to friends for no reason?
I mean, if you want to reduce thousands to sub-200, you might as well
put down all your cards.Aside from a couple of past cases where "ghost" voters were mobilized
for a huge, controversial RFCs, I haven't seen a problem with the
current voting pool members (and thus see little reason to attempt to
change it), but I also think it's sensible that e.g. translating a
couple of lines in the docs isn't enough. In any case however, the
criteria and metrics that you've chosen are, to me, quite arbitrary
and only appear fair while not actually being so, especially the 25
commit count.Full disclosure - that last one is what disqualifies me. Although, I
certainly don't consider myself a "core" developer, so if your
intention is to limit voting power to only that group I guess it has
achieved the goal in my case.
On the other hand, I qualify under all the current status-quo criteria
- I've contributed some code, features, tests, docs; had a couple of
RFCs; am a lead framework developer; participate somewhat regularly in
internals discussions - yet obtaining voting privilege wasn't as easy
as a "ridiculously low bar" would make you believe.Anyone who has ever attempted to use such metrics for evaluation would
tell you that commit count is a horrible one. It makes no difference
between 25 and 25k lines, quality or significance.
It doesn't give any weight to participation in discussions either,
whether its on this list or code reviews, both of which I believe are
influential and valuable.
Some squash commits, some don't; I've had my own commits squashed AND
authored by the person who merged them, meaning my name isn't attached
to them at all. This is an example of a previously meaningless factor
all of a sudden becoming a deciding one.
There are some well-known names that don't make the cut in Appendix A
and that does raise an eyebrow.If you want to say that there are people with voting privileges that
haven't earned them, that's one thing, but (and I'm not assuming bad
intentions with this) as it stands it looks like you just wanted to
cut as much as possible and only looked for a metric that wasn't going
to eliminate the very top contributors, whom you can't afford to lose.Cheers,
Andrey.--
Stripping any existing contributors of our voting rights is a non-starter
for me, period. Any changes must not be applied retroactively, as that
would just lead to all kinds of problems and severe animosity/drama.
The eligibility needs to be moved to its own RFC and fixed so that it
doesn't overreach by trying to force out existing voters. Otherwise you
can count me as a firm "no" on this one.
Hi again,
Stripping any existing contributors of our voting rights is a non-starter for me, period. Any changes must not be applied retroactively, as that would just lead to all kinds of problems and severe animosity/drama.
The eligibility needs to be moved to its own RFC and fixed so that it doesn't overreach by trying to force out existing voters. Otherwise you can count me as a firm "no" on this one.
Indeed, both excellent points and you can count me in favor of
splitting eligibiity into a separate RFC.
Cheers,
Andrey.
-----Original Message-----
From: Andrey Andreev narf@devilix.net
Sent: Tuesday, February 5, 2019 5:18 AM
To: Zeev Suraski zeev@php.net
Cc: Dan Ackroyd Danack@basereality.com; PHP internals
internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)You keep saying that, but it hasn't been explained how it is so.
It's simple. It's very easy to get a VCS account. You basically just ask,
and if the request is reasonable - you'll get one. It's enough for one of
the folks who have admin rights on master.php.net to think that the request
is reasonable for them to grant it to you. That's it.
You may consider that a reasonable bar, I don't. Nor was this ever a
bar agreed upon by the developers.
Is it the PEAR-only contributors that you want to eliminate? The doc &
translations teams? Old-timers who are no longer interested in the
project? Is
there a common occurrence of existing leaders granting VCS accounts to
friends
for no reason?
I mean, if you want to reduce thousands to sub-200, you might as well put
down
all your cards.
My cards are simple - the current de-facto bar is not sensible. It was
never intended. It is not backed by anything the code contributors ever
agreed to. It has no parallels in other OS projects. It stems from one
source and one source alone - it was the easiest way to get the voting
process up and running in a fully automated way. It would effect many
sub-groups, but the idea isn't about who to exclude, but rather - who to
include. It includes those who have contributed to the PHP project itself,
have made a sizeable contribution and over a period of time. Exactly like
it is in mostly every other open major source project (at least one that has
no BDFL(s)).
Aside from a couple of past cases where "ghost" voters were mobilized for
a
huge, controversial RFCs, I haven't seen a problem with the current voting
pool
members (and thus see little reason to attempt to change it), but I also
think it's
sensible that e.g. translating a couple of lines in the docs isn't enough.
In any
case however, the criteria and metrics that you've chosen are, to me,
quite
arbitrary and only appear fair while not actually being so, especially the
25
commit count.
We can (and should) debate the criteria. The rationale was to have bars on
both the contribution's size, as well as its breadth. The number of commits
tended to correlate with contributions over time, as opposed to one-time
contributions. There may be better ways of determining that, I'm open to
suggestions.
Full disclosure - that last one is what disqualifies me. Although, I
certainly don't
consider myself a "core" developer, so if your intention is to limit
voting power
to only that group I guess it has achieved the goal in my case.
Well, honestly, I don't think the 25 commit / 500 line bar qualifies anybody
as a core developer, and that's not what I'm trying to establish. It was
actually purposely what I at least consider a very low bar - that allows
newcomers to become voters relatively quickly (within several months to a
year), by showing a certain level of interest and commitment.
True core developers clear bars that are two orders of magnitude
larger, as you can see for yourself in the Git statistics.
On the other hand, I qualify under all the current status-quo criteria
- I've contributed some code, features, tests, docs; had a couple of RFCs;
am a
lead framework developer; participate somewhat regularly in internals
discussions - yet obtaining voting privilege wasn't as easy as a
"ridiculously low
bar" would make you believe.
Regardless of what you did, actually obtaining full voting rights
meant you had to ask for a VCS account, and have a reasonably good
explanation on why you need one - enough to convince one of the folks
with admin rights on master.php.net to click the 'Accept' button.
That's all. Immediately, one has identical rights to someone who may
have been spending years of their time on PHP, in a one way ticket.
Setting certain bars on the ability to influence the direction the
language is going does not in any way take away from the work you or
others did. PHP benefits greatly from contributions of hundreds of
thousands of people in various fronts. The vast majority of those
don't have voting powers today, including ones that have similar (or
different but equivalent) credentials to the ones you mentioned, but
didn't apply for a VCS account. Whether or not we should provide
non-code-contributors with voting rights is a tough question (as can
be seen on other posts on this thread), but I do think that the 'base
group' of those who should have voting powers should be the code
contributors - and we therefore need some definitions on what
qualifies one as a code contributor. Including other criteria (such
as tests, docs, framework contribution, etc.) is probably not
feasible, as it would be very difficult to apply in an even manner
(and no, what we have right now absolutely does not apply it in an
even manner). It may be that the code contributors (as we end up
defining them) could have a process to invite/elect non code
contributors as voters (temporary or permanent), or, as others
suggested, simply rely on non-code-contributors participating in the
discussion, and code contributors representing them in their votes.
Anyone who has ever attempted to use such metrics for evaluation would
tell
you that commit count is a horrible one. It makes no difference between 25
and
25k lines, quality or significance.
It doesn't give any weight to participation in discussions either, whether
its on
this list or code reviews, both of which I believe are influential and
valuable.
As I mentioned above, the criteria is open for debate. From my POV
though, having such a criteria and implementing it - even if it's 7.5
years too late - is a must.
I agree that a commit count isn't a good criteria on its own, but as
mentioned above - I think it adds value as an added bar for the
already-low 500 line count.
I consider both criteria as fairly low bars for full voting powers on
one of the most popular open source projects in the world.
That said, moving to a single criteria based exclusively on LOC is
also a possibility - although in such a case I'd go for a higher bar
than 500 LOC. Here's some experimentation:
sqlite> select count() from gitstats where insertions>=500 and commits>=25;
180
sqlite> select count() from gitstats where insertions>=500;
282
sqlite> select count() from gitstats where insertions>=1000;
228
sqlite> select count() from gitstats where insertions>=2000;
174
You can also experiment with it yourself:
https://www.dropbox.com/s/487bkzz1ukhxjhp/php-src.sqlite
Also note that the 'Grandfathering' period aims at providing a
reasonable transition for those who are borderline qualified to vote,
and gives them a full year to clear the bar to retain their full
voting rights.
Some squash commits, some don't; I've had my own commits squashed
authored by the person who merged them, meaning my name isn't attached to
them at all. This is an example of a previously meaningless factor all of
a sudden
becoming a deciding one.
There are some well-known names that don't make the cut in Appendix A and
that does raise an eyebrow.
I've had one person ask me about that exact same topic. What should
matter is the substance - and not what the automated scripts tell us.
I believe there will be several cases such as yours, where the dry
stats don't qualify you but the actual stats do. What would matter is
the latter - even if we need to do a bit of manual work in the
beginning (the list of voters won't be just 'calculated' from the
gitstats; It would feed to it, but we would also have some manual
override).
If you want to say that there are people with voting privileges that
haven't
earned them, that's one thing, but (and I'm not assuming bad intentions
with
this) as it stands it looks like you just wanted to cut as much as
possible and only
looked for a metric that wasn't going to eliminate the very top
contributors,
whom you can't afford to lose.
Again, I don't consider 500LOC / 25 commit as the 'very top
contributors' (especially on the LOC side). The variance in
contribution between these ~200 folks who qualify under this criteria
is huge. Had we wanted to go only for top contributors, we'd be left
with a lot fewer people (e.g. increasing it to 10K LOC cuts the list
in half) The criteria is supposed to be very achievable. I reran the
stats, and in the last 17 months (since Sep 2017), 5 additional people
cleared these bars, which I think is a very reasonable pace.
Zeev
Le mardi 5 février 2019, 10:36:48 CET Zeev Suraski a écrit :
Regardless of what you did, actually obtaining full voting rights
meant you had to ask for a VCS account, and have a reasonably good
explanation on why you need one - enough to convince one of the folks
with admin rights on master.php.net to click the 'Accept' button.
That's all. Immediately, one has identical rights to someone who may
have been spending years of their time on PHP, in a one way ticket.
To me that is the purpose of voting, what you’re saying is like complaining that in a democracy old people with experience has the same voting power than young ones.
I feel for votes to make sense you need a lot of people voting, a vote between the 10 core developers does not make a lot of sense, and could well be replaced by a discussion on a mailing list.
I’m also not sure why one would need to be coding PHP itself to be able to vote its direction, I feel it’s sane that people using it have a say in it.
I know you (or someone else) explained having a say in it does not necessarily means having voting power, but I feel it does.
I’m not sure without voting power I would follow closely RFCs as I do now.
So I think this is where my main disagreement with these criteria is: I like that people interested in PHP can get access to voting where it goes.
As I mentioned above, the criteria is open for debate. From my POV
though, having such a criteria and implementing it - even if it's 7.5
years too late - is a must.
I agree that a commit count isn't a good criteria on its own, but as
mentioned above - I think it adds value as an added bar for the
already-low 500 line count.
I consider both criteria as fairly low bars for full voting powers on
one of the most popular open source projects in the world.
You make it like it’s a gift for people to be able to vote on PHP RFCs while I feel like it’s good for PHP to have people voting its RFCs.
Also note that the 'Grandfathering' period aims at providing a
reasonable transition for those who are borderline qualified to vote,
and gives them a full year to clear the bar to retain their full
voting rights.
This is exactly the problem with such criteria: It will push people to do things just to get the criteria, like fix typos in comments or split features in several commits to make the count.
Voting system criteria should not influence the way we write the code.
One last point: Having non-core developers voting puts a higher bar on RFC redacting quality: The author needs to explain his feature well enough so that people without deep internal knowledge get it. This is a good thing.
Côme
Le mardi 5 février 2019, 10:36:48 CET Zeev Suraski a écrit :
Regardless of what you did, actually obtaining full voting rights
meant you had to ask for a VCS account, and have a reasonably good
explanation on why you need one - enough to convince one of the folks
with admin rights on master.php.net to click the 'Accept' button.
That's all. Immediately, one has identical rights to someone who may
have been spending years of their time on PHP, in a one way ticket.To me that is the purpose of voting, what you’re saying is like
complaining that in a democracy old people with experience has the same
voting power than young ones.
I feel for votes to make sense you need a lot of people voting, a vote
between the 10 core developers does not make a lot of sense, and could well
be replaced by a discussion on a mailing list.I’m also not sure why one would need to be coding PHP itself to be able to
vote its direction, I feel it’s sane that people using it have a say in it.
We'll have to agree to disagree on this one. I would say that the way
virtually every other major Open Source project serves as a fairly good
proof point for my position. In fact, even with the new eligible voting
criteria, we'd be well ahead of most other major OS projects in terms of
the number of people included in the process with full equal voting rights.
Zeev
Le mardi 5 février 2019, 11:53:01 CET Zeev Suraski a écrit :
We'll have to agree to disagree on this one. I would say that the way
virtually every other major Open Source project serves as a fairly good
proof point for my position. In fact, even with the new eligible voting
criteria, we'd be well ahead of most other major OS projects in terms of
the number of people included in the process with full equal voting rights.
I do not understand what this proves.
«No other project is doing that» is not a strong enough argument towards not doing it.
What is the problem you are actually trying to solve? That some RFCs are not passing?
Côme
Le mardi 5 février 2019, 11:53:01 CET Zeev Suraski a écrit :
We'll have to agree to disagree on this one. I would say that the way
virtually every other major Open Source project serves as a fairly good
proof point for my position. In fact, even with the new eligible voting
criteria, we'd be well ahead of most other major OS projects in terms of
the number of people included in the process with full equal voting
rights.I do not understand what this proves.
I'm not sure how I can deliver the point I was making in a better way than
I already did. The gap in the way you and I perceive the way OS project
governance should work is too big for this to be a fruitful discussion - so
as I said from in the beginning, let's just agree to disagree.
Zeev
Hi!
To me that is the purpose of voting, what you’re saying is like
complaining that in a democracy old people with experience has the
same voting power than young ones.
To be clear, PHP user community is not a democracy, neither we want to
be. In democracy, every person (marginal cases like resident aliens,
infants and prison inmates excluded) gets a vote, on the principle that
since the law apply to everyone, everyone must have a say in its design,
and once the majority decision is taken, it is mandatory to all members.
In software projects, I do not think there's been ever any project that
is a democracy of its users. While decisions of the project developers
do influence, undoubtedly, the users, it is universally true that the
users have no direct control over these decisions. Doing it the way
democracy is done would make the project ungovernable, and would likely
discourage most volunteers from working on it. Do you imagine Linus
asking a vote of all Linux users about how to implement a kernel driver
and implementing it only in a way that majority of Linux users approves?
I’m also not sure why one would need to be coding PHP itself to be
able to vote its direction,
Because whoever makes the thing defines how the thing is made (of
course, it takes more to make PHP than pure C coding, so I am bundling
all contributors to the project - however widely defined - together). If
you are to build a house, I am not going to tell you how to do it. It's
your house, you build it however you want it - even if you might later
invite me to visit. If I think the house is badly built, I may refuse to
come, and criticize you, but I won't claim the power to tell you how to
do it.
I feel it’s sane that people using it have a say in it.
Have a say, as in providing feedback and advice - sure, and they do.
Having decisive voice, overriding the voice of people who actually
implement it, in their own free time, and then give it away for free - no.
I know you (or someone else) explained having a say in it does not
necessarily means having voting power, but I feel it does. I’m not
Unfortunately, this is wrong.
sure without voting power I would follow closely RFCs as I do now. So
I think this is where my main disagreement with these criteria is: I
like that people interested in PHP can get access to voting where it
goes.
Being just "interested" is not enough to gain decisive power over what
other people are doing. If I'm interested in US politics, that doesn't
make me a Congressman.
You make it like it’s a gift for people to be able to vote on PHP
RFCs while I feel like it’s good for PHP to have people voting its
RFCs.
There's no abstract "PHP" that it'd be good for beyond people who
actually develop it. And I don't see how it'd be good for people who
develop it to give control over how to develop it to people that don't.
This is exactly the problem with such criteria: It will push people
to do things just to get the criteria, like fix typos in comments or
split features in several commits to make the count. Voting system
criteria should not influence the way we write the code.
If we get past contributors contributing again - even if by fixing typos
- I see nothing wrong with that. Maybe they'll get a taste for it and
then start fixing bugs and implementing extensions :)
In any case, I personally am for inclusion-biased system - but still not
"anything goes" system.
One last point: Having non-core developers voting puts a higher bar
on RFC redacting quality: The author needs to explain his feature
well enough so that people without deep internal knowledge get it.
I don't see how the voting process prevents people that didn't get it
from voting (either way). In a democracy, people do it all the time ;)
So this is really not a solid argument for your point.
--
Stas Malyshev
smalyshev@gmail.com
Le mardi 5 février 2019, 02:38:50 CET Stanislav Malyshev a écrit :
Hi!
Hi!
Do you imagine Linus
asking a vote of all Linux users about how to implement a kernel driver
and implementing it only in a way that majority of Linux users approves?
Not sure that would be so bad.
At least until it blocks everything and becomes a problem, but what I do not understand is that changing the RFC voters pool idea do not seem come from a problem with it, just some «These people are not writing C code, they should not vote» thinking.
Because whoever makes the thing defines how the thing is made (of
course, it takes more to make PHP than pure C coding, so I am bundling
all contributors to the project - however widely defined - together). If
you are to build a house, I am not going to tell you how to do it. It's
your house, you build it however you want it - even if you might later
invite me to visit. If I think the house is badly built, I may refuse to
come, and criticize you, but I won't claim the power to tell you how to
do it.
This is where we disagree, PHP devs are not building a house for themselves, they are building it for other people.
Have a say, as in providing feedback and advice - sure, and they do.
Having decisive voice, overriding the voice of people who actually
implement it, in their own free time, and then give it away for free - no.
If I use my free time to make the language worse, that is not a good thing just because I did some work for free.
You make it like it’s a gift for people to be able to vote on PHP
RFCs while I feel like it’s good for PHP to have people voting its
RFCs.There's no abstract "PHP" that it'd be good for beyond people who
actually develop it. And I don't see how it'd be good for people who
develop it to give control over how to develop it to people that don't.
I disagree here, PHP is supposed to be good to its community, not only its core developers.
One last point: Having non-core developers voting puts a higher bar
on RFC redacting quality: The author needs to explain his feature
well enough so that people without deep internal knowledge get it.I don't see how the voting process prevents people that didn't get it
from voting (either way). In a democracy, people do it all the time ;)
So this is really not a solid argument for your point.
You may always have some random or misinformed vote but I do think you will get more vote if you successfully explains how your feature improve the situation.
When I do not understand at all what it’s about I usually don’t vote (for PHP RFCs I mean).
Côme
Hi again,
Regardless of what you did, actually obtaining full voting rights
meant you had to ask for a VCS account, and have a reasonably good
explanation on why you need one - enough to convince one of the folks
with admin rights on master.php.net to click the 'Accept' button.
This is what I don't understand.
On one hand you say one needs to make a convincing enough request, so
that it may be granted by admins such as yourself. To me, that sounds
reasonable-ish (with some reserves, but certainly different to yours)
as I can't imagine that commit access to a project like PHP is handed
out left and right to anybody who wants it. But in the same breath you
also say that's a low bar.
If that's a low bar (to which I don't agree, but I also don't make
these decisions so idk), then perhaps the vetting process itself
should be revised. How can you trust your peers to grant commit
access, but not a say in how things should go forward? That's a
contradiction to me.
That's all. Immediately, one has identical rights to someone who may
have been spending years of their time on PHP, in a one way ticket.
There will always be new kids in the block and you have to accept that
if you want to attract any contributors at all.
Cheers,
Andrey.
Hi again,
Regardless of what you did, actually obtaining full voting rights
meant you had to ask for a VCS account, and have a reasonably good
explanation on why you need one - enough to convince one of the folks
with admin rights on master.php.net to click the 'Accept' button.This is what I don't understand.
On one hand you say one needs to make a convincing enough request, so
that it may be granted by admins such as yourself. To me, that sounds
reasonable-ish (with some reserves, but certainly different to yours)
as I can't imagine that commit access to a project like PHP is handed
out left and right to anybody who wants it. But in the same breath you
also say that's a low bar.
I see no contradiction between the two. The approval process for a VCS
account should absolutely not be coupled with the ability to vote. They
were never intended to be one and the same and they're not supposed to be
based on the currently-approved Voting RFC. Voting rights actually don't
play a major role in the decision on whether to grant someone a VCS account
- it's predominantly whether the one requesting it would need access to
just one of the PHP repositories (it can also be the php.net website, for
that matter).
Also, to me it does not sound reasonable or even reasonable-ish at all that
any one person - whether they're admin on master.php.net or not - would be
able to grant others with voting rights.
If that's a low bar (to which I don't agree, but I also don't make
these decisions so idk), then perhaps the vetting process itself
should be revised. How can you trust your peers to grant commit
access, but not a say in how things should go forward? That's a
contradiction to me.
It don't view it as a contradiction. VCS access is really an
administrative matter of convenience. You can grant someone access to the
VCS (which again, isn't just for php-src but for many other repositories as
well) - but in terms of what they're allowed to do with this access,
they're still subject to the rules of what they may and may not do. VCS
access in itself doesn't give anybody any special power, as all changes are
out in the open and virtually all of them are peer reviewed. If they do
something which they're not supposed to do - it will be reverted. Coupling
this administrative step with immediate implicit voting rights is not a
matter of convenience, it's a matter of substance. And it is, indeed, a
way-too-low (and arguably completely nonsensical) bar to clear.
That's all. Immediately, one has identical rights to someone who may
have been spending years of their time on PHP, in a one way ticket.
There will always be new kids in the block and you have to accept that
if you want to attract any contributors at all.
Having new kids in the block is crucial, but it does not immediately call
for having an extremely low bar for full voting rights. We shouldn't
underestimate the attractiveness of having full voting rights on one of
biggest development platforms in the world. It also goes both ways, if
it's entirely too easy to get voting rights, the value in having them
diminishes. At the same time - setting a higher bar than the
virtually-non-existent one we have right now may motivate contributors to
contribute a bit more if they want to have a say in the direction the
project takes as a whole.
Zeev
I've been doing a horrible job at explaining myself if that's what you think I'm trying to do.
As I said before, I think the difficulty has been caused by presenting
a complete set of solutions to multiple problems at once, without
agreement about what the fundamental problems are.
If you want to progress this RFC (or any RFC for that matter) breaking
the whole problem down into individual problems, and then talking
about those is usually more productive and less likely to produce
drama than just introducing a proposed solution.
I'm going to break what has been talked about in this discussion even
further, as I think we're still talking about solutions without
agreeing what the actual problems are.
- No process for giving vote to userland users.
Although that was proposed in the original voting RFC, I disagree with
this being a big problem that needs solving now. The people who are
voting are also userland users of PHP, and a lot of us use the
libraries/frameworks that would be given a vote.
Even here, the issue isn't necessarily one that would be best solved
with giving people a vote.
I think a better solution would be to make it easier for people
involved with userland libraries/frameworks to give feedback about
RFCs. Something like making a space on the RFCs form for userland
libraries to place their feedback, so that it is easily visible to all
voters, rather than being tucked away in an email thread.
I strongly doubt that if the feedback from multiple userland libraries
was "this is a terrible RFC and will cause us lots of problems", that
those opinions would be ignored.
- Who can vote needs to be tightened.
While I can agree with that, i'm not sure how big a problem it has
been. I haven't seen many votes where the margin of the decision has
been decided by less than the number of non-core developers voting.
Exactly who can vote is likely to be a big sprawling discussion that's
going to drag on for quite a while.
Although 'anyone with a php.net account' may not be ideal, it has
allowed extension maintainers, documentation writers and other people
who don't meet the 'core contributors' test, but who have otherwise
contributed to PHP to have a vote. I'm pretty sure those people should
still be covered by any new rules.*
Discussing that separately from other topics is likely to be a better
way to proceed.
- Once given, a vote stays forever, which is probably inappropriate
no matter how the vote was attained.
I think I can agree that people need to be actively contributing to
PHP to be able to continue to vote. Even if someone commits a lot of
code, but then doesn't contribute for five years, why should they
continue to be able to vote?
However that sounds like it is going to need to have a tool built to
track voters registration, which sounds like a decent chunk of work to
build and operate.
Depending on the rules chosen, we might also need an 'appeals' process
for people who either feel that some of their contributions have been
missed, or who have done major contributions that don't fall under the
exact rules.**
cheers
Dan
Ack
- Full disclaimer, I meet the suggested 'git commits to core' to
retain a vote. If I didn't and the work I have done on extensions
didn't count as a good enough contribution, I would find that very
annoying.
** For example, there is a project to move the source for the php
documentation from SVN to git, which is a non-trivial undertaking but
is hard to measure as a contribution in 'lines of code'.
Good morning Zeev&al :)
Thanks you for this RFC. I think it is long due to get a status of
where we are, what we like to have and what we can improve. My
apologize for the long reply, and as I got a mention in this reply, I
felt the need to put my grain of salt in this discussion. I hope you
don't mind.
I am not sure it makes sense to have all in one RFC however I fully
agree that the time has come to know where we are and improve things.
I am trying to explain in this reply.
Fair enough, I've heard that question from several others.
I'll use your email to clarify my motivation for the RFC, primarily on the
voting eligibility part - in slightly more detail than my reply to Nikita
on the other thread.
I think it would be better to clarify the RFC itself.
Beginning with the latter, the reality of things that the Voting RFC of
2011 was written in what was supposed to codify, and also structure a bit
more the already existing process of decision making that we had prior to
it. The structuring was mainly through the introduction of a voting
process, as well as some elements such as a mandatory discussion period.
Exactly.
The goal was also to streamline the introduction of features and
ensure a fully transparent decision can be taken. Mainly initiated by
some core developers and led by Lukas and myself to bring the 1st
version of the RFC process to life. It was cruelly required after the
6.0 fiasco and the long periods of no releases (ended by 5.3 and with
5.4 being the first release under the new rules).
However, it quickly became apparent that this RFC, that was written with a
certain 'working knowledge' of what was already happening de-facto, and
assuming these would continue - became treated as if it was the U.S.
constitution, and whatever wasn't in it - did not exist. Moreover - even
elements which were in fact in it (such as the voting eligibility), became
ignored - exclusively for the simple reason of the way the Wiki software,
used for voting, was implemented.
I think it is a bit of an extreme comparison here. However some
strictness were required to actually get things done and stop the
(benevolent or not) dictatorship which has brought the core to its
knees, divisions and a very unhealthy environment on internals. This
were a very dark moment in PHP history. We have grown and I am so
happy to see that things have changed in so many ways since then
(thanks to all devs).
Edge cases came up over the years in all sorts of manners. The most recent
edge case which isn't handled by the terse, laconic 2011 Voting RFC is the
Abolishing Narrow Margins RFC, which went straight from de-facto
hibernation into a "we're about to vote" stage overnight. But there were
many others (and yes, one of the common ones was 'how do we choose between
50%+1 and 2/3', but it was by no means the only one).
This one was supposed to be clear (I will leave to the reader to go
through the archives), ala, it was not so clear after all. The 2/3
were about everything affecting the language, the core part of it. An
extension f.e. was not thought to be part of the language. But almost
anything under /Zend, ext/standard, main/ or stream would (or
similar). Now with massive changes in how the web is developed,
something considered as a core critical feature 10 years ago is
totally useless now. We need to adapt.
What is core and what is an extension need to be clarified and I would
suggest to have a specific discussion about that. This discussion
could also include:
-
Definition of the core and what we want to include into it.
-
how we include and remove extensions
-
Do we want to always bundle all these extensions? as in. Should we
not focus on the core language and use distribution mechanisms for
anyone willing to add more exts. The extensions remaining should then
be considered as part of the core because of the critical need for PHP
as a language. Reflection, Xml, Json, reflection for example are very
good candidates. Databases extensions on the other hand make less
sense and should deserver their own releases cycles (which is
happening already anyway).
I am not sure if it makes sense to be in the same RFC. Maybe easier to
have a separate discussions about that as well. More discussions, but
smaller, clearer RFCs very crystal clear goals and expectations.
The goal here is to
provide clear cut answers to these cases, instead of leaving it up to the
RFC author to decide. Over the years, it became clear that RFC authors had
not only the ability to decide what goes into the RFC, but to also decide
much of the process surrounding the discussion and acceptance of the RFC -
filling the major voids that were present in the terse 2011 Voting RFC on
demand.In terms of Voting Eligibility, here's what was written in the original RFC:
---quote---
There's no way around this 'small' issue. Changes made to the PHP language
will affect millions of people, and theoretically, each and every one of
them should have a say in what we do. For obvious reasons, though, this
isn't a practical approach.The proposal here is for two audiences to participate in the voting process:
- People with php.net VCS accounts that have contributed code to PHP:
- Representatives from the PHP community, that will be chosen by those with
php.net VCS accounts
- Lead developers of PHP based projects (frameworks, cms, tools, etc.)
- regular participant of internals discussions
---end quote---Now, there are several things you can tell from the way this topic is
treated that are evident from this text. First, that the topic of Voting
Eligibility wasn't taken lightly, nor was there any intention to provide a
very low bar on who gets to vote.
Agreed.
Secondly, which is a lot more
unfortunate, it's very terse and laconic - like the rest of the RFC - e.g.
The RFC was not laconic but was supposed to be clarified if needed or
desired, regular updates should have been done as we learned. We fail
on the latter part.
when stating how the folks from the the 2nd group of eligible voters will
be chosen - even though it's evident that the idea was that they will be
chosen, in one way or another; Heck, even the first group is open to
interpretation from the way it's written (although the intention was clear)
Absolutely, this needs clarifications.
- code contributors to PHP - was supposed to mean folks that truly
contributed code to PHP, and not every person with a VCS account (it's
clearly a subset, even from the poor way it's written). Bear in mind that
Pierre Joye, that promoted this RFC - believed that we will be able to
figure these parts out as we go along. De-facto, what happened was very
different - overnight, because of the way the Wiki software was
implemented, anybody with a VCS account became an eligible voter, with the
same weight as Rasmus, myself, Nikita, or whomever else. This was never
the intention.
This should not have happened. Also please note that, as I would
gladly take the honor of it, I was not alone. Lukas and other (either
listed or in the background) did it.
By the way, I would greatly appreciate that we acknowledge the
benefits the RFC (and the 1st RFC about release process) gave to PHP,
even with its flaws and our failure to follow up in a timely manner.
What was the intention? In a nutshell:
- Code contributors to php-src get a vote
Indeed.
- Everyone with a VCS account (wider audience) get the ability to choose
folks that are beyond the first group, that will also get a vote (with the
assumption that the number of folks elected in this way will not be nearly
as high as the number of folks with VCS accounts, and in fact, a lot lower
than the first group of code contributors - essentially, it was to bring
outside voices, but not effectively overtake and marginalize the voice of
the code contributors). Regrettably, how that was to take place was left
out of that laconic RFC - in the belief that "we'll figure it out".
We fail to follow up, for 7 years. I will take the blame personally as well.
PS: may I suggest to remove this negativity and rough rhetoric, they
are neither actual nor bringing the discussion anywhere.
The barrier to obtaining a vote today is ridiculously low.
Agreed.
Mostly anybody
I spoke with that I shared how easy it was to get a vote that's equal to a
person that's been contributing for years and has proven knowledge about
PHP for ages - was shocked.
I have different feedback, while everyone agrees that there should be
better rules.
And indeed, our system where a person can
become an eligible voter almost overnight has no parallels (to the best of
my knowledge) in any other major OS project.
By the way, may I ask you to provide me clear examples of such voters?
The idea was to have a given person to send an introduction/request on
internals with a clear description of which group this person would
represent (for example, Symfony or Drupal). I have to say I do not
such much of these requests. Again, we fail to follow and control
that.
Take out #2:
This specific thing should be a separate RFC and we should clearly
define how, when voter(s) addition happens.
Virtually all of them are
some form of meritocracy, and yes, that's despite all of them having impact
on millions of users. The situation where an open source project effects
millions of users isn't uncommon - it's standard in virtually all major OS
projects - and yet, none of them makes it this easy to have voting rights,
literally overnight, and with 100% equivalence to folks who have
contributed for years - the way PHP de-facto does.
I agree here too.
I however disagree with the way you present it. It sounds like we need
a wall as we are submerged by thousands of illegal voters. I do not
think this is the case. We may get some data out of all RFCs, compare
to contributions activities (docs, code, tests, core, bugs, web or
systems) vs all other. I believe in data, feelings are good and
welcome but are distracting me from facts.
We were supposed to be more advanced than other projects, by providing
folks that aren't code contributors with a way to also influence votes -
and I still think it's worth exploring ways of doing it. But at no point
was the intention to lower the bar so much, providing a vote for anybody
with a VCS account (which is very, very easy to get) with a vote. This is
unfair to ones who actually take the time and effort to work on the project
itself.
To be honest, I can count with three fingers the core developers who
actually mentioned this unfairness or unwillingness to open RFC
decisions to a wider public.
Note to reader: Maybe raise your voice if you feel being treated
unfairly. We are here to move forwards. :)
Additionally, giving a vote to members of PHP-Fig is not a good idea
for multiple reasons.
I'm not sold on it being a good idea either, especially seeing the level of
controversy it stirred here (by the way - it accounts for most of the
controversy on this thread, as far as I can tell - I think that the general
idea of voting eligibility was actually supported by many folks replying to
this thread, mainly because it's common sense and is present in all other
major OS projects).
I am very neutral when it comes to FIG (or any other groups). As many
mentioned, PHP is a constellation of a lot of communities. Each of
them have their own habits. It would be very idealistic to think that
one single group could control all these communities (from a code,
norms, standatds, etc.).
I think we need to either come up with a mechanism - that's reasonably
well-defined - to bring the 'voice of the masses' into the voting process,
Yes, see my aforementioned comment about this. To make my point clear:
this should be a separate RFC with the clear and only goal to
streamline the addition of voters.
that would not be biased towards one particular group - or we simply stick
with the first group only, with the reasonable assumption that they'll
factor in what they hear from these masses during the discussion period as
they come to vote. That's mostly how all other major OS projects work.
Not really my feeling. Please bring in some data to support your feeling.
Another option might be going back to elements in the 2011 RFC (while
clearly clarifying it).
Absolutely required. However I would not do it like this RFC: Too many
topics, too many controversial points, born to fail in the endless
threads hell and ending in a rushed vote.
Perhaps, defining some sort of a voting/election
process where code-contributors can elect non-code-contributors that will
also have a vote is a way to go. What I definitely don't want to repeat,
though, is having open-ended definitions.
To close this reply, some final words/summary:
We need:
- . We need to clarify what is core, what is not core.
- how we handle extensions (addition/removal/default enabled or not)
- A clear definition of the process to add voter(s)
3.1 do we need groups represent their own project/community
3.2 Do we want only actual projects to be represented - last but not least. Life is not fair but php can be. Make php fair
again. Clearly define what is required to be seen as a PHP contributor
and have the contributor status (I mentioned my view on that in this
reply)
I am not sure in which order this should be done. However I am deeply
convinved that these topics cannot covered by one single
RFC/discussion. This is also something to be discussed with community
leaders and understand better how they actually see that (aka data).
A last note, and coming from me and for those who know me for too
long, it is kind of ironic. May I ask everyone posting here and other
threads to chill a little bit and stick to facts and propositions. It
will drastically help everyone to understand the challenges we are
facing and move towards solutions.
Best,
Pierre
@pierrejoye
Hi,
Regarding the definitions of what constitutes a Change, a Packaging
Decision and an Implementation Decision, I think it does a better job than
the current voting RFC but IMHO it still is over-complicated. Trying to
specify which changes are which just for the sake of allowing some things
to pass with a slim majority seems a wasted effort to me. As "proven" by
the currently open issues, it also misses a categorization for
administrative changes. Stating only which changes require a RFC and which
don't would be much simpler. Also, that last part about performance
degradation will also lead to unnecessary discussion if it isn't more
clearly defined (is it just the bench.php? mediawiki test suite?).
On the section about Changing the RFC, again a distinction is made between
extending the period for 1 or 2 weeks depending on what you subjectively
consider "substantial". For the sake of simplicity, I'd suggest it to be
always 1 week.
About No Discussion/Voting Periods, I think it would be simpler to just
extend the voting period to a minimum of 2 weeks. For anyone interested on
the subject, they would have 4 weeks to find out about it (2 for discussion
and 2 for voting). Maybe some people actually have more time to
contribute/participate in discussion during their holidays.
As stated before, The Eligible Voters section fails to mention its reason
to be. Lately, RFCs get around 20 to 40 votes, why do we have to reduce the
list of potential voters? To me, it seems arbitrarily hostile to newcomers
while overly protective of people that have long lost interest. In other
words, someone who has made their last contribution 10 years ago keeps
their vote while someone who fixed a bug every 2 weeks for the last year
isn't eligible. Also, the proposed measurements are subject to be "gamed"
(not squashing your commits, changes to license headers, etc..). And for
other members of the project the same problem poses, how do you measure
docs contributions? And maintaining the servers? And PECL extension
maintainers?
About FIG, it is an organization which has its own membership rules that
are subject to change at any time at its own discretion. While I truly
believe that it would be very important to provide a way to allow the users
to express their voice, doing that via an external organization doesn't
seem acceptable. Keep in mind that the current voting RFC keeps the
decision of which community members can vote in PHP's side.
To cater to an even larger audience, there could be a section on RFCs where
anyone could cast their vote so that the RFC author can also take it into
consideration but keeping it non-binding. (Or perhaps giving it a
predefined weight - 1, 3, 5 votes?)
Regards,
Pedro
Without further ado, an RFC that’s attempting to comprehensively solve
many of the issues that have plagued our RFC process since it was hastily
introduced in 2011:https://wiki.php.net/rfc/voting2019
Emphasis on ‘attempting’. I’m sure there are still a lot of holes in it
that should be plugged before we vote on it, but instead of waiting
indefinitely – I’d like us to start discussing it.Comments and suggestions welcome.
Zeev
Hi!
Reading the RFC, here's my thoughts:
-
Do we really need different classification of changes? I think having
one single vote procedure would have larger benefit, and RFC that fails
2/3 requirement would be suspect anyway. RFCs can have parts - "whether
we do it" and "how exactly we do it" - the former would be 2/3
requirement, the latter can be simple plurality even - e.g. if we decide
to have an extension for libfoobar, that should have 2/3 vote, but then
decision between whether to name it foobar or barfoo can be decided by
majority or plurality. -
The RFC deals simultaneously with two questions - whether vote is
needed for certain changes and how the voting process is performed. I am
not sure these issues should be handled together - they are
substantially different. -
Requiring patch for each RFC is kinda high bar - if I propose some
functionality, I don't really want to spend months on implementing it
only to see it voted down and my time completely wasted. -
I am feeling a bit uneasy about any change requiring a week's waiting
period - read literally, that means you'd better not fix typos in your
RFC if you don't want for it to take forever, and certainly not address
feedback like "X is not documented enough" or "Y description could be
clearer". I do think substantial changes require discussion and in some
cases even full re-launch of the RFC but requiring a week's wait for any
change, even the trivial one, seems going to far to me. -
The RFC changes [VOTE] subject that we've used before to [RFC VOTE].
I know it's a nitpick but is that change necessary? If people had
filters to match such things, the change would break them and I'm not
sure it improves anything. -
I think we should allow longer voting periods than 1 week. In fact,
I'd go as far as recommend longer minimum even, but even if we keep
minimum of 1 week, there would be cases - holidays, conferences, sports
events ;) - where a lot of people could be offline for prolonged time
and 1 week won't be nearly enough. -
For the sake of clarity, we should define what 2/3 threshold means -
is it:
a) $voted_yes >= 2 * $voters / 3
b) $voted_yes > 2 * $voters / 3
c) $voted_yes >= floor(2 * $voters / 3) + 1
d) something else? -
6 months seems a bit too long for rejected RFC. I'd probably shorten
it to something like 2 months, maybe even less. But include the language
that the feedback provided on the previous discussion stage should be
addressed (of course we can't control it, but we can establish the norm). -
I'm not sure I understand the purpose of "RFCs that targeted the next
mini version, and are moved back to the Discussion Stage after a
Hibernation Period, may not target that same mini version" - why not? -
I like the idea of no discussion during vacation time - though,
frankly, I've been using some vacation days to catch up with Internals
in the past... -
5 people to object to restart vote looks relatively high, and in
fact the procedure looks rather complicated... Is it a frequent
occurrence that needs special mention? -
I think we need more work on eligibility criteria. Specifically, I
think we should aim for:
a) including everybody who made contribution to PHP project in the past,
if their contribution are recent or they plan to keep contributing
(simple public declaration of intent should be enough). I am not sure
yet if we need minimal conribution size - depends on whether it actually
changes anything or not (should we make some tools that allow us to see
what changes with and without minima?). I think the process should be
biased to the side of inclusion - one more voter wouldn't hurt, but one
person unjustly excluded from voting would feel very bad and it may lead
to bitter discussions that don't help anything.
b) including important non-code contributors
c) having the mechanism to periodically remove participants that have
left the project and have no intent to contribute anymore, and to
restore their voting eligibility if they come back
d) as I said before, I certainly do not feel comfortable with including
all 50-strong PHP-FIG membership, and all future members, given that we
have no say about how they are selected. We may want to think about
mechanism to include their feedback somehow but current proposal seems
to broad. -
Quorum question would be an interesting one to tackle. Some votes
are being decided by very low number of votes, however I am not sure
whether or not it's a problem...
Probably will have more, but it's long enough for now :)
Also, I realize the above has a bit of a negative tint because I have
mostly addressed things that I disagree with or think may be improved,
so I want to explicitly state that I think it's great we are discussing
these things, and explicitly thank Zeev for working on it.
Stas Malyshev
smalyshev@gmail.com
On Mon, Feb 4, 2019 at 10:56 AM Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
Reading the RFC, here's my thoughts:
Thanks for the detailed response!
- Do we really need different classification of changes? I think having
one single vote procedure would have larger benefit, and RFC that fails
2/3 requirement would be suspect anyway. RFCs can have parts - "whether
we do it" and "how exactly we do it" - the former would be 2/3
requirement, the latter can be simple plurality even - e.g. if we decide
to have an extension for libfoobar, that should have 2/3 vote, but then
decision between whether to name it foobar or barfoo can be decided by
majority or plurality.
I think we do. There are decisions where a 2/3 majority requirement makes
no sense, as the vote itself is about a choice between two options that are
on the table, as opposed to deciding whether to do something or not.
There aren't many such cases, but when they do occur - they tend to be
important.
The most obvious case I have in mind is that of the choice between PHP 6
and 7. It doesn't expose us to any future commitments, doesn't change the
language - it's arguably almost a marketing decision. Similarly, if we
decide to change our release schedule, I don't see why that should require
a 2/3 majority. The 'bias for the status quo', which is the main reason we
have the super majority requirement to begin with, doesn't really play a
role here - as it bears no long term commitment.
- The RFC deals simultaneously with two questions - whether vote is
needed for certain changes and how the voting process is performed. I am
not sure these issues should be handled together - they are
substantially different.
Yes, that's something I intend to look into.
- Requiring patch for each RFC is kinda high bar - if I propose some
functionality, I don't really want to spend months on implementing it
only to see it voted down and my time completely wasted.
This new workflow does not require an RFC for each patch. It does require
an RFC for functionality that affects end users.
You do have a point regarding a scenario where you invest time into a patch
that then it ends up being rejected. However, I think there are several
things to consider here:
- De-facto, most large RFCs actually come with an accompanied
implementation even today. - In certain cases, the feasibility of implementation - and the ability to
do it in a reasonable, high performance way - are substantial parts of the
decision on whether to accept the RFC or not. - Usually, it's possible to gauge the level of interest/acceptance even
before beginning work on the patch and/or working on the RFC. This
workflow does not intend to replace all of the discussions on internals or
other avenues, and it may make sense to explicitly suggest in the workflow
to informally discuss the proposal with fellow contributors before
investing heavily in the implementation or RFC. - Perhaps most importantly, I think it's very difficult to create a simple,
repeatable criteria to determine which end-user-affecting change requires
an RFC and which one doesn't. Still, perhaps we can employ something like
Larry's approach - i.e., some sort of a "pre-RFC" stage where the author
asks for an 'exemption' from the full process for a small patch, and they'd
get it as long as there are no eligible voters opposing (say, 3 of them, or
whatnot).
- I am feeling a bit uneasy about any change requiring a week's waiting
period - read literally, that means you'd better not fix typos in your
RFC if you don't want for it to take forever, and certainly not address
feedback like "X is not documented enough" or "Y description could be
clearer". I do think substantial changes require discussion and in some
cases even full re-launch of the RFC but requiring a week's wait for any
change, even the trivial one, seems going to far to me.
Again, here too drawing the line is difficult. Typos are easy (although
certain types of typos can be quite strategic), but sometimes things like
further documentation may result in different levels of support for the
RFC. That's why I like Larry's approach and would try to build it into the
workflow - small changes will be permitted to the RFC without resetting the
clock, but that's provided there's consensus that they're indeed small
(e.g.., fewer than 3 eligible voters object).
- The RFC changes [VOTE] subject that we've used before to [RFC VOTE].
I know it's a nitpick but is that change necessary? If people had
filters to match such things, the change would break them and I'm not
sure it improves anything.
Agreed, fixed.
- I think we should allow longer voting periods than 1 week. In fact,
I'd go as far as recommend longer minimum even, but even if we keep
minimum of 1 week, there would be cases - holidays, conferences, sports
events ;) - where a lot of people could be offline for prolonged time
and 1 week won't be nearly enough.
I'm fine with going for a longer period of two weeks instead of one.
You're right that conferences and holidays may make a one week voting
period too short.
- For the sake of clarity, we should define what 2/3 threshold means -
is it:
a) $voted_yes >= 2 * $voters / 3
b) $voted_yes > 2 * $voters / 3
c) $voted_yes >= floor(2 * $voters / 3) + 1
d) something else?
Agreed. I think that it should simply be $voted_yes >= 2 * $voted_no (or
in words, at least twice as many people voted yes vs. voted no).
- 6 months seems a bit too long for rejected RFC. I'd probably shorten
it to something like 2 months, maybe even less. But include the language
that the feedback provided on the previous discussion stage should be
addressed (of course we can't control it, but we can establish the norm).
I'm not sure about that one. Perhaps we can set a certain bar (say, 60%
yes votes) above which - you're entitled to put the RFC back into a vote
sooner than 6 months. But I very much want to avoid situations where the
workflow is left to the arbitrary decision of the author.
Another approach would be shortening that period, perhaps to two months,
but if it fails again - the 'hibernation' period would be longer (say
1yr). I actually like that approach better. Thoughts?
- I'm not sure I understand the purpose of "RFCs that targeted the next
mini version, and are moved back to the Discussion Stage after a
Hibernation Period, may not target that same mini version" - why not?
Not sure I agree with my 2017 self either on this one. Should probably be
removed (and would be moot if we go for the different 2 months / 1 year
approach).
- 5 people to object to restart vote looks relatively high, and in
fact the procedure looks rather complicated... Is it a frequent
occurrence that needs special mention?
I don't think it's common, but it's important when it happens. Here too,
I'm trying to codify things as opposed to just leaving them to the
arbitrary decision of the RFC author.
I'm not sure I understand your feedback regarding 5 people being too high.
Are you saying it should be enough for fewer people to object to a vote
restart for this to be denied? Employing the approach of "whenever there's
doubt, there's no doubt", then perhaps even 3 people should be sufficient,
especially if we allow the RFC to be discussed once again after two months.
- I think we need more work on eligibility criteria.
I agree.
Specifically, I
think we should aim for:
a) including everybody who made contribution to PHP project in the past,
if their contribution are recent or they plan to keep contributing
(simple public declaration of intent should be enough). I am not sure
yet if we need minimal conribution size - depends on whether it actually
changes anything or not (should we make some tools that allow us to see
what changes with and without minima?). I think the process should be
biased to the side of inclusion - one more voter wouldn't hurt, but one
person unjustly excluded from voting would feel very bad and it may lead
to bitter discussions that don't help anything.
The devil is in the details. The problem (that you acknowledge yourself)
is that we still need to set a bar regarding what constitutes contribution
to PHP. First, are we talking about php-src? I'd say yes. Does a single
line of code qualify? I'd say no. Do two? We need to set a certain
threshold, even though it will be arbitrary to a degree.
I do think that the current criteria is biased to the side of inclusion, as
it includes folks with huge variance in their levels of contribution. At
the same time, we need to realize we're not talking about "one more voter",
but potentially dozens and even hundreds, depending on how we set the
criteria.
b) including important non-code contributors
This is tough, as I don't think we'll be able to come up with metrics. As
I've mentioned elsewhere, I currently see two options here:
- Rely on the non-code-contributors participating in internals, and having
their opinions ultimately represented by code-contributors - Have some sort of a process where the code-contributors elect a certain
number of non-code-contributors - coming up with a mechanism that we can
both agree on and can implement effectively will likely be mind boggling,
though
c) having the mechanism to periodically remove participants that have
left the project and have no intent to contribute anymore, and to
restore their voting eligibility if they come back
I think one way to do it would be disabling the right to vote for those who
haven't voted in the last 12 or 24 months. It can then be reinstated
on-demand, but with a 'cool-off' period of 3 months - to ensure that folks
don't just periodically come to vote on specific RFCs when 'summoned' on
demand by their friends. This will also serve to encourage people to vote,
if they want to keep their voting rights.
d) as I said before, I certainly do not feel comfortable with including
all 50-strong PHP-FIG membership, and all future members, given that we
have no say about how they are selected. We may want to think about
mechanism to include their feedback somehow but current proposal seems
to broad.
I'm going to remove FIG from the proposal for now, and replace it with a
question mark regarding a mechanism to include non-code-contributors.
- Quorum question would be an interesting one to tackle. Some votes
are being decided by very low number of votes, however I am not sure
whether or not it's a problem...
Same here, I'm undecided on this.
Thanks again for the detailed and high quality feedback!
Zeev
Hello and thanks for the RFC.
I think the Eligible Voters Section is too complex to be
addressed/bundled in this RFC. I think it deserves another RFC.
Most discussions here are rightfully about this section. To add my opinion:
- I don't understand the special treatment for PHP-FIG. This group
first intent was to reflect the “major implementors point of view”
in order to make common agreements/standards about some practises.
Based on that, yes it makes sense to include PHP-FIG into the
Eligible Voters group. However, some projects have decided to step
away from PHP-FIG for various reasons I won't list here (I can
mention sabre.io or hoa-project.net because I was/am involved in
those projects). Thus, they are excluding themselves from the
Eligible Voters group? It doesn't make sense, and it does not sound
very democratic :-). - Some people don't contribute to the php-src repository (like
myself), but create extensions, participate to the ecosystem, or
push PHP further. As an example not related to myself, I think of
PHPStan or Doctrine, both projects are important PHP projects, with
an extreme usage of PHP features as a language, and their authors
are in a good position to give feedbacks on PHP RFC, or to write
ones. The metrics that are currently listed in the RFC to be an
Eligible Voter entirely exclude this population. If this population
is excluded, I'm afraid that the PHP future will defer from the real
usages/expectations of the language. - I don't understand why keeping existing voters is an issue, it's not
motivated, and consequently I can only disagree with the
grandfathering section.
The rest of the RFC is very interesting. It would be sad to miss it
because of the Eligible Voters Section. I suggest to split it into 2 RFC.
Regards.
Without further ado, an RFC that’s attempting to comprehensively solve many of the issues that have plagued our RFC process since it was hastily introduced in 2011:
https://wiki.php.net/rfc/voting2019
Emphasis on ‘attempting’. I’m sure there are still a lot of holes in it that should be plugged before we vote on it, but instead of waiting indefinitely – I’d like us to start discussing it.
Comments and suggestions welcome.
Zeev