Hi!
Perhaps I’m being unfair and overthinking things, but I wonder if it is really fair for people who have no karma, i.e. not contributors to the documentation, extensions, php-src or anything else, to have the ability to vote on RFCs?
I’d never suggest people without internals karma can’t vote. I think doc and peck contributors are as valued as any other contributors. However, people with no karma whatsoever (a blank people.php.net page) voting irks me.
Thoughts?
Andrea Faulds
http://ajf.me/
Hi!
Perhaps I’m being unfair and overthinking things, but I wonder if it is really fair for people who have no karma, i.e. not contributors to the documentation, extensions, php-src or anything else, to have the ability to vote on RFCs?
I’d never suggest people without internals karma can’t vote. I think doc and peck contributors are as valued as any other contributors. However, people with no karma whatsoever (a blank people.php.net page) voting irks me.
Thoughts?
Andrea Faulds
http://ajf.me/
Hey Andrea,
I think you know my personal opinion here. I want the people who are
in a position to control the state of the language to be people who
actively contribute to the language.
Anyone who actively works towards a better PHP (regardless of whether
their proposals are accepted or rejected) should be able to have an
opinion on what is accepted or not.
People who contribute one translation a year, a bug report once, a
pecl extension 10 years ago and nothing since then,... I don't
understand why these people get to vote on the future of the language
that the rest of us "investors" use every day.
I think everyone with the ability to vote should have to communicate
their reasons behind their yes/no publicly on this mailing list for it
to be valid. If you cannot describe in your own words why a proposal
should or should not be accepted, why should your opinion be valid?
Interest in the language should be recent and relevant. It's difficult
to police "legacy contributors", but if they are not interested enough
to type a few lines..... the answer is clear.
Say no to non-contributors.
Cheers,
Leigh.
I think everyone with the ability to vote should have to communicate
their reasons behind their yes/no publicly on this mailing list for it
to be valid. If you cannot describe in your own words why a proposal
should or should not be accepted, why should your opinion be valid?
That's one of the reasons why I consider voting as default way wrong. It
might be a way to solve ties if a consensus can't be reached.
It is unclear what a "no" means. Might be a related to the patch the
design, a misunderstanding or due to a critical issue ... in the end a
vote creates "losers" with little feedback.
But well, I'm saying this from day one of the voting.
johannes
It is unclear what a "no" means. Might be a related to the patch the
design, a misunderstanding or due to a critical issue ... in the end a
vote creates "losers" with little feedback.But well, I'm saying this from day one of the voting.
johannes
This is my opinion exactly
Some people who vote no are involved in the internals discussion, and
that's great. But some people vote no without a word. How do we know
they even understand the impact of their vote? Without their feedback
how can the proposal be improved?
Even if they say "I'm voting no because of all of the reasons stated
by Person X", that's enough to know that more than one person doesn't
like a specific aspect, and makes it a higher priority for
improvement.
On 20 September 2014 15:37, Johannes Schlüter johannes@schlueters.de
wrote:It is unclear what a "no" means. Might be a related to the patch the
design, a misunderstanding or due to a critical issue ... in the end a
vote creates "losers" with little feedback.But well, I'm saying this from day one of the voting.
johannes
This is my opinion exactly
Some people who vote no are involved in the internals discussion, and
that's great. But some people vote no without a word. How do we know
they even understand the impact of their vote? Without their feedback
how can the proposal be improved?Even if they say "I'm voting no because of all of the reasons stated
by Person X", that's enough to know that more than one person doesn't
like a specific aspect, and makes it a higher priority for
improvement.
This is exactly the case for the “Yes” voters too. I’d be for having some
avenue (um... internals, or… is that the perfect place?) for giving two
cents [voluntarily] about a voter’s decision or indeed lack thereof.
Ideally, the atmosphere would be open and inviting (the latter appears to
be a problem here) where a pitchfork-weilding mob won’t descend on anyone
who happened to make a vote, one way or the other.
In the past we’ve had people editing wiki articles (not RFCs) with their
own thoughts as attributed annotations. This has obvious issues, but it
would be a) in writing, and b) directly associated with the RFC, and c)
not a conversation.
I think everyone with the ability to vote should have to communicate
their reasons behind their yes/no publicly on this mailing list for
it to be valid. If you cannot describe in your own words why a
proposal should or should not be accepted, why should your opinion
be valid?That's one of the reasons why I consider voting as default way wrong.
It might be a way to solve ties if a consensus can't be reached.
That's another good point, that I stand behind. I think f.e. the integer
semantics RFC was contentious enough to warrant further discussion and
see what could make other people to say "yes" as well. The current RFC
process does not state anything about reflecting comments on the ML to
have to be addressed before the RFC can even be put to vote. And I
think, valid (technical) objects should be required to be addressed.
It is unclear what a "no" means. Might be a related to the patch the
design, a misunderstanding or due to a critical issue ... in the end
a vote creates "losers" with little feedback.But well, I'm saying this from day one of the voting.
Yes. I am in that camp too.
cheers,
Derick
2014-09-20 3:29 GMT+02:00 Andrea Faulds ajf@ajf.me:
Hi!
Perhaps I’m being unfair and overthinking things, but I wonder if it is really fair for people who have no karma, i.e. not contributors to the documentation, extensions, php-src or anything else, to have the ability to vote on RFCs?
I’d never suggest people without internals karma can’t vote. I think doc and peck contributors are as valued as any other contributors. However, people with no karma whatsoever (a blank people.php.net page) voting irks me.
Thoughts?
I'm with you on this one, huge +1 for the separation on who can vote
and changing the voting rfc.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
2014-09-20 3:29 GMT+02:00 Andrea Faulds ajf@ajf.me:
Hi!
Perhaps I’m being unfair and overthinking things, but I wonder if it is
really fair for people who have no karma, i.e. not contributors to the
documentation, extensions, php-src or anything else, to have the ability to
vote on RFCs?I’d never suggest people without internals karma can’t vote. I think doc
and peck contributors are as valued as any other contributors. However,
people with no karma whatsoever (a blank people.php.net page) voting irks
me.Thoughts?
I'm with you on this one, huge +1 for the separation on who can vote
and changing the voting rfc.--
regards,Kalle Sommer Nielsen
kalle@php.net--
The one problem with this is it doesn't take into account those who
contribute to PHP in other ways, such as administering tests, contributing
RFCs, etc. I'm not necessarily against this, but if you want to garner
wide enough support, you might want to make the language a little more
inclusive.
Just my two cents.
--Kris
Hi Kris
2014-09-20 4:32 GMT+02:00 Kris Craig kris.craig@gmail.com:
The one problem with this is it doesn't take into account those who
contribute to PHP in other ways, such as administering tests, contributing
RFCs, etc. I'm not necessarily against this, but if you want to garner wide
enough support, you might want to make the language a little more inclusive.
Those who is an active contributor of the project should have the
voting rights, take Dan Brown, who does not contribute to php-src, but
is one of the main guys, if not THE guy behind the mirrors
communication and network infrastructure. People like that who is a
contributor should ofcourse be allowed, but people who despite they
"represent" a project written in PHP and does not take a part of the
actual development of PHP or maintenance of PHP.net and related
services, e.g. framework authors should not imo.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
2014-09-20 3:29 GMT+02:00 Andrea Faulds ajf@ajf.me:
Hi!
Perhaps I’m being unfair and overthinking things, but I wonder if it is
really fair for people who have no karma, i.e. not contributors to the
documentation, extensions, php-src or anything else, to have the ability to
vote on RFCs?I’d never suggest people without internals karma can’t vote. I think doc
and peck contributors are as valued as any other contributors. However,
people with no karma whatsoever (a blank people.php.net page) voting irks
me.Thoughts?
I'm with you on this one, huge +1 for the separation on who can vote
and changing the voting rfc.--
regards,Kalle Sommer Nielsen
kalle@php.net--
The one problem with this is it doesn't take into account those who
contribute to PHP in other ways, such as administering tests, contributing
RFCs, etc. I'm not necessarily against this, but if you want to garner
wide enough support, you might want to make the language a little more
inclusive.Just my two cents.
--Kris
I would also argue that contributions are not always a measure of the value of a person’s opinion. I haven’t made what would be considered “significant” contributions to PHP itself in a few years now, but I remain a very active user of the language, and I keep an eye on where it’s going.
When I vote on language features, I’m casting that vote as someone who 1) has a clear set of reasons in mind for why a feature would or wouldn’t be useful, and 2) is always looking for a reason to be able to devote my time again. I agree that voting should be kept out of the hands of people who’ve never made any effort to show they give a darn about the language and its future. But I would say, be careful about equating “small" contributions with “unimportant”, “uninteresting”, or “nonexistent" ones.
As Kris pointed out, the ways in which someone contributes aren’t always obvious. Leigh speaks of people who contribute “one translation a year” - that’s still more than many ever have done or ever will do. There are many who simply don’t have the time to take away from their lives to do more, but remain invested in the language and its community.
That being said, I am absolutely in favor of excluding people who don’t make at least some effort. I’m strongly +1 for people explaining their reasons for a vote, or even doing so much as saying “I’d prefer not to explain my reasons”. I’m even more strongly +1 for people having to at least shown some level of interest before being allowed to influence PHP’s future. I would just like to be sure that the bar is not set so high that it excludes opinions from people whose only failing is not being seen by the community.
Full disclosure: This is absolutely a self-serving opinion. All of my significant contributions are years old (dating back to 5.3), I’ve been all but invisible in the internals community since, and I am certainly someone who has limited time to spend on contributing to the language. But I like to think my thoughts are still worth something. If the requirement for that is that I explain why I voted how I did on an RFC, I’m glad - even eager - to do so. If the requirement for that is that I contribute at least one nontrivial documentation edit or source code commit per month, or something similar, I think the point has been missed.
-- Gwynne Raskind
Hi,
Hi!
Perhaps I’m being unfair and overthinking things, but I wonder if it is
really fair for people who have no karma, i.e. not contributors to the
documentation, extensions, php-src or anything else, to have the ability to
vote on RFCs?I’d never suggest people without internals karma can’t vote. I think doc
and peck contributors are as valued as any other contributors. However,
people with no karma whatsoever (a blank people.php.net page) voting irks
me.Thoughts?
I am not sure what brings you here but the idea of community votes was one
of the top thing when we introduced the voting RFC.
Thinking that we do not care what symfony, composer, zend framework,
lavahel (if they like to), drupal lead developers think about what we plan
to do then we will go back to a very dark time.
We may improve how it is done. But killing communities voices is a very bad
idea.
It is also important to keep in mind the RFCs, blocking ppl were not them.
Or ppl having strong opinions for one way or another, me or other, were not
part of these communities voices. So I do not think the impact of their
votes is that large anyway.
Cheers,
Pierre
I am not sure what brings you here but the idea of community votes was one
of the top thing when we introduced the voting RFC.
I should've made clear I'm not opposed to community reps voting either. People who have made enough contributions to earn either karma or community rep status should be allowed to vote. My problem is people with neither.
Andrea Faulds
http://ajf.me/
I am not sure what brings you here but the idea of community votes was
one
of the top thing when we introduced the voting RFC.I should've made clear I'm not opposed to community reps voting either.
People who have made enough contributions to earn either karma or community
rep status should be allowed to vote. My problem is people with neither.
For example?
2014.09.20. 14:14 ezt írta ("Pierre Joye" pierre.php@gmail.com):
I am not sure what brings you here but the idea of community votes was
one
of the top thing when we introduced the voting RFC.I should've made clear I'm not opposed to community reps voting either.
People who have made enough contributions to earn either karma or
community
rep status should be allowed to vote. My problem is people with neither.For example?
I personally have seen a couple of cases where we (mostly Rasmus) approves
outstanding php.net accounts but there are no follow up, so for example the
proposed pecl package is not created nor any karma is granted.
For the record: currently it is possible for a pecl ext developer to not
have php.net account (pecl.php.net has its own user db and some exts aren't
hosted on our svn/git infrastructure) which means that they won't have
voting karma by default.
I think it would make sense to review and cross-check the accounts and
maybe remove those which were never used.
We also have to keep in mind, that there could be users without any karma,
but other contributions like sorting out bugs or event/notes moderation,
etc.
Afair the voting rfc required previous contribution not just an existing
php.net account, but as I mentioned there are a bunch of ways to contribute
other than having commits in one of the repos so there is no easy way to
check that programatically.
Ps: sorry for the typos, sending from my phone.
Afair the voting rfc required previous contribution not just an existing
php.net account, but as I mentioned there are a bunch of ways to contribute
other than having commits in one of the repos so there is no easy way to
check that programatically.Ps: sorry for the typos, sending from my phone.
Perhaps we could make the system only allow people with karma to vote, but add an additional flag we can set on karmaless accounts to say they can vote, for the limited number of accounts for which this is necessary? I think this could work.
--
Andrea Faulds
http://ajf.me/
Perhaps I’m being unfair and overthinking things,
Yes, you are.
but I wonder if it is really fair for people who have no karma, i.e. not contributors to the documentation, extensions, php-src or anything else, to have the ability to vote on RFCs?
Yes, it is.
-Sara
Perhaps I’m being unfair and overthinking things,
Yes, you are.but I wonder if it is really fair for people who have no karma, i.e. not contributors to the documentation, extensions, php-src or anything else, to have the ability to vote on RFCs?
Yes, it is.-Sara
Yes, What Sara said. I am the type of person that would be excluded. I
contributed to PHP a lot 10 years ago. However, in all the SVN and GIT
moving, all my karma has long since been removed. I vote in almost every
RFC because I have a long history with PHP and care about where it is
going. People with dead accounts and who don't care about PHP most
likely don't vote.
Brian Moon
brianlmoon@php.net
Perhaps I’m being unfair and overthinking things, but I wonder if it
is really fair for people who have no karma, i.e. not contributors to
the documentation, extensions, php-src or anything else, to have the
ability to vote on RFCs?I’d never suggest people without internals karma can’t vote. I think
doc and peck contributors are as valued as any other contributors.
However, people with no karma whatsoever (a blank people.php.net page)
voting irks me.
I think people's votes should only count if they have karma to the
section of the code that the RFC/feature/whatever relates to.
cheers,
Derick
Perhaps I’m being unfair and overthinking things, but I wonder if it
is really fair for people who have no karma, i.e. not contributors to
the documentation, extensions, php-src or anything else, to have the
ability to vote on RFCs?I’d never suggest people without internals karma can’t vote. I think
doc and peck contributors are as valued as any other contributors.
However, people with no karma whatsoever (a blank people.php.net page)
voting irks me.I think people's votes should only count if they have karma to the
section of the code that the RFC/feature/whatever relates to.
Is that really fair? If we break BC, plenty of userland developers might be affected and they should have a right to chime in.
Andrea Faulds
http://ajf.me/
Perhaps I’m being unfair and overthinking things, but I wonder if it
is really fair for people who have no karma, i.e. not contributors to
the documentation, extensions, php-src or anything else, to have the
ability to vote on RFCs?I’d never suggest people without internals karma can’t vote. I think
doc and peck contributors are as valued as any other contributors.
However, people with no karma whatsoever (a blank people.php.net page)
voting irks me.I think people's votes should only count if they have karma to the
section of the code that the RFC/feature/whatever relates to.Is that really fair? If we break BC, plenty of userland developers might be affected and they should have a right to chime in.
That would be quite unfair, not just because of BC breaks and/or
userland developers' votes (there aren't many, afaik).
Practically every language change would be decided by only a handful
of people, while it should be important that many votes are gathered
for important decisions.
Cheers,
Andrey.
Perhaps I’m being unfair and overthinking things, but I wonder if
it is really fair for people who have no karma, i.e. not
contributors to the documentation, extensions, php-src or anything
else, to have the ability to vote on RFCs?I’d never suggest people without internals karma can’t vote. I
think doc and peck contributors are as valued as any other
contributors. However, people with no karma whatsoever (a blank
people.php.net page) voting irks me.I think people's votes should only count if they have karma to the
section of the code that the RFC/feature/whatever relates to.Is that really fair? If we break BC, plenty of userland developers
might be affected and they should have a right to chime in.That would be quite unfair, not just because of BC breaks and/or
userland developers' votes (there aren't many, afaik).
Practically every language change would be decided by only a handful
of people, while it should be important that many votes are gathered
for important decisions.
There is a big difference between votes, and voices. Voices should
definitely be listened too.
Derick
Perhaps I’m being unfair and overthinking things, but I wonder if
it is really fair for people who have no karma, i.e. not
contributors to the documentation, extensions, php-src or anything
else, to have the ability to vote on RFCs?I’d never suggest people without internals karma can’t vote. I
think doc and peck contributors are as valued as any other
contributors. However, people with no karma whatsoever (a blank
people.php.net page) voting irks me.I think people's votes should only count if they have karma to the
section of the code that the RFC/feature/whatever relates to.Is that really fair? If we break BC, plenty of userland developers
might be affected and they should have a right to chime in.That would be quite unfair, not just because of BC breaks and/or
userland developers' votes (there aren't many, afaik).
Practically every language change would be decided by only a handful
of people, while it should be important that many votes are gathered
for important decisions.There is a big difference between votes, and voices. Voices should
definitely be listened too.
We agree on listening. Only not on how we listen.
Derick
IMHO, denying non-karma people to vote is like to making PHP a company's
product, or, in another words, "you use what we built and shut up", because
only listening people won't allow to accept/deny a particular RFC, only
votes do. People surely don't comment (myself included) why they are
choosing some particular option on a RFC, but they are making their opinion
count, and I think this kind of "democracy power" shouldn't be voided.
Using separated voting count isn't an option? Like only internal changes
are voted only by people with karma and features/changes/small BC breaks
that affects userland are allowed to anyone. This way I believe is easy to
say if either internals and community agrees with the proposed change and
community people are making their opinion count.
Perhaps I’m being unfair and overthinking things, but I wonder if
it is really fair for people who have no karma, i.e. not
contributors to the documentation, extensions, php-src or anything
else, to have the ability to vote on RFCs?I’d never suggest people without internals karma can’t vote. I
think doc and peck contributors are as valued as any other
contributors. However, people with no karma whatsoever (a blank
people.php.net page) voting irks me.I think people's votes should only count if they have karma to the
section of the code that the RFC/feature/whatever relates to.Is that really fair? If we break BC, plenty of userland developers
might be affected and they should have a right to chime in.That would be quite unfair, not just because of BC breaks and/or
userland developers' votes (there aren't many, afaik).
Practically every language change would be decided by only a handful
of people, while it should be important that many votes are gathered
for important decisions.There is a big difference between votes, and voices. Voices should
definitely be listened too.We agree on listening. Only not on how we listen.
Derick
IMHO, denying non-karma people to vote is like to making PHP a
company's
product, or, in another words, "you use what we built and shut up",
because
only listening people won't allow to accept/deny a particular RFC, only
votes do. People surely don't comment (myself included) why they are
choosing some particular option on a RFC, but they are making their
opinion
count, and I think this kind of "democracy power" shouldn't be voided.
Slightly provocative: Why should I be forced to maintain code by people who
don't want to maintain it themselves? Probably even due to votes by people
about whom I don't know anything? Mind that most maintenance work by
most contributors happens in free time on a voluntarily base.
And no open source doesn't mean democracy as governing model. The
democratic part is that people who don't like it can fork the project and
eventually receive a higher traction. But no, "one man one vote" and full
equality doesn't work out. (i.e. if a modules primary maintainer vetos a
change I have to mind that [which doesn't mean I have to agree in the
end])
Using separated voting count isn't an option? Like only internal
changes
are voted only by people with karma and features/changes/small BC
breaks
that affects userland are allowed to anyone. This way I believe is easy
to
say if either internals and community agrees with the proposed change
and
community people are making their opinion count.
There are no plans (and enough people who'd veto such plans) to close
the mailing list. Everybody might state their opinion and we are happy to
receive (constructive) feedback and ideas here. And yes, this can be a bit
painful due to different forms of "trolling" but leads to better results respecting
more opinions than a yes/no vote.
johannes
On Mon, Sep 22, 2014 at 5:38 PM, Johannes Schlüter
johannes@schlueters.de wrote:
Slightly provocative: Why should I be forced to maintain code by people who
don't want to maintain it themselves? Probably even due to votes by people
about whom I don't know anything? Mind that most maintenance work by
most contributors happens in free time on a voluntarily base.
The same applies to many new codes. Even more for my team as we have
to take care of many issues where only a few actually takes care of.
And no open source doesn't mean democracy as governing model. The
democratic part is that people who don't like it can fork the project and
eventually receive a higher traction. But no, "one man one vote" and full
equality doesn't work out. (i.e. if a modules primary maintainer vetos a
change I have to mind that [which doesn't mean I have to agree in the
end])
Primary maintainers doing only maintenance but not having actually
designed/implemented an extension fits in this description. That
sounds pretty awkward to me, for anything landing in the core. Landed
in the core? Dictartorship goes away.
Using separated voting count isn't an option? Like only internal
changes
are voted only by people with karma and features/changes/small BC
breaks
that affects userland are allowed to anyone. This way I believe is easy
to
say if either internals and community agrees with the proposed change
and
community people are making their opinion count.There are no plans (and enough people who'd veto such plans) to close
the mailing list. Everybody might state their opinion and we are happy to
receive (constructive) feedback and ideas here. And yes, this can be a bit
painful due to different forms of "trolling" but leads to better results respecting
more opinions than a yes/no vote.
Never worked before and it will suddenly work? I am open to know how
one can make it works. Unless you mean to go back to individual
deciding everything for a given area or ext.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
On September 22, 2014 4:21:29 PM CEST, Rafael Kassner kassner@php.net
wrote:IMHO, denying non-karma people to vote is like to making PHP a
company's
product, or, in another words, "you use what we built and shut up",
because
only listening people won't allow to accept/deny a particular RFC, only
votes do. People surely don't comment (myself included) why they are
choosing some particular option on a RFC, but they are making their
opinion
count, and I think this kind of "democracy power" shouldn't be voided.Slightly provocative: Why should I be forced to maintain code by people
who
don't want to maintain it themselves?
Nobody is forcing you to do anything. You choose to contribute to PHP in
the manner in which you do, just as other people choose to contribute in
different, sometimes less obvious, ways.
Probably even due to votes by people
about whom I don't know anything? Mind that most maintenance work by
most contributors happens in free time on a voluntarily base.And no open source doesn't mean democracy as governing model.
It can. Every project is governed differently.
Winston Churchill once famously said that democracy is the worst form of
government, except all the others that have been tried.
The
democratic part is that people who don't like it can fork the project and
eventually receive a higher traction.
And then we can have dozens of competing PHP codebases floating around.
But no, "one man one vote" and full
equality doesn't work out. (i.e. if a modules primary maintainer vetos a
change I have to mind that [which doesn't mean I have to agree in the
end])Using separated voting count isn't an option? Like only internal
changes
are voted only by people with karma and features/changes/small BC
breaks
that affects userland are allowed to anyone. This way I believe is easy
to
say if either internals and community agrees with the proposed change
and
community people are making their opinion count.There are no plans (and enough people who'd veto such plans) to close
the mailing list. Everybody might state their opinion and we are happy to
receive (constructive) feedback and ideas here. And yes, this can be a bit
painful due to different forms of "trolling" but leads to better results
respecting
more opinions than a yes/no vote.
The problem with that model is that history has consistently shown that
those in power may listen, but will ultimately just do what they want,
anyway.
johannes
--
I feel it's also worth reminding everyone that VCS accounts generally
aren't given away like candy. Most people who have that access have done
something or another to earn it.
--Kris
Hi,
Slightly provocative: Why should I be forced to maintain code by
people who
don't want to maintain it themselves?Nobody is forcing you to do anything. You choose to contribute to PHP
in the manner in which you do, just as other people choose to
contribute in different, sometimes less obvious, ways.
Right, nobody can truely enforce me doing something, still I gave some
form of promise/commitment to less so since 5.3 reached EOL but still
this might require me to do something.
Probably even due to votes by people
about whom I don't know anything? Mind that most maintenance work by
most contributors happens in free time on a voluntarily base.And no open source doesn't mean democracy as governing model.
It can. Every project is governed differently.
Well democracy can mean so many things - in ancient Greece, the origin
of democracy, only the men of a social group had a vote. Even in
Switzerland, which is famous for its direct democracy, women weren't
allowed to vote till 1971 (in the canton Appenzell Innerrhoden even only
till 1990 for municipal issues) in others the voting power is unequally
distributed (see i.e. the EU parliament where larger countries have less
MEPs than smaller ones and different voting system's in different
countries give different weight to citizens of different countries)
Anyways this is a way different debate.
Winston Churchill once famously said that democracy is the worst form
of government, except all the others that have been tried.
While this depends on your view on what is good - Louis XIV of France
was quite happy with his, I assume. But government of a society is
different from governance of a software project. One case leads to a
revolution, the other to a fork.
The
democratic part is that people who don't like it can fork the
project and
eventually receive a higher traction.And then we can have dozens of competing PHP codebases floating
around.
That's were the social aspect comes back in - even people without a
formal vote have ability to impact the project.
The problem with that model is that history has consistently shown
that those in power may listen, but will ultimately just do what they
want, anyway.
If those with power will "ultimately just do what they want, anyway" the
official form of governance doesn't matter at all. Thanks for agreeing
to that :-D
But as this went to a path through European history let me reiterate and
clarify what I said in a different post in this thread: The strict
dependence on a vote impacts the constructive feedback for proposers
negatively. It also provides no feedbackloop for leading to constructive
critic being ignored, it becomes less clear whether voters were aware of
that. It also makes simple contributions hard, adding quite some
transactional cost for small improvements by newcomers. (then again here
is no clear and objective measure what "small" includes) This is
demotivating for all sides.
The approach I have in mind is going back to a consensus model by
default, allowing truly everybody to participate and giving the
opportunity to call for a vote if consensus can't be reached. Given our
social diversity I however think that this hardly works out as there
always will be somebody calling for a vote ... obvious consequence would
be a quorum for calling for a vote .. wich ends up in even more
bureaucracy hell.
I feel it's also worth reminding everyone that VCS accounts generally
aren't given away like candy. Most people who have that access have
done something or another to earn it.
It depends on the time of day and position of the stars, sometimes they
are thrown on people unless they run really fast, sometimes nobody looks
after requests ... :)
johannes
On Mon, Sep 22, 2014 at 7:21 PM, Johannes Schlüter johannes@schlueters.de
wrote:
Hi,
Slightly provocative: Why should I be forced to maintain code by
people who
don't want to maintain it themselves?Nobody is forcing you to do anything. You choose to contribute to PHP
in the manner in which you do, just as other people choose to
contribute in different, sometimes less obvious, ways.Right, nobody can truely enforce me doing something, still I gave some
form of promise/commitment to less so since 5.3 reached EOL but still
this might require me to do something.Probably even due to votes by people
about whom I don't know anything? Mind that most maintenance work by
most contributors happens in free time on a voluntarily base.And no open source doesn't mean democracy as governing model.
It can. Every project is governed differently.
Well democracy can mean so many things - in ancient Greece, the origin
of democracy, only the men of a social group had a vote. Even in
Switzerland, which is famous for its direct democracy, women weren't
allowed to vote till 1971 (in the canton Appenzell Innerrhoden even only
till 1990 for municipal issues) in others the voting power is unequally
distributed (see i.e. the EU parliament where larger countries have less
MEPs than smaller ones and different voting system's in different
countries give different weight to citizens of different countries)Anyways this is a way different debate.
Fair enough.
Winston Churchill once famously said that democracy is the worst form
of government, except all the others that have been tried.While this depends on your view on what is good - Louis XIV of France
was quite happy with his, I assume. But government of a society is
different from governance of a software project. One case leads to a
revolution, the other to a fork.
Also fair enough.
The
democratic part is that people who don't like it can fork the
project and
eventually receive a higher traction.And then we can have dozens of competing PHP codebases floating
around.That's were the social aspect comes back in - even people without a
formal vote have ability to impact the project.
But that's assuming the threat of fork will be enough, thereby keeping
forks to a minimum. I'm not sure I can concur with that assumption.
The problem with that model is that history has consistently shown
that those in power may listen, but will ultimately just do what they
want, anyway.If those with power will "ultimately just do what they want, anyway" the
official form of governance doesn't matter at all. Thanks for agreeing
to that :-D
I think you misunderstood. Ignoring vote results derived from a
legitimized process that was agreed to is much more difficult that ignoring
a request made by some person without karma, with or without the threat of
a fork.
But as this went to a path through European history let me reiterate and
clarify what I said in a different post in this thread: The strict
dependence on a vote impacts the constructive feedback for proposers
negatively. It also provides no feedbackloop for leading to constructive
critic being ignored, it becomes less clear whether voters were aware of
that. It also makes simple contributions hard, adding quite some
transactional cost for small improvements by newcomers. (then again here
is no clear and objective measure what "small" includes) This is
demotivating for all sides.
I wouldn't be against modifying the voting process to require everyone to
state a brief reason for their vote in order for it to be counted. The
current table could be modified to add a text column easily enough, I'm
sure, and the results could display the reason next to each vote in the
row. I think that would at least help mitigate the concerns you're raising
here.
The approach I have in mind is going back to a consensus model by
default, allowing truly everybody to participate and giving the
opportunity to call for a vote if consensus can't be reached. Given our
social diversity I however think that this hardly works out as there
always will be somebody calling for a vote ... obvious consequence would
be a quorum for calling for a vote .. wich ends up in even more
bureaucracy hell.
I've noticed that minor changes are already made all the time without a
vote being called and I don't have any problem with that, nor am I aware of
anyone else who does. Perhaps we could clarify exactly when a vote is
required and when it's not, but since that does not appear to have been an
issue thus far, it would probably just be a solution in search of a problem.
I feel it's also worth reminding everyone that VCS accounts generally
aren't given away like candy. Most people who have that access have
done something or another to earn it.It depends on the time of day and position of the stars, sometimes they
are thrown on people unless they run really fast, sometimes nobody looks
after requests ... :)
Heh true. Perhaps we should focus our energy toward improving the process
of giving out VCS accounts, instead.
johannes
--Kris
On Tue, Sep 23, 2014 at 4:21 AM, Johannes Schlüter
johannes@schlueters.de wrote:
The approach I have in mind is going back to a consensus model by
default, allowing truly everybody to participate and giving the
opportunity to call for a vote if consensus can't be reached.
It never worked in the last decade+, what makes you think it will work
all of a sudden?
All I see is some being afraid to loose control while all RFCs show
that it is by far not the case. The active core devs did not loose
control and we reached many consensuses. We have a couple of issues
but the roots of them are very clear. All is all there is no reason to
go back in a very bad time for php.
Given our
social diversity I however think that this hardly works out as there
always will be somebody calling for a vote ... obvious consequence would
be a quorum for calling for a vote .. wich ends up in even more
bureaucracy hell.
There is no bureaucracy hell but an end to endless discussions,
pressures, and other nonconstructive behaviors. The recent RFC events
about starting, ending, counting are unlucky but easily fixable.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Perhaps I’m being unfair and overthinking things, but I wonder if it
is really fair for people who have no karma, i.e. not contributors to
the documentation, extensions, php-src or anything else, to have the
ability to vote on RFCs?I’d never suggest people without internals karma can’t vote. I think
doc and peck contributors are as valued as any other contributors.
However, people with no karma whatsoever (a blank people.php.net page)
voting irks me.I think people's votes should only count if they have karma to the
section of the code that the RFC/feature/whatever relates to.Is that really fair? If we break BC, plenty of userland developers
might be affected and they should have a right to chime in.
Breaking BC should never happen anyway.
cheers,
Derick
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Monday, September 22, 2014 2:33 PM
To: Andrea Faulds
Cc: PHP internals
Subject: Re: [PHP-DEV] Is it fair that people with no karma can vote on
RFCs?I think people's votes should only count if they have karma to the section
of
the code that the RFC/feature/whatever relates to.
I agree with that, to a degree. I think it depends on whether we're talking
about implementation RFCs or feature RFCs.
As I mentioned in the past, when the Voting RFC was written - I never
envisioned it would be used for implementation decisions. Maybe it was
short sighted, maybe not - but to me, it was obvious that implementation
would be up to the respective code owners, and not the full voter base. So
yes, implementation issues that deal with the engine should be decided by
those who have engine karma. Implementation decisions to the mysqli
extension should be up to those who contributed to this codebase, even if
there's just a handful of them. And so on and so forth. Johannes recent
comments about maintenance of code are a major reason behind this approach,
but it goes beyond fairness. The contributors are the domain experts in the
respective implementations - it makes no sense to open this up to the voter
base at large. You want to have a say? By all means, work your way in and
contribute; Once you do, you'd have a vote. Until then, you have a voice
in internals, but not a vote.
The second group is trickier - and those are language features and other
types of votes. The way we work today - where SVN yes/no is the only
question - was absolutely not the intent of the Voting RFC and thankfully,
it's also clearly not the language it contains. The original RFC read the
following:
- People with php.net SVN accounts that have contributed code to PHP
- Representatives from the PHP community, that will be chosen by those with
php.net SVN accounts
Unfortunately, this was changed without me noticing it at the time, to the
following:
- People with php.net SVN accounts that have contributed code to PHP
- Representatives from the PHP community, that will be chosen by those with
php.net SVN accounts- Lead developers of PHP based projects (frameworks, cms, tools, etc.)
- regular participant of internals discussions
The first bullet is the one this thread deals with so far. It clearly
states that having an SVN account isn't enough - but that code contributions
to PHP are mandatory. We should probably consider revising that to also
account for people contributing docs and other types of submissions. I'd
also consider adding a requirement for contributing at least X commits (say
20 or 50) so that someone who did a one-off or two-off patch won't have the
same vote as someone who contributed hundreds or thousands of commits. I
believe this data can be easily pulled from git.
While we're at it, IMHO, the second bucket is open ended and must be much
more well defined. I think we need a process where people from the
community can be nominated and voted on - either by people from the first
line, or by some sort of a public community poll. Having 'elections' for
representatives from the community doesn't sound like a bad idea to me :)
Another option is to take the 1-2 top contributors of the 10-20 top PHP
projects on github. That's probably a lot easier and would eliminate much
of the politics involved.
Last, the 2nd sub-bullet of the 2nd bullet ("regular participant of
internals discussions") is especially problematic - as it basically pulls
the barrier to entry to nothing, and is the opposite of well-defined. When
we revise the Voting RFC, it should go IMHO. Talk is cheap - the way to get
a vote with PHP is to contribute - be it with code, docs, testing,
frameworks or apps.
Zeev
Last, the 2nd sub-bullet of the 2nd bullet ("regular participant of
internals discussions") is especially problematic - as it basically pulls
the barrier to entry to nothing, and is the opposite of well-defined.
When
we revise the Voting RFC, it should go IMHO. Talk is cheap - the way to
get
a vote with PHP is to contribute - be it with code, docs, testing,
frameworks or apps.
To kill the FUD about totally random ppl being able to vote:
To my knowdlege, nobody fitting in what is describe in this last line ever
voted. If someone knows a case where it happened, let me know.
account for people contributing docs and other types of submissions. I'd
also consider adding a requirement for contributing at least X commits
(say
20 or 50) so that someone who did a one-off or two-off patch won't have
the
same vote as someone who contributed hundreds or thousands of commits. I
believe this data can be easily pulled from git.
And let add a time since actual last commit too?
This is bad in so many ways...
The first bullet is the one this thread deals with so far. It clearly
states that having an SVN account isn't enough - but that code contributions
to PHP are mandatory. We should probably consider revising that to also
account for people contributing docs and other types of submissions. I'd
also consider adding a requirement for contributing at least X commits (say
20 or 50) so that someone who did a one-off or two-off patch won't have the
same vote as someone who contributed hundreds or thousands of commits. I
believe this data can be easily pulled from git.
That's a horrible idea. From a very quick unscientific glance at
https://github.com/php/php-src/graphs/contributors there's only ~50
people ever to have more than 20 commits in php-src. (Incidentally I'm
at the very bottom with 22, should I be happy to just have made the cut
if php-src commits are the only metric?)
I'm not saying karma could be revoked after a few years, especially if
there were cases where it was given back instantly on return, but this
all sounds like a bureaucratic mess. Also, how do you value people
reproducing bugs, checking the bugtracker, testing every build, etc.pp?
There are a lot of tasks that are a lot more important in every day work
than only writing internals code.
I don't have a solution ready, but maybe I'm just too much in the middle
ground - not a day to day contributor, but with an account nearly 11
years old and enough inactivity breaks of months to years I feel
entitled enough to see both sides.
Greetings,
Florian
The first bullet is the one this thread deals with so far. It clearly
states that having an SVN account isn't enough - but that code contributions
to PHP are mandatory. We should probably consider revising that to also
account for people contributing docs and other types of submissions. I'd
also consider adding a requirement for contributing at least X commits (say
20 or 50) so that someone who did a one-off or two-off patch won't have the
same vote as someone who contributed hundreds or thousands of commits. I
believe this data can be easily pulled from git.That's a horrible idea. From a very quick unscientific glance at
https://github.com/php/php-src/graphs/contributors there's only ~50
people ever to have more than 20 commits in php-src. (Incidentally I'm
at the very bottom with 22, should I be happy to just have made the cut
if php-src commits are the only metric?)I'm not saying karma could be revoked after a few years, especially if
there were cases where it was given back instantly on return, but this
all sounds like a bureaucratic mess. Also, how do you value people
reproducing bugs, checking the bugtracker, testing every build, etc.pp?
There are a lot of tasks that are a lot more important in every day work
than only writing internals code.I don't have a solution ready, but maybe I'm just too much in the middle
ground - not a day to day contributor, but with an account nearly 11
years old and enough inactivity breaks of months to years I feel
entitled enough to see both sides.
also the method is by far buggy, for me at least :) I have way more
than 133 commits in php history, maybe got lost somehow in git
migration, no idea :)
https://www.openhub.net/p/php/contributors?query=&sort=commits shows
more but also incomplete, for what php-src contains.
The funny part is when we look at the recent, or 1-5 years activity,
if we begin to apply such insane filters to allow votes, some may not
even vote anymore. In short, let trash this horrible idea.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
On Tue, Sep 23, 2014 at 10:27 AM, Florian Anderiasch ml@anderiasch.de
wrote:
The first bullet is the one this thread deals with so far. It clearly
states that having an SVN account isn't enough - but that code
contributions
to PHP are mandatory. We should probably consider revising that to also
account for people contributing docs and other types of submissions. I'd
also consider adding a requirement for contributing at least X commits
(say
20 or 50) so that someone who did a one-off or two-off patch won't have
the
same vote as someone who contributed hundreds or thousands of commits.
I
believe this data can be easily pulled from git.That's a horrible idea. From a very quick unscientific glance at
https://github.com/php/php-src/graphs/contributors there's only ~50
people ever to have more than 20 commits in php-src. (Incidentally I'm
at the very bottom with 22, should I be happy to just have made the cut
if php-src commits are the only metric?)
from a quick look that list only contains the contributors with an existing
(and matching) github account.
there are around 170 accounts with 20 or more commits:
https://gist.github.com/Tyrael/3bf0d24d33cf6b9e828b
ofc. some of those accounts are technical ones like the one with the empty
name (was used for changelog entries from a quick look), and there are also
some commits which were done by the same person but using different
email/author name.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Tue, Sep 23, 2014 at 10:27 AM, Florian Anderiasch ml@anderiasch.de
wrote:The first bullet is the one this thread deals with so far. It clearly
states that having an SVN account isn't enough - but that code
contributions
to PHP are mandatory. We should probably consider revising that to also
account for people contributing docs and other types of submissions. I'd
also consider adding a requirement for contributing at least X commits
(say
20 or 50) so that someone who did a one-off or two-off patch won't have
the
same vote as someone who contributed hundreds or thousands of commits.
I
believe this data can be easily pulled from git.That's a horrible idea. From a very quick unscientific glance at
https://github.com/php/php-src/graphs/contributors there's only ~50
people ever to have more than 20 commits in php-src. (Incidentally I'm
at the very bottom with 22, should I be happy to just have made the cut
if php-src commits are the only metric?)from a quick look that list only contains the contributors with an existing
(and matching) github account.
there are around 170 accounts with 20 or more commits:
https://gist.github.com/Tyrael/3bf0d24d33cf6b9e828b
ofc. some of those accounts are technical ones like the one with the empty
name (was used for changelog entries from a quick look), and there are also
some commits which were done by the same person but using different
email/author name.
Even that list is not complete - it shows me with only 1 commit while
I've got 2 pull requests merged.
Cheers,
Andrey.
On Tue, Sep 23, 2014 at 10:27 AM, Florian Anderiasch ml@anderiasch.de
wrote:The first bullet is the one this thread deals with so far. It clearly
states that having an SVN account isn't enough - but that code
contributions
to PHP are mandatory. We should probably consider revising that to
also
account for people contributing docs and other types of submissions.
I'd
also consider adding a requirement for contributing at least X commits
(say
20 or 50) so that someone who did a one-off or two-off patch won't
have
the
same vote as someone who contributed hundreds or thousands of
commits.
I
believe this data can be easily pulled from git.That's a horrible idea. From a very quick unscientific glance at
https://github.com/php/php-src/graphs/contributors there's only ~50
people ever to have more than 20 commits in php-src. (Incidentally I'm
at the very bottom with 22, should I be happy to just have made the cut
if php-src commits are the only metric?)from a quick look that list only contains the contributors with an
existing
(and matching) github account.
there are around 170 accounts with 20 or more commits:
https://gist.github.com/Tyrael/3bf0d24d33cf6b9e828b
ofc. some of those accounts are technical ones like the one with the
empty
name (was used for changelog entries from a quick look), and there are
also
some commits which were done by the same person but using different
email/author name.Even that list is not complete - it shows me with only 1 commit while
I've got 2 pull requests merged.
one of your pr's did not keep the author info, it seems as it was squashed
into a single commit:
http://git.php.net/?p=php-src.git;a=commit;h=ec2fff80e768dfb04aa393c06a2b1a42a9e871ff
so it isn't a problem with the list, but how your PR was merged.
ofc. probably there are other similar cases, so the potential number of
people with more than 20 commits could be different, but this the info we
have easy access to, and I don't think that it would change the numbers
significantly.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
one of your pr's did not keep the author info, it seems as it was squashed into a single commit:
http://git.php.net/?p=php-src.git;a=commit;h=ec2fff80e768dfb04aa393c06a2b1a42a9e871ff
so it isn't a problem with the list, but how your PR was merged.
ofc. probably there are other similar cases, so the potential number of people with more than 20 commits could be
different, but this the info we have easy access to, and I don't think that it would change the numbers significantly.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I do not think it makes sense to take the number of commits as metric. People's commit behaviour is different. Some commit only once after everything is done and others commit regularly after each achieved small step towards the goal.
I belong rather to the second group. Why should I be favoured over another person who has only one commit in his pull request?
one of your pr's did not keep the author info, it seems as it was
squashed into a single commit:http://git.php.net/?p=php-src.git;a=commit;h=ec2fff80e768dfb04aa393c06a2b1a42a9e871ff
so it isn't a problem with the list, but how your PR was merged.
ofc. probably there are other similar cases, so the potential number of
people with more than 20 commits could be
different, but this the info we have easy access to, and I don't think
that it would change the numbers significantly.--
Ferenc Kovács
@Tyr43l - http://tyrael.huI do not think it makes sense to take the number of commits as metric.
People's commit behaviour is different. Some commit only once after
everything is done and others commit regularly after each achieved small
step towards the goal.
I belong rather to the second group. Why should I be favoured over another
person who has only one commit in his pull request?
are you favored?
I was just pointing out a factual error about a claim in an earlier message
and how other factors can influence the number of commits counted
attributed to a person.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I do not think it makes sense to take the number of commits as metric.
People's commit behaviour is different. Some commit only once after
everything is done and others commit regularly after each achieved
small step towards the goal.
I belong rather to the second group. Why should I be favoured over
another person who has only one commit in his pull request?are you favored?
I was just pointing out a factual error about a claim in an earlier message and how other factors can influence the number of
commits counted attributed to a person.
Sorry, you obviously interpreted my message in a way I did not intend to bring it over. I did not intend to attack you or something. I merely wanted to point out that there are additional aspects which makes number of commits a rather fuzzy metric.
If this metric were be used then people which commit more regularly would be favoured and with committing regularly I do not mean implement many features, fixing bugs etc. but just that they use the git command "commit" more often than others.
I do not think it makes sense to take the number of commits as metric.
People's commit behaviour is different. Some commit only once after
everything is done and others commit regularly after each achieved
small step towards the goal.
I belong rather to the second group. Why should I be favoured over
another person who has only one commit in his pull request?are you favored?
I was just pointing out a factual error about a claim in an earlier
message and how other factors can influence the number of
commits counted attributed to a person.Sorry, you obviously interpreted my message in a way I did not intend to
bring it over. I did not intend to attack you or something. I merely wanted
to point out that there are additional aspects which makes number of
commits a rather fuzzy metric.
If this metric were be used then people which commit more regularly would
be favoured and with committing regularly I do not mean implement many
features, fixing bugs etc. but just that they use the git command "commit"
more often than others.
and I completely agree with that.
replying to my email (which only corrected some numbers) seemed like you
are assuming/projecting that it was my idea to bring those numbers to the
discussion.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I do not think it makes sense to take the number of commits as metric.
People's commit behaviour is different. Some commit only once after
everything is done and others commit regularly after each achieved
small step towards the goal.
I belong rather to the second group. Why should I be favoured over
another person who has only one commit in his pull request?are you favored?
I was just pointing out a factual error about a claim in an earlier
message and how other factors can influence the number of
commits counted attributed to a person.Sorry, you obviously interpreted my message in a way I did not intend to
bring it over. I did not intend to attack you or something. I merely wanted
to point out that there are additional aspects which makes number of
commits a rather fuzzy metric.
If this metric were be used then people which commit more regularly would
be favoured and with committing regularly I do not mean implement many
features, fixing bugs etc. but just that they use the git command "commit"
more often than others.and I completely agree with that.
replying to my email (which only corrected some numbers) seemed like you
are assuming/projecting that it was my idea to bring those numbers to the
discussion.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
for the record:
I've just approved two outstanding account requests from people who already
contributed sufficient amount of patches through PRs and explicitly stated
that they don't want php-src karma for now, but they want to be able to
assign bugs to themselves and one of them also mentioned that he wants to
be able to vote on RFCs.
I think that it was ok to approve their accounts (otherwise I wouldn't done
it), but this means two more accounts without karma (albeit probably that
will change as they get more confident and realize that it doesn't really
matter who merges the PR as long as it is properly discussed and reviewed).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
-----Original Message-----
From: Robert Stoll [mailto:php@tutteli.ch]
Sent: Tuesday, September 23, 2014 5:48 PM
To: 'Ferenc Kovacs'; 'Andrey Andreev'
Cc: 'Florian Anderiasch'; 'Zeev Suraski'; 'Derick Rethans'; 'Andrea
Faulds'; 'PHP
internals'
Subject: AW: [PHP-DEV] Is it fair that people with no karma can vote on
RFCs?one of your pr's did not keep the author info, it seems as it was
squashed
into a single commit:
http://git.php.net/?p=php-
src.git;a=commit;h=ec2fff80e768dfb04aa393c06
a2b1a42a9e871ff so it isn't a problem with the list, but how your PR
was merged.
ofc. probably there are other similar cases, so the potential number
of people with more than 20 commits could be different, but this the
info
we have easy access to, and I don't think that it would change the numbers
significantly.--
Ferenc Kovács
@Tyr43l - http://tyrael.huI do not think it makes sense to take the number of commits as metric.
I'd welcome better suggestions if anybody has any. I think the complete
lack of metrics and exceptionally low barrier to voting is a much bigger
problem.
Perhaps LoC?
That said, 20 commits is an exceptionally low bar IMHO to get a say for a
project with a HUGE impact such as PHP. I think it might look high since
people got used to the idea that they can vote even if they've never
contributed anything to PHP at all. I suspect that if I asked people from
the Linux Kernel community what they think about the idea that someone who
contributed 20 commits to the kernel would have the same say as Linus
Torvalds, they'd think I had a bit too much to drink.
Zeev
I'd welcome better suggestions if anybody has any. I think the complete
lack of metrics and exceptionally low barrier to voting is a much bigger
problem.
Please point me at a vote where the author is not part of what you defined
(and the rfc):
- php karma (doc)
- lead of leading projects
Now to create classes along developers or regular contributors is the worst
idea we can have. It says that writing docs is less valuable than a PoC.
Wrong in so many ways.
Perhaps LoC?
Oh gosh...
That said, 20 commits is an exceptionally low bar IMHO to get a say for a
project with a HUGE impact such as PHP.
And what's about zero commit in 5+ years?
This discussion has the bad taste of creating a kind of elite in php.net.
That's a horrible idea. From a very quick unscientific glance at
https://github.com/php/php-src/graphs/contributors there's only ~50
people ever to have more than 20 commits in php-src.
I believe this may be partially due to the fact that github will only show
contributors to the default branch (master in our case). There are some
other reasons why commits may not be attributed; see
https://help.github.com/articles/why-are-my-contributions-not-showing-up-on-my-profile
Obviously this was just a very unscientific scan, but worth noting.
Perhaps I’m being unfair and overthinking things, but I wonder if it
is really fair for people who have no karma, i.e. not contributors to
the documentation, extensions, php-src or anything else, to have the
ability to vote on RFCs?I’d never suggest people without internals karma can’t vote. I think
doc and peck contributors are as valued as any other contributors.
However, people with no karma whatsoever (a blank people.php.net page)
voting irks me.I think people's votes should only count if they have karma to the
section of the code that the RFC/feature/whatever relates to.
+1. I've said this plenty over the last couple of years, as IRC
regulars can attest to. Ultimately, people who actually know and
maintain the codebase should be making the final decisions.
Which is definitely not to say that we shouldn't be listening to
people outside the voting group — obviously, we should listen, and get
feedback. I just don't believe that the haziness of the current
process ("we might give you a voting account if you meet mostly
undefined criteria which no two people actually agree on, which then
allows you to provide a single tick with no feedback") encourages
that, and at some point we're going to end up with a feature being
committed that is going to cause major headaches for day to day
developers.
Adam