Hi internals,
The heated debate about attribute syntax made me think once again that it
would be valuable to get feedback in the form of votes from the community,
not just from core developers, on RFCs under discussion.
Understandably, the RFC voting process needs to be restricted to carefully
selected people, mostly core developers. But the fact is, this process is a
bit elitist, and fails to represent the community as a whole. A recent
thread https://externals.io/message/111552 showed that even very active
contributors to OSS are unlikely to ever get a vote.
A project being nothing without its users, it would be nice to know whether
an important change will make them happy or not.
Therefore, I have in mind to develop (time permitting) an experimental
tool, external to the PHP wiki, that would replicate the voting options of
each RFC, but would allow everyone with a GitHub account to vote on the
same options as the original RFC. While the vote results would not directly
affect the wiki's vote results, I guess that this community feedback could
be taken into consideration by wiki voters and help them make an informed
decision.
To be useful, a link to the community voting site would need to be present
in each RFC, ideally some time before the actual voting starts on the wiki.
If popular enough, this tool could offer some analysis capabilities, such
as "what's the vote results from people having at least 100 commits to the
top 1000 packagist projects in the last year?" to help filter out the noise.
Thoughts?
Kind regards,
Benjamin
Hi internals,
The heated debate about attribute syntax made me think once again that it
would be valuable to get feedback in the form of votes from the community,
not just from core developers, on RFCs under discussion.Understandably, the RFC voting process needs to be restricted to carefully
selected people, mostly core developers. But the fact is, this process is a
bit elitist, and fails to represent the community as a whole. A recent
thread https://externals.io/message/111552 showed that even very active
contributors to OSS are unlikely to ever get a vote.A project being nothing without its users, it would be nice to know whether
an important change will make them happy or not.Therefore, I have in mind to develop (time permitting) an experimental
tool, external to the PHP wiki, that would replicate the voting options of
each RFC, but would allow everyone with a GitHub account to vote on the
same options as the original RFC. While the vote results would not directly
affect the wiki's vote results, I guess that this community feedback could
be taken into consideration by wiki voters and help them make an informed
decision.To be useful, a link to the community voting site would need to be present
in each RFC, ideally some time before the actual voting starts on the wiki.If popular enough, this tool could offer some analysis capabilities, such
as "what's the vote results from people having at least 100 commits to the
top 1000 packagist projects in the last year?" to help filter out the noise.Thoughts?
I think there’s already a fair amount of community representation on
this list, and while there are sometimes criticisms levied at
internals, such as “internals doesn’t use PHP” or “internals doesn’t
understand what the rest of the PHP community wants,” I think these are
false or mistaken. A lot of the folks who have voting privileges and
who actively participate in voting on RFCs are already what some might
call “at-large” community representatives.
Those on this list who have wider community networks often seek
feedback on RFCs from their network. None of this is done in a vacuum.
It’s all fairly transparent, and if non-voting members want to provide
input, they have various ways to do so (e.g., posting here, giving
feedback to someone who is active here, etc.).
That said, I never want to discourage more involvement from the wider
community, but I think something like what you’re proposing needs to be
handled carefully. I think it would need to be clear that this is not a
binding vote. Rather, it’s an informal poll to gauge
support/interest in something. People who do have RFC voting privileges
are not obligated to vote one way or another based on the results of
the poll.
In the end, it may be best if an informal poll like this is conducted
by a third-party who does not have RFC voting privileges (so that they
could be considered neutral and unrelated to internals). This way,
there’s no confusion over the purpose of the poll, and it is simply
information that may be shared with internals but is not officially
sanctioned by the PHP project.
There’s nothing stopping anyone from doing this right now. :-)
Cheers,
Ben
Thank you for your feedback, Ben & Stanislav.
Ben:
It’s all fairly transparent, and if non-voting members want to provide
input, they have various ways to do so (e.g., posting here, giving
feedback to someone who is active here, etc.).
While this is true, I'm afraid the opportunities to provide "lightweight"
feedback are fairly limited. For the same reason I hate not being able to
just "+1" a message on @internals without having to reply and pollute the
thread with just a thumbs up, I feel like someone may just want to give
their opinion in a poll, without having to post a "I like XXX
syntax" message on @internals.
I think it would need to be clear that this is not a
binding vote. Rather, it’s an informal poll to gauge
support/interest in something. People who do have RFC voting privileges
are not obligated to vote one way or another based on the results of
the poll.
A *poll *reflects much better what I had in mind, indeed!
In the end, it may be best if an informal poll like this is conducted
by a third-party who does not have RFC voting privileges (so that they
could be considered neutral and unrelated to internals).
I don't have RFC voting privileges, so this condition would be met.
There’s nothing stopping anyone from doing this right now. :-)
Actually there is: without a link to the poll in the RFC itself, the poll
would probably not get enough visibility to be useful.
Stanislav:
If
somebody wants to voice an opinion, it's always welcome. But let's not
pretend like people who actually maintain PHP core and everybody who
ever used PHP or may be thinking about using it have equal weight here.
The whole idea would be to give people a straightforward way to voice their
opinion, without polluting @internals. As stated above, the wording would
be very clear that this is just a poll to help actual voters make an
informed decision, nothing more. If the poll gives a different result than
the RFC, the RFC obviously wins.
Please feel welcome to. However, I don't think this should have any
official role in any PHP governance process, any more than any other
poll on the internet might. That said, my opinion is hearing other
opinions is rarely harmful and frequently useful, so why not.
Again, this would only be useful if linked to from the RFC. Hence I'd need
to get some kind of approval on the idea here before venturing into an
implementation.
- Benjamin
There’s nothing stopping anyone from doing this right now. :-)
Actually there is: without a link to the poll in the RFC itself, the poll would probably not get enough visibility to be useful.
I don’t think the RFC should include a link to the poll. This makes the poll an official artifact of the PHP project.
I do think you should link to the poll in the discussion thread for the RFC on internals. This way, voters can use it as information to inform their decision. RFC authors can also take the information into account to discuss certain topics in an RFC they may have overlooked or left out.
Cheers,
Ben
There’s nothing stopping anyone from doing this right now. :-)
Actually there is: without a link to the poll in the RFC itself, the poll would probably not get enough visibility to be useful.
I don’t think the RFC should include a link to the poll. This makes the poll an official artifact of the PHP project.
I do think you should link to the poll in the discussion thread for the RFC on internals. This way, voters can use it as information to inform their decision. RFC authors can also take the information into account to discuss certain topics in an RFC they may have overlooked or left out.
To be clear, this kind of feedback needs to take place during the discussion period. A poll that takes place during the voting period can’t have any impact on the direction of the RFC.
Cheers,
Ben
Hi!
Understandably, the RFC voting process needs to be restricted to carefully
selected people, mostly core developers. But the fact is, this process is a
bit elitist, and fails to represent the community as a whole. A recent
PHP development is not a representative democracy. There's no
requirement to "represent" anyone, and nobody who doesn't contribute to
PHP development in a specific manner has any claim on a vote. If
somebody wants to voice an opinion, it's always welcome. But let's not
pretend like people who actually maintain PHP core and everybody who
ever used PHP or may be thinking about using it have equal weight here.
If it is "elitist" that's because there's the "elite" (not the word I
would choose but if we must keep with it for a minute) - people who
actually implement and maintain stuff. It doesn't mean they don't have
to listen to others - on the contrary - but there's no obligation not to
be "elitist".
A project being nothing without its users, it would be nice to know whether
an important change will make them happy or not.
If we could do that, it'd be awesome. I wouldn't mind using the same
tool to know the stock prices next year. But prediction is hard,
especially about the future. Only thing we can reasonably do is to know
the opinion of a tiny minority of the community, randomly self-selected,
about whether or not they think they will like something without the
experience of actually using it. That's certainly better than nothing,
but I wouldn't exaggerate too much about how much better.
Therefore, I have in mind to develop (time permitting) an experimental
tool, external to the PHP wiki, that would replicate the voting options of
each RFC, but would allow everyone with a GitHub account to vote on the
same options as the original RFC. While the vote results would not directly
Please feel welcome to. However, I don't think this should have any
official role in any PHP governance process, any more than any other
poll on the internet might. That said, my opinion is hearing other
opinions is rarely harmful and frequently useful, so why not.
--
Stas Malyshev
smalyshev@gmail.com
Den tor. 20. aug. 2020 kl. 01.07 skrev Stanislav Malyshev smalyshev@gmail.com:
Please feel welcome to. However, I don't think this should have any
official role in any PHP governance process, any more than any other
poll on the internet might. That said, my opinion is hearing other
opinions is rarely harmful and frequently useful, so why not.
I very much agree with Stas here. I think it should be up to the
individual RFC author to put out feelers for feedback from userland,
because going to internals is the final judgement.
Regarding the link to the thread in the initial email, while it is not
impossible to get voting rights. There is a very high barrier of
entry, if you are not involved with the PHP project, then being
granted voting rights is absurd and can easily flood the usual Core
Developer voting turnout, we had a similar debate about this in the
spring of 2019 in regards to the PHP FIG which was heavily disputed.
Anyone who is not actively involved with the PHP project, is not
someone I can feel safe with granting the right to vote. Should I also
gain the right at any PHP based project to vote on whatever democratic
process they have because I am a maintainer of PHP? No I shouldn't. If
I'm involved with a project in question, then that changes the
perspective but it is still up to the project to decide on how to
proceed here.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Den tor. 20. aug. 2020 kl. 01.07 skrev Stanislav Malyshev smalyshev@gmail.com:
Please feel welcome to. However, I don't think this should have any
official role in any PHP governance process, any more than any other
poll on the internet might. That said, my opinion is hearing other
opinions is rarely harmful and frequently useful, so why not.I very much agree with Stas here. I think it should be up to the
individual RFC author to put out feelers for feedback from userland,
because going to internals is the final judgement.Regarding the link to the thread in the initial email, while it is not
impossible to get voting rights. There is a very high barrier of
entry, if you are not involved with the PHP project, then being
granted voting rights is absurd and can easily flood the usual Core
Developer voting turnout, we had a similar debate about this in the
spring of 2019 in regards to the PHP FIG which was heavily disputed.Anyone who is not actively involved with the PHP project, is not
someone I can feel safe with granting the right to vote. Should I also
gain the right at any PHP based project to vote on whatever democratic
process they have because I am a maintainer of PHP? No I shouldn't. If
I'm involved with a project in question, then that changes the
perspective but it is still up to the project to decide on how to
proceed here.
I've had very good success with explicitly non-binding polls/surveys in the past with FIG. They can really help to cut through the "a few loud people say X, but we don't know if that's actually the broad position" problem. I'd support such a mechanism being available to RFC authors. That would be a better way to "poll the audience" than the current "Go read reddit and see what they said" mechanism. It also can allow for non-binary questions, like gauging opinion on something from 1-10 (or 1-7, or whatever). Specifically:
- Some standard recognized way of doing so. That could be as simple as "use a Google form and remember to ask these specific questions" (which is what I did for FIG).
- It's optional for RFC authors to use or not.
- It's very clearly labeled a survey, not a binding vote.
- RFC authors should use it before an actual vote starts.
- Voters can give the poll results as much weight as they feel like giving it.
I think that could be a useful data gathering tool without rocking the status quo too much.
--Larry Garfield
Hi Kalle, all
Anyone who is not actively involved with the PHP project, is not
someone I can feel safe with granting the right to vote.
Just want to point out that there are lots of people eligable to vote who are not actively involved with PHP development at the moment. There has even been a few occasions lately where I tweet about my point of view on an RFC which has been in voting phase for over a week, and suddenly someone replies "Oh that's interesting, I'll vote for that later today". In other words: a tweet from a random userland developer reminded someone to vote.
What about people who occasionaly contribute to docs? Are they more eligable to vote than someone like Nicalos Grekas? It's a good thing he got voting rights, but in my mind that should have been a no-brainer. I realise some people might get upset with this point of view, but I don't think that occasionaly contributing to PHP docs makes you a better representative than having actively shaped the PHP landscape over the past decade.
How many people have voting rights? Over 200 if I'm not mistaken? How many of those have been activly contributing to PHP for over the past year? I think that's a better question to answer. If half of those people's voting rights get revoked then maybe there's room to allow a few more key community figures to participate?
I very much agree with Stas here.
I agree too btw. There's no need for official community polls, I feel like the key figures of PHP's core team already do listen to the community.
Kind regards
Brent
Den tor. 20. aug. 2020 kl. 01.07 skrev Stanislav Malyshev smalyshev@gmail.com:
Please feel welcome to. However, I don't think this should have any
official role in any PHP governance process, any more than any other
poll on the internet might. That said, my opinion is hearing other
opinions is rarely harmful and frequently useful, so why not.I very much agree with Stas here. I think it should be up to the
individual RFC author to put out feelers for feedback from userland,
because going to internals is the final judgement.Regarding the link to the thread in the initial email, while it is not
impossible to get voting rights. There is a very high barrier of
entry, if you are not involved with the PHP project, then being
granted voting rights is absurd and can easily flood the usual Core
Developer voting turnout, we had a similar debate about this in the
spring of 2019 in regards to the PHP FIG which was heavily disputed.Anyone who is not actively involved with the PHP project, is not
someone I can feel safe with granting the right to vote. Should I also
gain the right at any PHP based project to vote on whatever democratic
process they have because I am a maintainer of PHP? No I shouldn't. If
I'm involved with a project in question, then that changes the
perspective but it is still up to the project to decide on how to
proceed here.--
regards,Kalle Sommer Nielsen
kalle@php.net--
To unsubscribe, visit: https://www.php.net/unsub.php
Den fre. 21. aug. 2020 kl. 09.03 skrev Brent Roose brendt@stitcher.io:
What about people who occasionaly contribute to docs? Are they more eligable to vote than someone like Nicalos Grekas? It's a good thing he got voting rights, but in my mind that should have been a no-brainer. I realise some people might get upset with this point of view, but I don't think that occasionaly contributing to PHP docs makes you a better representative than having actively shaped the PHP landscape over the past decade.
Difference is that people who "occasionally" contribute to docs are
involved with the PHP project, they are contributors, not users. So
yes they are more eligible to vote because that is the privilege that
they earn by being contributors, not users. Sure we have a high
barrier of entry, but if we let the floodgates open for any abled soul
to begin voting and judging then we would never get anything
productive done. The RFC experiment on Github was a mess, sure there
was some valuable feedback there but there was a multitude of equal
feedback that was useless because it was so open.
How many people have voting rights? Over 200 if I'm not mistaken? How many of those have been activly contributing to PHP for over the past year? I think that's a better question to answer. If half of those people's voting rights get revoked then maybe there's room to allow a few more key community figures to participate?
There are 1876 VCS accounts and then we have a number of wiki only
users who can vote. We have no metrics that can measure such, because
a lot of things happen behind the scenes that you see. The discussion
that I referenced in my earlier reply that took place last year tried
to revoke existing contributors from their right to vote that they
have earned by using the amount of commits or something in that
direction as a metric to tell if a contributor was "active". Neither
do we have a process to clean this, and for most project members that
seems fine so it has not changed. What baffles me is that non project
contributors really seem interested in taking a stab at this without
really being involved in the project in any way.
If you want to have the right to vote, then please earn it by being a
part of the project. If I want the right to vote on features in
userland projects, then I would also earn it like a regular
contributor if I wanted it so dearly. It really does not take much
effort.
There is nothing that stops an RFC author from surveying userland
various communities before they seek to have it accepted into PHP
proper. Twitter is a decent place to do so.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Hi!
How many people have voting rights? Over 200 if I'm not mistaken? How
many of those have been activly contributing to PHP for over the past
year? I think that's a better question to answer. If half of those
people's voting rights get revoked then maybe there's room to allow a
few more key community figures to participate?
There's no reason to. If these people don't contribute and don't vote -
so what? There's no limited pool of votes that needs to be distributed,
and as I said before, the reason for getting a vote is not passing
some kind of representation quota. If the person contributes
substantially, they should have a vote, regardless of how many or few
inactive voters are there. If they are not the part of the contributing
team, they are free to voice their opinion, which will be listened to,
but they won't be a part of the binding vote process.
--
Stas Malyshev
smalyshev@gmail.com
-1
Hi internals,
The heated debate about attribute syntax made me think once again that it
would be valuable to get feedback in the form of votes from the community,
not just from core developers, on RFCs under discussion.Understandably, the RFC voting process needs to be restricted to carefully
selected people, mostly core developers. But the fact is, this process is a
bit elitist, and fails to represent the community as a whole. A recent
thread https://externals.io/message/111552 showed that even very active
contributors to OSS are unlikely to ever get a vote.A project being nothing without its users, it would be nice to know whether
an important change will make them happy or not.Therefore, I have in mind to develop (time permitting) an experimental
tool, external to the PHP wiki, that would replicate the voting options of
each RFC, but would allow everyone with a GitHub account to vote on the
same options as the original RFC. While the vote results would not directly
affect the wiki's vote results, I guess that this community feedback could
be taken into consideration by wiki voters and help them make an informed
decision.To be useful, a link to the community voting site would need to be present
in each RFC, ideally some time before the actual voting starts on the wiki.If popular enough, this tool could offer some analysis capabilities, such
as "what's the vote results from people having at least 100 commits to the
top 1000 packagist projects in the last year?" to help filter out the noise.Thoughts?
Kind regards,
Benjamin