Request for karma to vote on RFCs

  115464
July 18, 2021 18:47 tobias.nyholm@gmail.com (Tobias Nyholm)
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
  115465
July 18, 2021 20:46 kalle@php.net (Kalle Sommer Nielsen)
Hi

Den søn. 18. jul. 2021 kl. 21.47 skrev Tobias Nyholm 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
  115468
July 19, 2021 03:28 tobias.nyholm@gmail.com (Tobias Nyholm)
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
  115471
July 19, 2021 05:32 smalyshev@gmail.com (Stanislav Malyshev)
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
  115485
July 19, 2021 10:27 benjamin.morel@gmail.com (Benjamin Morel)
> > 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
  115475
July 19, 2021 07:41 pierre-php@processus.org (Pierre)
Le 18/07/2021 à 22:46, Kalle Sommer Nielsen a écrit :
> Hi > > Den søn. 18. jul. 2021 kl. 21.47 skrev Tobias Nyholm 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
  115476
July 19, 2021 08:11 kjarli@gmail.com (Lynn)
On Mon, Jul 19, 2021 at 9:41 AM Pierre <pierre-php@processus.org> wrote:

> - 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.
  115477
July 19, 2021 08:33 pierre-php@processus.org (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. 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
  115481
July 19, 2021 09:11 kjarli@gmail.com (Lynn)
On Mon, Jul 19, 2021 at 10:33 AM Pierre <pierre-php@processus.org> wrote:

> 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.
  115483
July 19, 2021 09:47 kalle@php.net (Kalle Sommer Nielsen)
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
  115484
July 19, 2021 10:14 kjarli@gmail.com (Lynn)
On Mon, Jul 19, 2021 at 11:47 AM Kalle Sommer Nielsen <kalle@php.net> wrote:

> 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.
  115486
July 19, 2021 10:33 kalle@php.net (Kalle Sommer Nielsen)
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
  115489
July 19, 2021 13:44 office.hamzaahmad@gmail.com (Hamza Ahmad)
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:
1. The person may have RFC karma already.
2. After obtaining an RFC karma, it may have been active on the
mailing list for a specific time period.
3. It may have n number of bugs solved and merged.
4. It may have worked with senior developers of php at least on the n
number of RFCs.
5. Optionally, it may have some of his own RFCs approved or rejected
with minimum percentage.
6. 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:
1. The person is well aware of PHP and its built system.
2. The person is able to resolve bugs, add new features and improve
existing ones.
3. 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


On 7/19/21, Kalle Sommer Nielsen <kalle@php.net> wrote:
> 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  115478
July 19, 2021 08:37 nikita.ppv@gmail.com (Nikita Popov)
On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm 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
  115496
July 19, 2021 14:34 internals@lists.php.net ("Levi Morrison via internals")
On Mon, Jul 19, 2021 at 2:38 AM Nikita Popov ppv@gmail.com> wrote:
> > On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm 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.
  115497
July 19, 2021 15:02 Andreas Heigl <andreas@heigl.org>
--aNuDauoOeBe2kOLBKyAmfH9JT4t5DqMKC
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

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 ppv@gmail.com> wro= te:
>> >> On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm nyholm@gmail.com= > >> wrote: >> >>> Hey. >>> I would like to get karma to be able to vote on RFCs. I understand th= at
>>> voting karma isn=E2=80=99t usually given out to people who write thei= r first
>>> mailing list entry. >>> >>> But I do believe I qualify as =E2=80=9CLead developers of PHP based p= rojects
>>> (frameworks, cms, tools, etc.)=E2=80=9D >> >> 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 las= t
>> 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 extens= ive
>> experience in PHP's open source ecosystem, then the discussion phase i= s the
>> time to provide it, while it can still influence the proposal, as well= as
>> other people's view of the proposal. >=20 > I second this. >=20 >> At least in my personal opinion, I think it's important that people gr= anted
>> voting rights as community representatives have at least some historic= al
>> involvement in RFC discussions. >=20 > 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. >=20
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 --=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ --aNuDauoOeBe2kOLBKyAmfH9JT4t5DqMKC--
  115506
July 20, 2021 05:37 office.hamzaahmad@gmail.com (Hamza Ahmad)
> 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 On 7/19/21, Andreas Heigl <andreas@heigl.org> wrote:
> 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 ppv@gmail.com> >> wrote: >>> >>> On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm 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 | > +---------------------------------------------------------------------+ > >
  115508
July 20, 2021 06:22 Andreas Heigl <andreas@heigl.org>
--lP33ItGRDEvdIM29sbn7GLrFSpMZxLDgK
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Hey All

Am 19.07.21 um 17:02 schrieb Andreas Heigl:
> Hey All >=20 > Am 19.07.21 um 16:34 schrieb Levi Morrison via internals: >> On Mon, Jul 19, 2021 at 2:38 AM Nikita Popov ppv@gmail.com> wr= ote:
>>> >>> On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm nyholm@gmail.co= m>
>>> wrote: >>> >>>> Hey. >>>> I would like to get karma to be able to vote on RFCs. I understand t= hat
>>>> voting karma isn=E2=80=99t usually given out to people who write the= ir first
>>>> mailing list entry. >>>> >>>> But I do believe I qualify as =E2=80=9CLead developers of PHP based = projects
>>>> (frameworks, cms, tools, etc.)=E2=80=9D >>> >>> Hey Tobias, >>> >>> My response here is basically the same as the last time the topic cam= e up:
>>> https://externals.io/message/110936#110937 Voting is just the very la= st
>>> 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 exten= sive
>>> 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 wel= l as
>>> other people's view of the proposal. >> >> I second this. >> >>> At least in my personal opinion, I think it's important that people g= ranted
>>> voting rights as community representatives have at least some histori= cal
>>> 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. >> >=20 > 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 --=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ --lP33ItGRDEvdIM29sbn7GLrFSpMZxLDgK--
  115511
July 20, 2021 08:07 jordan.ledoux@gmail.com (Jordan LeDoux)
On Mon, Jul 19, 2021 at 11:23 PM Andreas Heigl <andreas@heigl.org> wrote:

> 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 ppv@gmail.com> > wrote: > >>> > >>> On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm 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
  115515
July 20, 2021 09:14 Andreas Heigl <andreas@heigl.org>
--tlJBBPvENjvbHOqTdOFCDriwsIliQrGYH
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

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 pus= h
> certain concerns to the side, however it might be worth considering if = the
> process could promote a variety of opinions and backgrounds. Even if su= ch a
> situation were considered unlikely, it could be worth writing such a > process with that in mind if the process involves a sponsor. >=20 > 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 contributi= ons
> (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 wo= rth
> considering these impacts explicitly. >=20 > It's also worth considering if people believe that this is a process th= at
> will be iterated on or if there is a desire to get it right the first t= ime
> 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, w= hich
> gives everyone clarity and certainty about the structure over a given > period. >=20 > 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 --=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ --tlJBBPvENjvbHOqTdOFCDriwsIliQrGYH--
  115517
July 20, 2021 09:57 mike@newclarity.net (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?
> 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
> On Jul 20, 2021, at 2:22 AM, Andreas Heigl <andreas@heigl.org> wrote: > > 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 ppv@gmail.com> wrote: >>>> >>>> On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm 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 | > +---------------------------------------------------------------------+ >
  115527
July 20, 2021 12:55 Andreas Heigl <andreas@heigl.org>
--AfoHcxEO4hyv3OK2oxa81vkDzK7RoTJb2
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Hey Mike

Thank you for your feedback!

Am 20.07.21 um 11:57 schrieb Mike Schinkel:
> Quoting the RFC >=20 >> the requester has contributed to the PHP sourcecode ecosystem. >=20 > You mention what types of contributions apply, but give no indication o= f 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?
>=20 >> these contributions show a consistent effort >=20 > 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.
>=20 >> the requester has shown interaction with the main discussion medium of= the relevant part
>=20 >=20 > This is unclear to me. I assume "the main discussion medium" is more th= an just the mailing list, otherwise you would have said the mailing list,=
right?=20 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
>=20 > And what does "relevant part" mean? Maybe some examples would help, = at least in reply.
See above ;-)
>=20 >> the requester has a proponent that currently has voting karma >=20 > Agreeing with Jordan LeDoux, these seems primed to make current voting = members a target for wanna-be voters.=20
>=20 > Maybe this could discuss processes that would naturally bring people to= want to sponsor someone, such as (maybe?) recommending they first "appre=
ntice" under one or more people by helping document, helping fix bugs, or= working with them on an RFC?=20 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
>=20 >> The requester should search a proponent of their case that then propos= es the request for voting karma to the dedicated discussion medium for su=
ch requests. The proposal should include the reasons why the proponent th= inks the requester fullfills the above stated requirements.
>=20 > Are you really suggesting that allowing someone new to vote would be he= ld out in the open, where the discussions about that person will get reco=
rded on externals.io <http://externals.io/> and indexed by Google for all= to see, forevermore? =20
>=20 > Seems like discussion about an individual should respect the long term = privacy of the individual a bit more, especially for those who will be tu=
rned down.=20 Thanks! I actually hadn't thought about that! Any suggestions on how to improve that?
>=20 >> When there are more approvals than objections the voting karma will be= granted.
>=20 > How is voting to be done? Yay's and nay's on a mailing list? Or some = other way? =20
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.
>=20 > 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...
>=20 > I ask these questions so people who might be interested in getting voti= ng rights would have an objective roadmap for how to get there otherwise =
it would seem to just be documenting an extremely subjective process. (W= hich 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 effor= ts. Perhaps we should add a passage to the RFC regarding that as well. Thanks though for your input! Cheers Andreas --=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ --AfoHcxEO4hyv3OK2oxa81vkDzK7RoTJb2--
  115528
July 20, 2021 13:11 mike@newclarity.net (Mike Schinkel)
> On Jul 20, 2021, at 8:55 AM, Andreas Heigl <andreas@heigl.org> wrote: > > 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
  115530
July 20, 2021 13:49 Andreas Heigl <andreas@heigl.org>
--iR9AFPB32rXxsf4IyoajoGZvEXO3qx4jN
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Hey Mike

Am 20.07.21 um 15:11 schrieb Mike Schinkel:
>> On Jul 20, 2021, at 8:55 AM, Andreas Heigl <andreas@heigl.org> wrote: >> >> 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 right=
s? 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 i= s
>> 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?=
>=20 > As I don't have voting rights, I don't think I am in an empowered posit= ion 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.
>=20 > If I were going to design the PHP's governance I would design different= ly, but since I'm not in a role to do that I can only accept that PHP gov=
ernance is the way that it is, and point out things I think might be prob= lematic. >
> As for specific suggestions? I'll let others who already have a vote sp= ecify 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
>=20 > -Mike >=20
--=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ --iR9AFPB32rXxsf4IyoajoGZvEXO3qx4jN--
  115519
July 20, 2021 10:07 alec@alec.pl (Aleksander Machniak)
On 20.07.2021 08:22, Andreas Heigl wrote:

> 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
  115523
July 20, 2021 11:12 office.hamzaahmad@gmail.com (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 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

On 7/20/21, Aleksander Machniak <alec@alec.pl> wrote:
> On 20.07.2021 08:22, Andreas Heigl wrote: > >> 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  115524
July 20, 2021 11:59 Andreas Heigl <andreas@heigl.org>
--I72Ajwzsfb2PxKojLkjOLAekmo2bhkNcY
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

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 --=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ --I72Ajwzsfb2PxKojLkjOLAekmo2bhkNcY--
  115525
July 20, 2021 12:40 chasepeeler@gmail.com (Chase Peeler)
On Tue, Jul 20, 2021 at 2:22 AM Andreas Heigl <andreas@heigl.org> wrote:

> 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 ppv@gmail.com> > wrote: > >>> > >>> On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm 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
  115507
July 20, 2021 05:37 tobias.nyholm@gmail.com (Tobias Nyholm)
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 Mon, 19 Jul 2021 at 01:37, Nikita Popov ppv@gmail.com> wrote:

> On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm 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 >
  115529
July 20, 2021 13:39 rowan.collins@gmail.com (Rowan Tommins)
On 20/07/2021 06:37, Tobias Nyholm wrote:
> 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]
  115541
July 21, 2021 10:49 mike@newclarity.net (Mike Schinkel)
> On Jul 20, 2021, at 9:39 AM, Rowan Tommins collins@gmail.com> wrote: > > 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: 1. 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? 2. 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: 1. 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. 2. Lowering the bar for voting rights because voters couldn't do damage to core-related concerns. 3. Possibly gain more participation from userland 4. An increase in userland satisfaction from either being allowed to participate or for the broader community getting more features userland developers want. 5. 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
  115531
July 20, 2021 14:26 matthewmatthew@gmail.com (Matthew Brown)
On Sun, 18 Jul 2021 at 14:47, Tobias Nyholm nyholm@gmail.com> wrote:

> 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