Hey.
I would like to get karma to be able to vote on RFCs. I understand that voting karma isn’t usually given out to people who write their first mailing list entry.
But I do believe I qualify as “Lead developers of PHP based projects (frameworks, cms, tools, etc.)”
For those of you who don’t know me, I’ve been working with open source PHP projects since 2015. I am part of Symfony core team, I wrote PSR-18 and was part of the working group for PSR-17. I also maintain Guzzle, webmozart/assert, Flysystem, HTTPlug and the php-http ecosystem and about 50 other packages with more than 100.000 monthly downloads.
I think I am the most downloaded PHP maintainer.
I have been following the RFCs more closely the past 2 years and I’ve finally gathered some courage to ask for karma. There has not been many (maybe just one or two) RFCs where I wished the vote turned out the other way. So, I don’t think I would have any radical opinions about future RFCs.
If I’ve understad the process correctly, I do need someone with a php.net VCS account to sponsor me.
My username is: nyholm
Regards
Tobias Nyholm
Hi
Den søn. 18. jul. 2021 kl. 21.47 skrev Tobias Nyholm tobias.nyholm@gmail.com:
Hey.
I would like to get karma to be able to vote on RFCs. I understand that voting karma isn’t usually given out to people who write their first mailing list entry.
I'm not comfortable with this if this is indeed your first person to
internals. There was a similar concern with the maintainer of PHPStan
a while ago, who while also have a large set of downloaded packages,
did not participate in the internals community by actively taking part
of the conversation at the time at least and the request turned out to
be declined.
-1 from me to prevent discrimination and keep it consistent.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Thank you Kalle for the reply.
I do admire and respect Ondřej and his work on PHPStan. He is really talented and from what I hear a really nice person. But please don’t confuse Ondřej’s 8 packages with over 100.000 monthly downloads with my 50 packages plus another 100 in the Symfony organization.
I have tried to approach PHP internals once before by asking for permission to modify some outdated wiki entries. I got rejected by you and after that I didn’t feel motivated to work with PHP (source/internals) for a while. I’m sure it wasn’t your intention, don’t worry about it. I also know that I have modified the manual, or at least I’ve tried because that process is really painful. I’m honestly not sure if I managed to submit my changes and if I did, I don’t remember if they got accepted or not.
I know there are plenty of things that could be improved, be more inclusive and less complicated. For example, the manual pages for Sodium. They were released 4 years ago and still lots of functions are missing examples, lots of parameters/return types are undocumented and it is impossible to understand how to use Sodium for someone without a CS degree. The reason why these pages are still not fully documented is not because lack of knowledge or lack of interest/energy.
I think PHP’s biggest strength is its large and active community. But in my opinion, PHP (source/internals) often miss to benefit from our great community. I am happy to help making changes, but I feel like it is an impossible task for me… I mean, I cannot even update an outdated wiki entry.
I know I’m not a “project leader” for any of the handful large PHP projects. I also know that I am far from the “top 1000 best developers” list. But I know that there are not many people (if any) that have a larger impact of user-land PHP right now.
(I do acknowledge that there are people with more impact over the Symfony community, the Laravel community, or the cool async community etc.)
The only thing I’m asking for is to be among those 1000+ people that can vote on the language’s future.
// Tobias
Hi!
I think PHP’s biggest strength is its large and active community. But
in my opinion, PHP (source/internals) often miss to benefit from our
great community. I am happy to help making changes, but I feel like
it is an impossible task for me… I mean, I cannot even update an
outdated wiki entry.
Why it's an impossible task for you and why it's related to voting? I
don't think you need voting access to fix docs or propose patches.
--
Stas Malyshev
smalyshev@gmail.com
I know I’m not a “project leader” for any of the handful large PHP
projects. I also know that I am far from the “top 1000 best developers”
list. But I know that there are not many people (if any) that have a larger
impact of user-land PHP right now.(I do acknowledge that there are people with more impact over the Symfony
community, the Laravel community, or the cool async community etc.)The only thing I’m asking for is to be among those 1000+ people that can
vote on the language’s future.// Tobias
There was a discussion a year ago
https://externals.io/message/107460#107465 about giving userland library
maintainers the right to do a semi-official vote, that would be non-binding
as far as the RFC is concerned, but would give people with RFC vote karma a
good idea of what the most influential userland library maintainers think
of a change in the language, so that they can take this variable into
account prior to voting themselves.
As a library author with 4 million downloads per month, it also crossed my
mind to request a right to vote on RFCs, but given previous discussions on
the topic, I understood that core maintainers are reluctant to give voting
rights to userland developers, whatever their influence, so I've restrained
myself from doing so so far.
I do understand the concern from core maintainers that if people voting on
RFCs are not the ones getting their hands dirty maintaining the codebase,
it can quickly become an issue. I would, however, strongly advise core
maintainers to consider the idea of performing an "official" library
maintainers vote before the actual vote takes place.
At the end of the day, we'll be the ones maintaining libraries that use
these new PHP features, that will have to provide compatibility for
multiple versions of PHP, etc. It would be nice if we could at least
formally give our opinion on each individual RFC. Yes, we can do so via the
mailing list, but this is just one message lost in the middle of a usually
verbose discussion, which is often discouraging to say the least.
— Benjamin
Le 18/07/2021 à 22:46, Kalle Sommer Nielsen a écrit :
Hi
Den søn. 18. jul. 2021 kl. 21.47 skrev Tobias Nyholm tobias.nyholm@gmail.com:
Hey.
I would like to get karma to be able to vote on RFCs. I understand that voting karma isn’t usually given out to people who write their first mailing list entry.I'm not comfortable with this if this is indeed your first person to
internals. There was a similar concern with the maintainer of PHPStan
a while ago, who while also have a large set of downloaded packages,
did not participate in the internals community by actively taking part
of the conversation at the time at least and the request turned out to
be declined.-1 from me to prevent discrimination and keep it consistent.
Hello,
I don't have karma as well, and I sure don't have the legitimacy to
represent anyone else but me, but I wouldn't feel comfortable if some
would have gain voting right because they maintain a lot of community
packages, and here's why:
- For once, I'm writing PHP since PHP 3, and doing it professionally
for more than 15 years, I wrote PHP code 8+ hours a day for the latest
15 years (more or less), I'm one of the many silent users for which each
language feature change will impact every-day's life. Maintaining open
source community driven tools doesn't make their writers fundamentally
better than the rest of us in programming, it just make them visible.
- All those daily silent users doesn't always agree with community
packages standards, style, design and direction, and that's legit, thus
community maintainers cannot represent all the daily users. Regarding a
community package, no matter how much it relies on community or users
and feedback, will always see its final decisions under the hand of a
few, which may not be representative (and for the best, since that the
maintainer will have to maintain it, it's only legit to let him/her decide).
- Proprietary code represents much more code in the end that
open-source, most of us write proprietary all day long, at least as much
code as we re-use community code.
I'm not comfortable with current voting process because all users can't
say their word about the language features they'd really want to see,
but on the other hand, the current voting process makes me safe because
only people deeply engaged in maintaining it can vote, and they don't
want their life to be harder, they want it to be a pleasure, which
drives them to essentially make good decisions. And I can still express
my opinion in this list, and I love PHP maintainers community for having
allowed it.
Maybe what's missing in all that would be an additional voting process,
not between people with karma, but a publicly opened one, like a survey,
for which anyone could vote. Those surveys wouldn't count for the final
decision, wouldn't have any "legal" outcome, but could give serious and
solid insight for RFC discussions. It'd give an overview about what PHP
users want and what they don't want or don't care about, this could
actually change some decisions.
I really like the way everything happens, it's a solid process where
only people that actually maintain or maintained the stuff can actually
decide about what to maintain in the future, it's good. But maybe, in my
opinion, it lacks one tiny detail: the global users feedback about how
each decision will impact them.
That was my 2 cents.
Regards,
--
Pierre
- For once, I'm writing PHP since PHP 3, and doing it professionally
for more than 15 years, I wrote PHP code 8+ hours a day for the latest
15 years (more or less), I'm one of the many silent users for which each
language feature change will impact every-day's life. Maintaining open
source community driven tools doesn't make their writers fundamentally
better than the rest of us in programming, it just make them visible.
I use php every day, I have been doing so for close to 10 years now.
Language features also impact my daily life, and I'm glad they do. The
software Tobias writes also has a big impact on my daily life, just like
PHP as I depend on a lot of his packages. Voting rights doesn't make
someone a better developer, and applying for them for this reason makes no
sense to me. Working with this many packages in the PHP ecosystem means
that one (hopefully) has a lot of experience in a lot of parts of
open-source software. In fact, open-source package maintainers are often
one of the first lines when it comes to PHP compatibility. They ensure your
software keeps working because they keep their packages up-to-date. Every
minor change in PHP can cascade into having to update hundreds of packages.
Every choice made can seem good for certain use-cases, and then completely
fall apart when someone with this much experience brings a good argument to
the table.
- All those daily silent users doesn't always agree with community
packages standards, style, design and direction, and that's legit, thus
community maintainers cannot represent all the daily users. Regarding a
community package, no matter how much it relies on community or users
and feedback, will always see its final decisions under the hand of a
few, which may not be representative (and for the best, since that the
maintainer will have to maintain it, it's only legit to let him/her them
decide).
They cannot and do not represent all the daily users. At best they decide
that a certain standard is worth keeping and (hopefully) ensure things like
consistency through the ecosystem. This can be seen through composer and
PSR autoloading for example.
- Proprietary code represents much more code in the end that
open-source, most of us write proprietary all day long, at least as much
code as we re-use community code.
A vast majority of proprietary code depends on open-source community
written by the community.
I think that people who have a big impact on the ecosystem should be able
to vote. Perhaps it would be an idea for other voters to vote on whether or
not others can receive voting rights? When someone contributes a lot of
(free) time to the ecosystem and makes a big impact, I think it's unfair to
ask for even more (free) time to make a direct contribution to PHP just to
get voting permissions, it feels like this is just for show.
Le 19/07/2021 à 10:11, Lynn a écrit :
A vast majority of proprietary code depends on open-source community
written by the community.
All your arguments are good ones, even if in my position I don't agree
with everything. Nevertheless, I specifically don't agree with this one:
a lot of proprietary code uses open-source community code, but is not
always tied to it. You're ignoring all projects that took the other
direction, clean architecture, business libraries, dependency-free code,
and others, whose goals are not to be dependent upon third party, but
rather integrate with them in the software stack edges, making it both
replaceable and discrete. I don't write "Symfony" projects, I write
business domain projects, Symfony only brings a nice dependency
injection container and a router I could both replace easily.
In my use case, focusing on my code is what primarily matters, and I'm
not denying language changes are impacting for open source software, but
I trust PHP for always keeping its BC promise (and it does, probably
thanks to "In fact, open-source package maintainers are often one of the
first lines when it comes to PHP compatibility"), which at least resolve
that.
Regards,
--
Pierre
Le 19/07/2021 à 10:11, Lynn a écrit :
A vast majority of proprietary code depends on open-source community
written by the community.All your arguments are good ones, even if in my position I don't agree
with everything. Nevertheless, I specifically don't agree with this one:
a lot of proprietary code uses open-source community code, but is not
always tied to it. You're ignoring all projects that took the other
direction, clean architecture, business libraries, dependency-free code,
and others, whose goals are not to be dependent upon third party, but
rather integrate with them in the software stack edges, making it both
replaceable and discrete. I don't write "Symfony" projects, I write
business domain projects, Symfony only brings a nice dependency
injection container and a router I could both replace easily.
Hence I wrote "A vast majority". Even if it's not your code directly, your
application has a dependency on open-source php software that is often
directly impacted by every decision voted on for php, whether this is
Symfony, Pimple, Laravel or any other dependency injection you've decided
to integrate. If you choose to use abstractions, then I think it's only
fair to have the authors of those abstractions have a say in changes that
impact their abstractions, whether it directly impacts the "end developer"
or not.
In my use case, focusing on my code is what primarily matters, and I'm
not denying language changes are impacting for open source software, but
I trust PHP for always keeping its BC promise (and it does, probably
thanks to "In fact, open-source package maintainers are often one of the
first lines when it comes to PHP compatibility"), which at least resolve
that.
I fully agree with this, as a developer I do not want to worry about low
level php changes that do not directly impact me. Therefore I think that
people who do get impacted by this (for example open-source package
managers), at least get a vote in these changes. It's unfair to put the
burden of writing abstractions on someone and then tell them they don't get
a say in making their lives easier or more difficult.
Other than that, polling with the community to see if an idea can get
traction before more proposing it on the mailing list or through an RFC is
always a good idea in my opinion.
Den man. 19. jul. 2021 kl. 12.11 skrev Lynn kjarli@gmail.com:
I fully agree with this, as a developer I do not want to worry about low level php changes that do not directly impact me. Therefore I think that people who do get impacted by this (for example open-source package managers), at least get a vote in these changes. It's unfair to put the burden of writing abstractions on someone and then tell them they don't get a say in making their lives easier or more difficult.
Why is it then fair to give them voting rights if they only contribute
their vote but not words before hand? Why is it only possible to give
feedback in terms of a +1 or -1 and not feedback in text form? Because
if its only possible in that way, it makes me think that it is purely
a PR thing which makes me worry that the power vested into the voter
may not be just.
Why is there no dialogs from their side on internals with problems
they may have with directions? So far I do see a few faces from the
community like representives static analyzers, Nicolas Grekas and
Marco Pivetta to name some who actively takes part of the challenges
at hand and even actively runs RFCs on their own with implementation
patches, which is fantastic and well deserved in my opinion.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Why is it then fair to give them voting rights if they only contribute
their vote but not words before hand? Why is it only possible to give
feedback in terms of a +1 or -1 and not feedback in text form? Because
if its only possible in that way, it makes me think that it is purely
a PR thing which makes me worry that the power vested into the voter
may not be just.
Currently there are people with voting permissions that do vote, yet do not
interact with RFCs or the mailing list. Regardless of the reasons one may
have for wanting to vote, the requirements given should be applied equally
if this is the argument.
Why is there no dialogs from their side on internals with problems
they may have with directions? So far I do see a few faces from the
community like representives static analyzers, Nicolas Grekas and
Marco Pivetta to name some who actively takes part of the challenges
at hand and even actively runs RFCs on their own with implementation
patches, which is fantastic and well deserved in my opinion.
Yes, and I love it when I see new users interact with the mailing list,
even when in the end the questions or arguments changed nothing to the RFC.
It shows that people are probably invested. How do you measure investment
behind the scenes though? How often has someone decided to not post
anything on the mailing list because after testing a bunch of changes
proposed, it worked and required no comment? Would every user that one day
would want to have voting rights post a "yes I agree" message in every
thread in order to show they contribute in discussions? Sometimes when I
see a change proposed, I will jump into 3v4l or my php -a and test if a
proposed change would work or break anything for an edge case I came up
with. Proposals and changes pretty much always work so I don't reply or
comment, this investment (for lack of better words from my side) can't be
measured.
I would personally be interested in knowing how much work Tobias does
behind the scenes to ensure proposed changes and RFCs work with code run by
thousands, if not millions of developers.
Den man. 19. jul. 2021 kl. 13.14 skrev Lynn kjarli@gmail.com:
Currently there are people with voting permissions that do vote, yet do not interact with RFCs or the mailing list. Regardless of the reasons one may have for wanting to vote, the requirements given should be applied equally if this is the argument.
If this is a problem, then why has the voting RFC not been amended to
require such commentary? That seems like a productive first step in
solving the issue instead of complaining about it not happening
automatically
Yes, and I love it when I see new users interact with the mailing list, even when in the end the questions or arguments changed nothing to the RFC. It shows that people are probably invested. How do you measure investment behind the scenes though? How often has someone decided to not post anything on the mailing list because after testing a bunch of changes proposed, it worked and required no comment?
How can I take that into consideration if no one lets me know about
that? This argument sounds more to me like an illusion, I cannot read
minds nor am I into experimentation on the matter, I cannot consider
what I do not know (similarly to the problem you pointed out above).
Would every user that one day would want to have voting rights post a "yes I agree" message in every thread in order to show they contribute in discussions?
That is not what I was implying and I am certain you know that. I
specifically mean the discussions, not the voting itself. Taking
Tobias here as an example, why is there no feedback from him on the
RFCs like[1][2][3] (which was recent as in 8.1, this is just a list
from a quick glance which may or not be accurate), they seem to me
like an good way he could have given feedback based on the work he put
forward that he had been involved with.
Why is it that political power should just be given without actually
taking part of the project and problems here at the PHP project? To me
that comes off as laziness. "I just want to vote, but take no
responsibility of maintaining the PHP project"
[1] https://wiki.php.net/rfc/curl_user_agent
[2] https://wiki.php.net/rfc/fsync_function
[3] https://wiki.php.net/rfc/fibers
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Hello all,
Tobias wants to obtain a right that lets him represent the community
in the RFCs' approval. Tobias, as for the feature requests, you can
discuss and propose your own ideas. You can also obtain RFC karma to
propose your ideas and contribute to the language.
As for the people that are going to give the final vote, PHP
maintainers need to make a proper policy for this process. I am going
to give a basic idea. They can better brainstorm.
The person that wants to have the voting rights may qualify for the following:
- The person may have RFC karma already.
- After obtaining an RFC karma, it may have been active on the
mailing list for a specific time period. - It may have n number of bugs solved and merged.
- It may have worked with senior developers of php at least on the n
number of RFCs. - Optionally, it may have some of his own RFCs approved or rejected
with minimum percentage. - Every person that gets voting rights may have fulfilled the conditions above.
When it qualifies for the above conditions, it can apply for the
voting karma. The people with the voting rights can recognize its
efforts and contributions for the language and finally allow a voting
karma. The karma will be rewarded with a simple majority after a vote.
The conditions that I have suggested above assess following:
- The person is well aware of PHP and its built system.
- The person is able to resolve bugs, add new features and improve
existing ones. - The person well understands PHP's nature and is able to form the
ideas accordingly.
Tobias's scale of qualification will motivate a large number of people
to ask for the voting rights, and they have the equal right to get the
right to vote. It doesn't matter a core developer maintains n number
of libraries. The thing that matters is the understandability of the
core. If one is able to contribute to the language and its efforts are
visible to the core developers and the community, it may have a voting
right. Yes, having developed numerous libraries can be an edge. Nobody
will object because one receives a karma according to a set policy.
Additionally, when there emerges a policy, it will motivate people to
partake in the discussions, practice their hands on the PHP core and
leverage the company of senior developers. Power to you all.
Best
Den man. 19. jul. 2021 kl. 13.14 skrev Lynn kjarli@gmail.com:
Currently there are people with voting permissions that do vote, yet do
not interact with RFCs or the mailing list. Regardless of the reasons one
may have for wanting to vote, the requirements given should be applied
equally if this is the argument.If this is a problem, then why has the voting RFC not been amended to
require such commentary? That seems like a productive first step in
solving the issue instead of complaining about it not happening
automaticallyYes, and I love it when I see new users interact with the mailing list,
even when in the end the questions or arguments changed nothing to the
RFC. It shows that people are probably invested. How do you measure
investment behind the scenes though? How often has someone decided to not
post anything on the mailing list because after testing a bunch of changes
proposed, it worked and required no comment?How can I take that into consideration if no one lets me know about
that? This argument sounds more to me like an illusion, I cannot read
minds nor am I into experimentation on the matter, I cannot consider
what I do not know (similarly to the problem you pointed out above).Would every user that one day would want to have voting rights post a "yes
I agree" message in every thread in order to show they contribute in
discussions?That is not what I was implying and I am certain you know that. I
specifically mean the discussions, not the voting itself. Taking
Tobias here as an example, why is there no feedback from him on the
RFCs like[1][2][3] (which was recent as in 8.1, this is just a list
from a quick glance which may or not be accurate), they seem to me
like an good way he could have given feedback based on the work he put
forward that he had been involved with.Why is it that political power should just be given without actually
taking part of the project and problems here at the PHP project? To me
that comes off as laziness. "I just want to vote, but take no
responsibility of maintaining the PHP project"[1] https://wiki.php.net/rfc/curl_user_agent
[2] https://wiki.php.net/rfc/fsync_function
[3] https://wiki.php.net/rfc/fibers--
regards,Kalle Sommer Nielsen
kalle@php.net--
To unsubscribe, visit: https://www.php.net/unsub.php
On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm tobias.nyholm@gmail.com
wrote:
Hey.
I would like to get karma to be able to vote on RFCs. I understand that
voting karma isn’t usually given out to people who write their first
mailing list entry.But I do believe I qualify as “Lead developers of PHP based projects
(frameworks, cms, tools, etc.)”For those of you who don’t know me, I’ve been working with open source PHP
projects since 2015. I am part of Symfony core team, I wrote PSR-18 and was
part of the working group for PSR-17. I also maintain Guzzle,
webmozart/assert, Flysystem, HTTPlug and the php-http ecosystem and about
50 other packages with more than 100.000 monthly downloads.I think I am the most downloaded PHP maintainer.
I have been following the RFCs more closely the past 2 years and I’ve
finally gathered some courage to ask for karma. There has not been many
(maybe just one or two) RFCs where I wished the vote turned out the other
way. So, I don’t think I would have any radical opinions about future RFCs.If I’ve understad the process correctly, I do need someone with a php.net
VCS account to sponsor me.My username is: nyholm
Regards
Tobias Nyholm
Hey Tobias,
My response here is basically the same as the last time the topic came up:
https://externals.io/message/110936#110937 Voting is just the very last
step of the RFC process, at which point the proposal can no longer be
influenced. If you have feedback about a proposal based on your extensive
experience in PHP's open source ecosystem, then the discussion phase is the
time to provide it, while it can still influence the proposal, as well as
other people's view of the proposal.
At least in my personal opinion, I think it's important that people granted
voting rights as community representatives have at least some historical
involvement in RFC discussions.
Regards,
Nikita
On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm tobias.nyholm@gmail.com
wrote:Hey.
I would like to get karma to be able to vote on RFCs. I understand that
voting karma isn’t usually given out to people who write their first
mailing list entry.But I do believe I qualify as “Lead developers of PHP based projects
(frameworks, cms, tools, etc.)”Hey Tobias,
My response here is basically the same as the last time the topic came up:
https://externals.io/message/110936#110937 Voting is just the very last
step of the RFC process, at which point the proposal can no longer be
influenced. If you have feedback about a proposal based on your extensive
experience in PHP's open source ecosystem, then the discussion phase is the
time to provide it, while it can still influence the proposal, as well as
other people's view of the proposal.
I second this.
At least in my personal opinion, I think it's important that people granted
voting rights as community representatives have at least some historical
involvement in RFC discussions.
I agree with this, but have no specific objection to granting Tobias
voting karma, as this is underspecified; how long should they
participate? What kinds of involvement are appropriate? Being
underspecified is not really their fault, and I don't feel like it
would be an abuse to grant them voting karma, but do think it would be
an abuse to deny them voting karma indefinitely because "we" don't get
around to specifying it. It should be less of a decision on a
case-by-case basis and more of a checklist.
Hey All
Am 19.07.21 um 16:34 schrieb Levi Morrison via internals:
On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm tobias.nyholm@gmail.com
wrote:Hey.
I would like to get karma to be able to vote on RFCs. I understand that
voting karma isn’t usually given out to people who write their first
mailing list entry.But I do believe I qualify as “Lead developers of PHP based projects
(frameworks, cms, tools, etc.)”Hey Tobias,
My response here is basically the same as the last time the topic came up:
https://externals.io/message/110936#110937 Voting is just the very last
step of the RFC process, at which point the proposal can no longer be
influenced. If you have feedback about a proposal based on your extensive
experience in PHP's open source ecosystem, then the discussion phase is the
time to provide it, while it can still influence the proposal, as well as
other people's view of the proposal.I second this.
At least in my personal opinion, I think it's important that people granted
voting rights as community representatives have at least some historical
involvement in RFC discussions.I agree with this, but have no specific objection to granting Tobias
voting karma, as this is underspecified; how long should they
participate? What kinds of involvement are appropriate? Being
underspecified is not really their fault, and I don't feel like it
would be an abuse to grant them voting karma, but do think it would be
an abuse to deny them voting karma indefinitely because "we" don't get
around to specifying it. It should be less of a decision on a
case-by-case basis and more of a checklist.
Sounds like we need an RFC to make it clearer how voting karma for the
RFC process will be granted in the future.
Looking forward to your inputs.
Cheers
Andreas
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
Sounds like we need an RFC to make it clearer how voting karma for the
RFC process will be granted in the future.
Yes, I agree. I would love to join that team, which is going to
prepare this RFC. Plus, I have shared some of the ideas in the
previous message.
Best
Hamza
Hey All
Am 19.07.21 um 16:34 schrieb Levi Morrison via internals:
On Mon, Jul 19, 2021 at 2:38 AM Nikita Popov nikita.ppv@gmail.com
wrote:On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm tobias.nyholm@gmail.com
wrote:Hey.
I would like to get karma to be able to vote on RFCs. I understand that
voting karma isn’t usually given out to people who write their first
mailing list entry.But I do believe I qualify as “Lead developers of PHP based projects
(frameworks, cms, tools, etc.)”Hey Tobias,
My response here is basically the same as the last time the topic came
up:
https://externals.io/message/110936#110937 Voting is just the very last
step of the RFC process, at which point the proposal can no longer be
influenced. If you have feedback about a proposal based on your
extensive
experience in PHP's open source ecosystem, then the discussion phase is
the
time to provide it, while it can still influence the proposal, as well
as
other people's view of the proposal.I second this.
At least in my personal opinion, I think it's important that people
granted
voting rights as community representatives have at least some historical
involvement in RFC discussions.I agree with this, but have no specific objection to granting Tobias
voting karma, as this is underspecified; how long should they
participate? What kinds of involvement are appropriate? Being
underspecified is not really their fault, and I don't feel like it
would be an abuse to grant them voting karma, but do think it would be
an abuse to deny them voting karma indefinitely because "we" don't get
around to specifying it. It should be less of a decision on a
case-by-case basis and more of a checklist.Sounds like we need an RFC to make it clearer how voting karma for the
RFC process will be granted in the future.Looking forward to your inputs.
Cheers
Andreas
,,, (o o)+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
Hey All
Am 19.07.21 um 17:02 schrieb Andreas Heigl:
Hey All
Am 19.07.21 um 16:34 schrieb Levi Morrison via internals:
On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm tobias.nyholm@gmail.com
wrote:Hey.
I would like to get karma to be able to vote on RFCs. I understand that
voting karma isn’t usually given out to people who write their first
mailing list entry.But I do believe I qualify as “Lead developers of PHP based projects
(frameworks, cms, tools, etc.)”Hey Tobias,
My response here is basically the same as the last time the topic came up:
https://externals.io/message/110936#110937 Voting is just the very last
step of the RFC process, at which point the proposal can no longer be
influenced. If you have feedback about a proposal based on your extensive
experience in PHP's open source ecosystem, then the discussion phase is the
time to provide it, while it can still influence the proposal, as well as
other people's view of the proposal.I second this.
At least in my personal opinion, I think it's important that people granted
voting rights as community representatives have at least some historical
involvement in RFC discussions.I agree with this, but have no specific objection to granting Tobias
voting karma, as this is underspecified; how long should they
participate? What kinds of involvement are appropriate? Being
underspecified is not really their fault, and I don't feel like it
would be an abuse to grant them voting karma, but do think it would be
an abuse to deny them voting karma indefinitely because "we" don't get
around to specifying it. It should be less of a decision on a
case-by-case basis and more of a checklist.Sounds like we need an RFC to make it clearer how voting karma for the
RFC process will be granted in the future.
I have created a draft for an RFC to implement future rules for granting
voting karma.
If you want to contribute to that, feel free to open a PR against it[1].
To be able to make the future karma grants more trnasparent this needs
input from everyone: Opponoents as well as proponents!
I'm looking forward to a fruitful conversation and to a great RFC that
can move us to more transparency.
Cheers
Andreas
[1]
https://github.com/heiglandreas/rfc/blob/main/implement_future_rules_for_granting_voting_karma.md
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
Hey All
Am 19.07.21 um 17:02 schrieb Andreas Heigl:
Hey All
Am 19.07.21 um 16:34 schrieb Levi Morrison via internals:
On Mon, Jul 19, 2021 at 2:38 AM Nikita Popov nikita.ppv@gmail.com
wrote:On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm <tobias.nyholm@gmail.com
wrote:
Hey.
I would like to get karma to be able to vote on RFCs. I understand
that
voting karma isn’t usually given out to people who write their first
mailing list entry.But I do believe I qualify as “Lead developers of PHP based projects
(frameworks, cms, tools, etc.)”Hey Tobias,
My response here is basically the same as the last time the topic came
up:
https://externals.io/message/110936#110937 Voting is just the very
last
step of the RFC process, at which point the proposal can no longer be
influenced. If you have feedback about a proposal based on your
extensive
experience in PHP's open source ecosystem, then the discussion phase
is the
time to provide it, while it can still influence the proposal, as well
as
other people's view of the proposal.I second this.
At least in my personal opinion, I think it's important that people
granted
voting rights as community representatives have at least some
historical
involvement in RFC discussions.I agree with this, but have no specific objection to granting Tobias
voting karma, as this is underspecified; how long should they
participate? What kinds of involvement are appropriate? Being
underspecified is not really their fault, and I don't feel like it
would be an abuse to grant them voting karma, but do think it would be
an abuse to deny them voting karma indefinitely because "we" don't get
around to specifying it. It should be less of a decision on a
case-by-case basis and more of a checklist.Sounds like we need an RFC to make it clearer how voting karma for the
RFC process will be granted in the future.I have created a draft for an RFC to implement future rules for granting
voting karma.If you want to contribute to that, feel free to open a PR against it[1].
To be able to make the future karma grants more trnasparent this needs
input from everyone: Opponoents as well as proponents!I'm looking forward to a fruitful conversation and to a great RFC that
can move us to more transparency.Cheers
Andreas
[1]
https://github.com/heiglandreas/rfc/blob/main/implement_future_rules_for_granting_voting_karma.md
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
As someone who only subscribed to internals a week ago, I hope you take my
feedback with a grain of salt Andreas, but as this discussion has showed,
this is the part of the process that my input might be valuable in.
The requester should search a proponent of their case that then proposes
the request for voting karma to the dedicated discussion medium for such
requests. The proposal should include the reasons why the proponent thinks
the requester fullfills the above stated requirements.
This makes sense for a variety of reasons. The first and most concrete
being that verifying the credentials and history of every person who
applies for karma could be restrictively time consuming if it were done in
a totally open format. However, my first thought on reading this was "if I
was still just an observer in internals and asking for voting karma, I
would feel a little strange about emailing someone off the list directly
and about figuring out who to message that way". Perhaps this could be
paired with like... not a mentor program, but sort of a list of people on
the list who are willing to field such requests?
After this request there will be a two week period in which objections
and approvals will be brought in. When there are more approvals than
objections the voting karma will be granted.
This should be clarified. I think you intended something to the effect of "
After this request there will be a two week period in which objections and
approvals will be brought in. Once this period is over, if there are more
approvals than objections the voting karma will be granted."
The original phrasing makes it ambiguous as to whether or not the entire
two weeks must pass for every such case, and also seems to suggest that
someone could be granted karma with a vote of 1-0, since there would be
more approvals than objections.
Another aspect that I thought about after reading your draft was a way to
structurally avoid concerns about stacking. I don't believe that there
would necessarily be overt efforts to grant karma to individuals to push
certain concerns to the side, however it might be worth considering if the
process could promote a variety of opinions and backgrounds. Even if such a
situation were considered unlikely, it could be worth writing such a
process with that in mind if the process involves a sponsor.
As I said earlier, it makes sense for many reasons to require a sponsor to
get voting karma, however this may unnecessarily make the applicant
associated with their sponsor or their sponsor's history and contributions
(which could be a positive or negative to one person or the other). It also
makes it less likely that a perspective which is totally unrepresented gets
sponsored. This could also be a positive thing, as not all perspectives are
truly relevant or constructive to all the processes. But it might be worth
considering these impacts explicitly.
It's also worth considering if people believe that this is a process that
will be iterated on or if there is a desire to get it right the first time
and stick with it. Perhaps if the intent is to iterate, or at least
explicitly revisit the criteria, the RFC could include an expiration at
which time a vote to either keep or change the process could be held, which
gives everyone clarity and certainty about the structure over a given
period.
Those are my immediate thoughts on your rough draft.
Jordan
Hey Jordan, Hey All.
Am 20.07.21 um 10:07 schrieb Jordan LeDoux:
Another aspect that I thought about after reading your draft was a way to
structurally avoid concerns about stacking. I don't believe that there
would necessarily be overt efforts to grant karma to individuals to push
certain concerns to the side, however it might be worth considering if the
process could promote a variety of opinions and backgrounds. Even if such a
situation were considered unlikely, it could be worth writing such a
process with that in mind if the process involves a sponsor.As I said earlier, it makes sense for many reasons to require a sponsor to
get voting karma, however this may unnecessarily make the applicant
associated with their sponsor or their sponsor's history and contributions
(which could be a positive or negative to one person or the other). It also
makes it less likely that a perspective which is totally unrepresented gets
sponsored. This could also be a positive thing, as not all perspectives are
truly relevant or constructive to all the processes. But it might be worth
considering these impacts explicitly.It's also worth considering if people believe that this is a process that
will be iterated on or if there is a desire to get it right the first time
and stick with it. Perhaps if the intent is to iterate, or at least
explicitly revisit the criteria, the RFC could include an expiration at
which time a vote to either keep or change the process could be held, which
gives everyone clarity and certainty about the structure over a given
period.Those are my immediate thoughts on your rough draft.
I've incorporated the changes into a PR
https://github.com/heiglandreas/rfc/pull/1/files and also added these
concerns to the PR description.
Either I'll see to it to incorporate them or if someone else wants to
create a PR to discuss those concerns I'd be happy as well.
Cheers
Andreas
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
Quoting the RFC
the requester has contributed to the PHP sourcecode ecosystem.
You mention what types of contributions apply, but give no indication of quantity. If someone fixes one bug, does that give them voting rights? I would assume not. So is it two bugs, 10 bugs, 100?
these contributions show a consistent effort
How is "consistent" defined? How frequently and for what minimum time period?
the requester has shown interaction with the main discussion medium of the relevant part
This is unclear to me. I assume "the main discussion medium" is more than just the mailing list, otherwise you would have said the mailing list, right?
And what does "relevant part" mean? Maybe some examples would help, at least in reply.
the requester has a proponent that currently has voting karma
Agreeing with Jordan LeDoux, these seems primed to make current voting members a target for wanna-be voters.
Maybe this could discuss processes that would naturally bring people to want to sponsor someone, such as (maybe?) recommending they first "apprentice" under one or more people by helping document, helping fix bugs, or working with them on an RFC?
The requester should search a proponent of their case that then proposes the request for voting karma to the dedicated discussion medium for such requests. The proposal should include the reasons why the proponent thinks the requester fullfills the above stated requirements.
Are you really suggesting that allowing someone new to vote would be held out in the open, where the discussions about that person will get recorded on externals.io http://externals.io/ and indexed by Google for all to see, forevermore?
Seems like discussion about an individual should respect the long term privacy of the individual a bit more, especially for those who will be turned down.
When there are more approvals than objections the voting karma will be granted.
How is voting to be done? Yay's and nay's on a mailing list? Or some other way?
And voting right can be approved with 51% whereas most RFCs require 67% to pass?
I ask these questions so people who might be interested in getting voting rights would have an objective roadmap for how to get there otherwise it would seem to just be documenting an extremely subjective process. (Which might be all you are attempting to do?)
Anyway, #jmtcw.
-Mike
Hey All
Am 19.07.21 um 17:02 schrieb Andreas Heigl:
Hey All
Am 19.07.21 um 16:34 schrieb Levi Morrison via internals:
On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm tobias.nyholm@gmail.com
wrote:Hey.
I would like to get karma to be able to vote on RFCs. I understand that
voting karma isn’t usually given out to people who write their first
mailing list entry.But I do believe I qualify as “Lead developers of PHP based projects
(frameworks, cms, tools, etc.)”Hey Tobias,
My response here is basically the same as the last time the topic came up:
https://externals.io/message/110936#110937 Voting is just the very last
step of the RFC process, at which point the proposal can no longer be
influenced. If you have feedback about a proposal based on your extensive
experience in PHP's open source ecosystem, then the discussion phase is the
time to provide it, while it can still influence the proposal, as well as
other people's view of the proposal.I second this.
At least in my personal opinion, I think it's important that people granted
voting rights as community representatives have at least some historical
involvement in RFC discussions.I agree with this, but have no specific objection to granting Tobias
voting karma, as this is underspecified; how long should they
participate? What kinds of involvement are appropriate? Being
underspecified is not really their fault, and I don't feel like it
would be an abuse to grant them voting karma, but do think it would be
an abuse to deny them voting karma indefinitely because "we" don't get
around to specifying it. It should be less of a decision on a
case-by-case basis and more of a checklist.Sounds like we need an RFC to make it clearer how voting karma for the
RFC process will be granted in the future.I have created a draft for an RFC to implement future rules for granting
voting karma.If you want to contribute to that, feel free to open a PR against it[1].
To be able to make the future karma grants more trnasparent this needs
input from everyone: Opponoents as well as proponents!I'm looking forward to a fruitful conversation and to a great RFC that
can move us to more transparency.Cheers
Andreas
[1]
https://github.com/heiglandreas/rfc/blob/main/implement_future_rules_for_granting_voting_karma.md--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
Hey Mike
Thank you for your feedback!
Am 20.07.21 um 11:57 schrieb Mike Schinkel:
Quoting the RFC
the requester has contributed to the PHP sourcecode ecosystem.
You mention what types of contributions apply, but give no indication of quantity. If someone fixes one bug, does that give them voting rights? I would assume not. So is it two bugs, 10 bugs, 100?
As the RFC is still not finished especially in terms of wording that is
something that definitely needs some improvements. I tried to leave it
as open as possible in the initial draft to have that as basis for
further discussions. What do you think would be an appropriate number?
these contributions show a consistent effort
How is "consistent" defined? How frequently and for what minimum time period?
This is the same "blurriness" as above due to the same reasons. Any
suggestions for a better wording? For me consistent means that someone
keeps at something for the duration of that process. So not like giving
a comment to a bug report and off but instead continuously monitoring
the bug, answering comments, triaging the bug, looking to find someone
to fix it, writing tests for it etc. But yes, that is not described in
the RFC and that'S just my personal take. Being explicit definitely is
better there.
Though perhaps we should not become too explicit and still allow a
certain amount of interpretation.
the requester has shown interaction with the main discussion medium of the relevant part
This is unclear to me. I assume "the main discussion medium" is more than just the mailing list, otherwise you would have said the mailing list, right?
The "main discussion medium" is currently the Mailinglist. As I have no
idea of when this RFC will be ready for voting I kept it that vague to
not have to rewrite everything should for whatever reason the mailing
list be replaced with something else. For some things the mailing-list
has already been replaced with the PR-Comments
And what does "relevant part" mean? Maybe some examples would help, at least in reply.
See above ;-)
the requester has a proponent that currently has voting karma
Agreeing with Jordan LeDoux, these seems primed to make current voting members a target for wanna-be voters.
Maybe this could discuss processes that would naturally bring people to want to sponsor someone, such as (maybe?) recommending they first "apprentice" under one or more people by helping document, helping fix bugs, or working with them on an RFC?
My main idea was to limit the number of emails to the mailinglist by
requesting them to come from someone already with voting karma so that
there is a slight barrier of entrance. And during the preparation
process for the voting karma someone would hopefully not work in an
empty space but have contacts to other people with voting karma. So that
they can guide the person through the process. And as the process
requires someone to have interacted with the system beforehand that
should not lead to too many wanna-be voters out of the blue
The requester should search a proponent of their case that then proposes the request for voting karma to the dedicated discussion medium for such requests. The proposal should include the reasons why the proponent thinks the requester fullfills the above stated requirements.
Are you really suggesting that allowing someone new to vote would be held out in the open, where the discussions about that person will get recorded on externals.io http://externals.io/ and indexed by Google for all to see, forevermore?
Seems like discussion about an individual should respect the long term privacy of the individual a bit more, especially for those who will be turned down.
Thanks! I actually hadn't thought about that! Any suggestions on how to
improve that?
When there are more approvals than objections the voting karma will be granted.
How is voting to be done? Yay's and nay's on a mailing list? Or some other way?
Someone else suggested to have a similar voting widget like we have for
the RFCs as that would ease the whole thing considerably. I'll add that
suggestion to the Draft.
And voting right can be approved with 51% whereas most RFCs require 67% to pass?
Only RFCs that change the language need 2/3rd majority. ANd the RFC we
are talking here would need that. But you are right. When the poll is
that close that means there are a lot of objections against that person
(whyever) so we might think about that. On the other hand that would
mean that we might miss valuable input from people that contribute to
the PHP-System...
I ask these questions so people who might be interested in getting voting rights would have an objective roadmap for how to get there otherwise it would seem to just be documenting an extremely subjective process. (Which might be all you are attempting to do?)
I'm trying to create exactly that: An objective roadmap what to do to
get voting rights.
What I did not yet get into is the question what to do when someone did
a lot of effort to get voting rights and right after that stops all efforts.
Perhaps we should add a passage to the RFC regarding that as well.
Thanks though for your input!
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
Hey Mike
Thank you for your feedback!
Am 20.07.21 um 11:57 schrieb Mike Schinkel:
Quoting the RFC
the requester has contributed to the PHP sourcecode ecosystem.
You mention what types of contributions apply, but give no indication of quantity. If someone fixes one bug, does that give them voting rights? I would assume not. So is it two bugs, 10 bugs, 100?
As the RFC is still not finished especially in terms of wording that is
something that definitely needs some improvements. I tried to leave it
as open as possible in the initial draft to have that as basis for
further discussions. What do you think would be an appropriate number?
As I don't have voting rights, I don't think I am in an empowered position to make specific suggestions.
If I were going to design the PHP's governance I would design differently, but since I'm not in a role to do that I can only accept that PHP governance is the way that it is, and point out things I think might be problematic.
As for specific suggestions? I'll let others who already have a vote specify those.
-Mike
Hey Mike
Am 20.07.21 um 15:11 schrieb Mike Schinkel:
Hey Mike
Thank you for your feedback!
Am 20.07.21 um 11:57 schrieb Mike Schinkel:
Quoting the RFC
the requester has contributed to the PHP sourcecode ecosystem.
You mention what types of contributions apply, but give no indication of quantity. If someone fixes one bug, does that give them voting rights? I would assume not. So is it two bugs, 10 bugs, 100?
As the RFC is still not finished especially in terms of wording that is
something that definitely needs some improvements. I tried to leave it
as open as possible in the initial draft to have that as basis for
further discussions. What do you think would be an appropriate number?As I don't have voting rights, I don't think I am in an empowered position to make specific suggestions.
That's got nothing to do with empowerment. You raised the issue so what
would you think is an adequate number? ;-)
Whether that will be something that internals will find appropriate is a
different story, but having a base for discussion is always helpful.
If I were going to design the PHP's governance I would design differently, but since I'm not in a role to do that I can only accept that PHP governance is the way that it is, and point out things I think might be problematic. >
As for specific suggestions? I'll let others who already have a vote specify those.
If we leave the specs only to those with voting rights then nothing
might change as they have a fair share of work already. So proposing
something to them that they can then use as a base for discussion is
always easier than pushing others to come up with something ;-)
Cheers
Andreas
-Mike
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
the requester has contributed to the PHP sourcecode ecosystem. That
can be (but is not limited to):
Contributions to the PHP-Sources
Contributions to the Documentation or the Translation
Triage, solve or otherwise interact with bugs
Voter would need an easy way to verify that information. Otherwise we'll
be facing "-1, because I can't verify or have no time to do it" votes.
Help in the maintenance of the PHP Infrastructure
This has nothing to do with PHP language, and it cannot be verified by
anyone. I suggest to remove this point.
I think the voting would need to be in a form we're using for RFCs,
counting votes on mailing list will be error-prone and time-consuming
(you don't know who's a voter).
--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
I am not going to critique the RFC; rather, I say that this RFC needs
a fresh rewrite because I find more like it a set of instructions. The
proposal needs to be a detailed one. It seams as if it is written
hastily.
As Tobias has mentioned that he has been reading the RFCs for years,
there is a large number of people that do the same. After this
discussion has been started, people are closely observing the dialog
and waiting for their chance to become a voter.
Thus, there needs a clear framework that will lay a foundation for the
future of PHP. There are a lot of voters out there, but you will
hardly see 60 or 70 voters participating in the process. There needs
to be a system that provides others obtain the right to vote and
contribute to the language. Here, Tobias is not a single instance. I
honor him and also respect the other community members that want to
vote for the features. Many feature requests were declined just
because 25 to 30 people had disliked them.
Meanwhile, nobody wants a rush. Thus, the policy should be flexible
enough that it incorporates the great talent. It should not be that
strict that nobody ever tries to partake in the process, nor that
flexible that somebody establishes its feed and one day hack the
source. We have seen how hackers tried to use Nikita's name for their
own purpose. Why cannot a hackers group try to join the team?
To avoid such incidents. One should not get merging rights after
getting voting rites. Rather, it should be a separate process. Also,
it should be cleared, so the language development is successfully
passed on to the next gen. I have another idea that can initially
allow Tobias and other community members participate in the process.
What about 80 20 system? 80 percent vote will come from the current
voters and 20 percent from the community.
Best
Hamza
the requester has contributed to the PHP sourcecode ecosystem. That
can be (but is not limited to):
Contributions to the PHP-Sources
Contributions to the Documentation or the Translation
Triage, solve or otherwise interact with bugsVoter would need an easy way to verify that information. Otherwise we'll
be facing "-1, because I can't verify or have no time to do it" votes.Help in the maintenance of the PHP Infrastructure
This has nothing to do with PHP language, and it cannot be verified by
anyone. I suggest to remove this point.I think the voting would need to be in a form we're using for RFCs,
counting votes on mailing list will be error-prone and time-consuming
(you don't know who's a voter).--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
--
To unsubscribe, visit: https://www.php.net/unsub.php
Hey Hamza
Am 20.07.21 um 13:12 schrieb Hamza Ahmad:
I am not going to critique the RFC; rather, I say that this RFC needs
a fresh rewrite because I find more like it a set of instructions. The
proposal needs to be a detailed one. It seams as if it is written
hastily.
As noted in the original Email to the list, the RFC is a draft that was
explicitly put onto github (and not into the PHP-Wiki) to allow working
on it before putting it up on the PHP-Wiki for the discussion phase that
is required for an RFC.
Yes: You are right! The RFC was written hastily! It was mainly written
hastily to have something as base for discussions so that we have
something that we can then together improve over multiple iterations
to make a great RFC out of it that will
a) provide a consistent way for gaining voting karma and
b) has a chance to be accepted when it comes to voting for or against
this RFC.
So the intention of this RFC is not to be the only relevant solution to
a problem we might probably not even have. On the contrary: The
intention is to provide something that everyone interested can improve
to something great.
So your input is more than welcome. Especially your input in form of a
PR to improve the current version! And of course also your input in form
of discussion contributions on that text.
What this RFC will for sure not modify is the infrastructure. We have
a certain infrastructure at the moment and changing that will take much
more than an RFC. So this RFC also has to take that as a given and has
to work around this. As great as some changes would be: we can not take
them for grantend in the course of this RFC.
So looking forward to your PR.
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
Hey All
Am 19.07.21 um 17:02 schrieb Andreas Heigl:
Hey All
Am 19.07.21 um 16:34 schrieb Levi Morrison via internals:
On Mon, Jul 19, 2021 at 2:38 AM Nikita Popov nikita.ppv@gmail.com
wrote:On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm <tobias.nyholm@gmail.com
wrote:
Hey.
I would like to get karma to be able to vote on RFCs. I understand
that
voting karma isn’t usually given out to people who write their first
mailing list entry.But I do believe I qualify as “Lead developers of PHP based projects
(frameworks, cms, tools, etc.)”Hey Tobias,
My response here is basically the same as the last time the topic came
up:
https://externals.io/message/110936#110937 Voting is just the very
last
step of the RFC process, at which point the proposal can no longer be
influenced. If you have feedback about a proposal based on your
extensive
experience in PHP's open source ecosystem, then the discussion phase
is the
time to provide it, while it can still influence the proposal, as well
as
other people's view of the proposal.I second this.
At least in my personal opinion, I think it's important that people
granted
voting rights as community representatives have at least some
historical
involvement in RFC discussions.I agree with this, but have no specific objection to granting Tobias
voting karma, as this is underspecified; how long should they
participate? What kinds of involvement are appropriate? Being
underspecified is not really their fault, and I don't feel like it
would be an abuse to grant them voting karma, but do think it would be
an abuse to deny them voting karma indefinitely because "we" don't get
around to specifying it. It should be less of a decision on a
case-by-case basis and more of a checklist.Sounds like we need an RFC to make it clearer how voting karma for the
RFC process will be granted in the future.I have created a draft for an RFC to implement future rules for granting
voting karma.If you want to contribute to that, feel free to open a PR against it[1].
To be able to make the future karma grants more trnasparent this needs
input from everyone: Opponoents as well as proponents!I'm looking forward to a fruitful conversation and to a great RFC that
can move us to more transparency.Cheers
Andreas
[1]
https://github.com/heiglandreas/rfc/blob/main/implement_future_rules_for_granting_voting_karma.md
Here is the problem (and I don't know if there is a good solution to this)
- the requirements are still subjective. How much interaction is required
with the PHP sourcecode ecosystem? What is considered a "consistent
effort?" How much interaction with the "main discussions medium" is needed?
If we are going to change how karma is given, I think we really need to
determine solid, objective criteria. I honestly don't know what this looks
like. Everything I can think of has issues. For example, if we decided to
allow a path for non-core contributors to gain karma, what would we base
that on? Anything around the number of commits, projects worked on, etc.,
can be easily gamed. Allowing those that already have voting karma the
final decision over who gets voting karma is also problematic. Like Tobias,
I have gotten the "elitist" feeling at times from the group.
Finally, I think the idea of "approvals outweighing objections" is not
good. While it definitely is a purely objective measurement, it shows why I
think it is so hard (if not impossible) to find good measurements that are
purely objective. What if we get one objection that rightly says "This
person shows that they have no knowledge of how PHP actually works"
compared to two approvals saying "I like this person, so I'm OK with it"
--
Chase Peeler
chasepeeler@gmail.com
Thank you all for your input.
I understand that I should be more active on the mailing list to get some
history. I think that is reasonable, but I don’t see why that is important.
I’m not applying based on my C skills, knowledge of processes or my
previous technical arguments. So, I can only assume that you want me to
have history because you want to get to know me better in this forum. Which
means that if I show a pattern to disagree with you (in the general sense),
that would decrease my chances to be granted voting rights.
I’m sure that is not what you mean, but that is what’s implied.
@Kalle, I’ve not been active on those RFCs simply because I either agree or
don’t care. I know it is a poor answer from me, but it is an honest answer.
I do find that some of you are making the argument that having voting
access is like being in the “elite” and there should not be too many people
in the elite. I guess it depends on your personality if you choose to see
it that way.
I also saw suggestions that one has to be a good core developer to be able
to influence PHP. I find it particularly strange if it would be a
requirement. Being a frequent and valuable contributor to PHP core would
bring one perspective to the votes. Spending 5.000/hours yearly on
programming PHP would bring you another perspective. The group of people
with voting access currently have both perspectives which I think is a good
thing.
This thread got way more answers and perspectives than I could imagine. I
do agree with @Andreas Heigl that it would be good with some clearer
processes on how to get and keep(!) voting karma.
I will be more public on the mailing lists and share my thoughts if I have
anything good to share. I’ll revisit this topic in 6-18 months and hope
that you all know me better then.
Regards,
Tobias
On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm tobias.nyholm@gmail.com
wrote:Hey.
I would like to get karma to be able to vote on RFCs. I understand that
voting karma isn’t usually given out to people who write their first
mailing list entry.But I do believe I qualify as “Lead developers of PHP based projects
(frameworks, cms, tools, etc.)”For those of you who don’t know me, I’ve been working with open source
PHP projects since 2015. I am part of Symfony core team, I wrote PSR-18 and
was part of the working group for PSR-17. I also maintain Guzzle,
webmozart/assert, Flysystem, HTTPlug and the php-http ecosystem and about
50 other packages with more than 100.000 monthly downloads.I think I am the most downloaded PHP maintainer.
I have been following the RFCs more closely the past 2 years and I’ve
finally gathered some courage to ask for karma. There has not been many
(maybe just one or two) RFCs where I wished the vote turned out the other
way. So, I don’t think I would have any radical opinions about future RFCs.If I’ve understad the process correctly, I do need someone with a php.net
VCS account to sponsor me.My username is: nyholm
Regards
Tobias NyholmHey Tobias,
My response here is basically the same as the last time the topic came up:
https://externals.io/message/110936#110937 Voting is just the very last
step of the RFC process, at which point the proposal can no longer be
influenced. If you have feedback about a proposal based on your extensive
experience in PHP's open source ecosystem, then the discussion phase is the
time to provide it, while it can still influence the proposal, as well as
other people's view of the proposal.At least in my personal opinion, I think it's important that people
granted voting rights as community representatives have at least some
historical involvement in RFC discussions.Regards,
Nikita
I also saw suggestions that one has to be a good core developer to be able
to influence PHP. I find it particularly strange if it would be a
requirement.
When decisions are just a matter of bikeshedding, or deciding what
"style" the language should have, there is a strong argument for general
democracy, and a strong voice for those who use the language.
But some decisions have more fundamental impact on the implementation
itself - highly technical features like JIT or Fibers, or conceptually
simple features with complex implementations like Intersection Types.
The concern is that the small number of people who understand those
consequences will be out-voted by people "voting with their heart"
because they like the idea of a feature.
Those core contributors are then expected to maintain the resulting
code, with little help from those who wanted the feature. Hence the
suggestion, not of an "elite", but of some sort of "meritocracy", where
that knowledge carries some weight.
Perhaps we need a more revolutionary re-organisation into two separate
voting groups:
- a very open community vote, to indicate a breadth of support for the
direction a change takes the language - a group of Core Contributors, much smaller than the current voting
pool, who are equipped to judge the impact of the implementation
An RFC could require separate approval from both groups, regardless of
number of voters, like a parliament with two chambers.
Obviously, this still leaves the question of how to gain a vote in
either "chamber", but it avoids the difficulty of coming up with a
definition that applies fairly to these very different groups of people.
Regards,
--
Rowan Tommins
[IMSoP]
When decisions are just a matter of bikeshedding, or deciding what "style" the language should have, there is a strong argument for general democracy, and a strong voice for those who use the language.
But some decisions have more fundamental impact on the implementation itself - highly technical features like JIT or Fibers, or conceptually simple features with complex implementations like Intersection Types. The concern is that the small number of people who understand those consequences will be out-voted by people "voting with their heart" because they like the idea of a feature.
Those core contributors are then expected to maintain the resulting code, with little help from those who wanted the feature. Hence the suggestion, not of an "elite", but of some sort of "meritocracy", where that knowledge carries some weight.
Perhaps we need a more revolutionary re-organisation into two separate voting groups:
- a very open community vote, to indicate a breadth of support for the direction a change takes the language
- a group of Core Contributors, much smaller than the current voting pool, who are equipped to judge the impact of the implementation
This is an excellent observation, and encapsulates why some of the RFC outcomes might feel a bit mismatched with what many people want and/or what seems to make the most sense for PHP from a core maintenance perspective.
An RFC could require separate approval from both groups, regardless of number of voters, like a parliament with two chambers.
But I'm not sure having two houses that can both veto a a solution would improve things. I think it would just make it worse.
If there was the Userland House and the Core Contributor Senate then that would mean that things in your category of bike-shedding could still be blocked by the Core Contributors even if 99% of userland developers loved an idea.
Instead maybe we should consider those known and respected because of their continuous core contributions ("Core Contributors") have the ability to veto an RFC if it treads into core territory?
BTW, "membership" in Core Contributors would be managed informally within the group of people. Once the initial group was recognized they would handle adding new people to the group and/or ejecting existing people completely among themselves and then one of them would announce any updates to the list.
Consider if Core Contributors are allowed to classify an RFC as a "Core-related" concern, such as 1.) a core maintenance concern and/or 2.) a future-compatibility concern? And if it is one of those two, then Core Contributors could request a veto vote. I think we could assume they would only do this in good faith because of the potential for damage to their reputations if they were to operate in bad faith.
When an RFC is being discussed a Core Contributor could simply stating their belief it is Core-related and if two other Core Contributors seconded that concern then the RFC would be susceptible to a potential veto vote and the RFC author would be required to mark it as such. Classifying as Core-related should happen during discussion period and before the vote starts, and especially not after a main vote has passed.
(However if it gets contentious then three (3) Core Contributors could band together and simply update the RFC to be Core-related; their view on this would be final. But I doubt that would ever be needed because an author arguing against Core Contributors in this way would mean the RFC would probably be voted down anyway.)
Then for voting:
-
If an RFC is not Core-related then everyone gets to vote just as before, but maybe voting access becomes more open and more democratic?
-
If an RFC is Core-related then the same vote occurs but if is passes then three (3) Core Contributors can request to have a Core Contributor-only vote which will require a 2/3rd majority to pass. If this vote fails to gain 2/3rd majority approval of the Core Contributors then the RFC is considered "Vetoed."
The benefits could potentially be:
-
Ensure even if a feature is desired by userland we could still guard against approving features that would be a maintenance problem or that could paint PHP into an evolutionary corner.
-
Lowering the bar for voting rights because voters couldn't do damage to core-related concerns.
-
Possibly gain more participation from userland
-
An increase in userland satisfaction from either being allowed to participate or for the broader community getting more features userland developers want.
-
Very little change procedurally, except to formally recognize the Core Contributors separately from others, and giving them the ability to call for a veto vote after an RFCs that were previously tagged as core-related passed.
BTW, rather than calling it "bikeshedding" we might characterize it more charitably as "style-based," where "style" refer to the realm of userland developer-experience.
What do you think?
Most specifically I would like to hear from those who know they would be in the category of Core Contributors who would get a veto they currently do not have on core-related concerns, but who would also potentially see their vote on opinion-based RFCs diluted.
-Mike
There has not been many (maybe just one or two) RFCs where I wished the
vote turned out the other way.
This was the reason that I did not think that I needed a vote, as a
prolific PHP coder — while individual voters might be voting the "wrong"
way, in the aggregate the decisions were all pretty good. While I think
it's important for me to share my opinion (because my opinion is, like, the
best opinion), I don't think that opinion needs to be able to vote.
You and I still have soft power — we can use our platform (many existing
voters follow both you and I on Twitter) to encourage people to vote yes on
an RFC we feel strongly about e.g.
https://twitter.com/psalmphp/status/1347163072587186178.
There are also lots of examples of non-voters influencing RFCs to make them
more acceptable to the wider PHP community:
https://twitter.com/brendt_gd/status/1335090303192195075
Best wishes,
Matt