# Request for karma to vote on RFCs - Thread: https://externals.io/message/115464 - Original archive: https://news-web.php.net/php.internals/115464 - Started by Tobias Nyholm on 2021-07-18T18:47:27+00:00 - Messages: 32 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/115464.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #115464 — Tobias Nyholm — 2021-07-18T18:47:27+00:00 URL: https://externals.io/message/115464#115464 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 — Kalle Sommer Nielsen — 2021-07-18T20:46:59+00:00 URL: https://externals.io/message/115464#115465 · In reply to: #115464 Hi Den søn. 18. jul. 2021 kl. 21.47 skrev 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. 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 — Tobias Nyholm — 2021-07-19T03:28:10+00:00 URL: https://externals.io/message/115464#115468 · In reply to: #115465 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 — Stanislav Malyshev — 2021-07-19T05:32:58+00:00 URL: https://externals.io/message/115464#115471 · In reply to: #115468 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 --- ## #115475 — Pierre — 2021-07-19T07:41:54+00:00 URL: https://externals.io/message/115464#115475 · In reply to: #115465 Le 18/07/2021 à 22:46, Kalle Sommer Nielsen a écrit : > Hi > > Den søn. 18. jul. 2021 kl. 21.47 skrev Tobias Nyholm : > > […] > > 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 — Lynn — 2021-07-19T08:11:03+00:00 URL: https://externals.io/message/115464#115476 · In reply to: #115475 > - 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 — Pierre — 2021-07-19T08:33:26+00:00 URL: https://externals.io/message/115464#115477 · In reply to: #115476 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 --- ## #115478 — Nikita Popov — 2021-07-19T08:37:28+00:00 URL: https://externals.io/message/115464#115478 · In reply to: #115464 On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm 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 --- ## #115481 — Lynn — 2021-07-19T09:11:05+00:00 URL: https://externals.io/message/115464#115481 · In reply to: #115477 > Le 19/07/2021 à 10:11, Lynn a écrit : > > […] > > 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 — Kalle Sommer Nielsen — 2021-07-19T09:47:26+00:00 URL: https://externals.io/message/115464#115483 · In reply to: #115481 Den man. 19. jul. 2021 kl. 12.11 skrev Lynn : > 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 — Lynn — 2021-07-19T10:14:01+00:00 URL: https://externals.io/message/115464#115484 · In reply to: #115483 > 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. --- ## #115485 — Benjamin Morel — 2021-07-19T10:27:23+00:00 URL: https://externals.io/message/115464#115485 · In reply to: #115468 > > 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 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 --- ## #115486 — Kalle Sommer Nielsen — 2021-07-19T10:33:32+00:00 URL: https://externals.io/message/115464#115486 · In reply to: #115484 Den man. 19. jul. 2021 kl. 13.14 skrev Lynn : > 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 — Hamza Ahmad — 2021-07-19T13:44:28+00:00 URL: https://externals.io/message/115464#115489 · In reply to: #115486 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 > Den man. 19. jul. 2021 kl. 13.14 skrev Lynn : > > […] > > 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 > > > […] > > 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). > > > […] > > 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 --- ## #115496 — Levi Morrison via internals — 2021-07-19T14:34:03+00:00 URL: https://externals.io/message/115464#115496 · In reply to: #115478 > > On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm > wrote: > > > […] > > 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 — Andreas Heigl — 2021-07-19T15:02:47+00:00 URL: https://externals.io/message/115464#115497 · In reply to: #115496 Hey All Am 19.07.21 um 16:34 schrieb Levi Morrison via internals: > > > […] > > I second this. > > > […] > > 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 | +---------------------------------------------------------------------+ --- ## #115507 — Tobias Nyholm — 2021-07-20T05:37:04+00:00 URL: https://externals.io/message/115464#115507 · In reply to: #115478 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 > wrote: > > > […] > > 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 --- ## #115506 — Hamza Ahmad — 2021-07-20T05:37:11+00:00 URL: https://externals.io/message/115464#115506 · In reply to: #115497 > 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: > > […] > > 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 — Andreas Heigl — 2021-07-20T06:22:45+00:00 URL: https://externals.io/message/115464#115508 · In reply to: #115497 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: > > […] > > 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 | +---------------------------------------------------------------------+ --- ## #115511 — Jordan LeDoux — 2021-07-20T08:07:43+00:00 URL: https://externals.io/message/115464#115511 · In reply to: #115508 > Hey All > > Am 19.07.21 um 17:02 schrieb Andreas Heigl: > > […] > wrote: > > […] > that > > […] > up: > > […] > last > > […] > extensive > > […] > is the > > […] > as > > […] > granted > > […] > historical > > […] > > 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 — Andreas Heigl — 2021-07-20T09:14:15+00:00 URL: https://externals.io/message/115464#115515 · In reply to: #115511 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 | +---------------------------------------------------------------------+ --- ## #115517 — Mike Schinkel — 2021-07-20T09:57:12+00:00 URL: https://externals.io/message/115464#115517 · In reply to: #115508 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 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: > > […] > > 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 | > +---------------------------------------------------------------------+ --- ## #115519 — Aleksander Machniak — 2021-07-20T10:07:21+00:00 URL: https://externals.io/message/115464#115519 · In reply to: #115508 > 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 — Hamza Ahmad — 2021-07-20T11:12:21+00:00 URL: https://externals.io/message/115464#115523 · In reply to: #115519 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 > > > > […] > can be (but is not limited to): > > […] > > 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. > > > […] > > 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 --- ## #115524 — Andreas Heigl — 2021-07-20T11:59:00+00:00 URL: https://externals.io/message/115464#115524 · In reply to: #115523 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 | +---------------------------------------------------------------------+ --- Next page: https://externals.io/message/115464.md?page=2