There is no middle ground in an RFC that proposes the deprecation at this level of specifics. You either deprecate it, or you don't. The only middle ground you can reach, is that you give it a vote to see if it should indeed be deprecated. Perhaps I'm looking at it from a wrong perspective, it looks very binary to me (see next answer for why).
I will address the question of perspective below.
The idea behind a deprecation is that you are discouraging its use and plan to remove it at a later stage. To me it makes no sense to deprecate something but never remove it, might as well not deprecate it at that point. Either we accept it's in the language and keep it, or we remove it at some point, which ideally gets a deprecation first to ease migrations.
There is not logical/logistical/technical reason why we cannot deprecate w/o a plan to remove. The only reason is that you and maybe others have established the constraint in your mind(s) that it is a requirement. And that is unfortunate, because there is absolutely nothing that would stop us from deprecating something with no current plan to remove.
But I am not challenging you. People do this all the time in areas they care about. They establish constraints that only exist in their mind. I could give multiple example of where that happens in governmental politics, but I won't for fear of offending someone who has set constraints in their mind about any given example topic.
Instead I am asking you to be willing to find a workable solution and ask yourself this: Is this constraint which only exists in your attitude towards to topic really so important that we cannot consider revisiting it, especially if it will allow the PHP team to signal users not to use a disliked feature but also ensure that no userland code won't break? The tangible benefits here seem to be to outweigh the intangible constraints.
And please note, there is nothing that stops a future RFC from remove a feature at a future date assuming the community agrees that the BC concern for this feature is no longer the overriding concern.
But to force a constraint that does not actually exist feels like we are tying one hand behind our back prior to a fist-fight. Especially when making sure we have all available hands can potentially reduce the acrimony of these non-stop BC debates.
I agree. There are a lot of unhappy user-land voices about a lot of decisions made here. Sadly I don't see a way to give everyone a voice in this.
I do see a way to give userland a voice, and I have written up significant parts of a proposal for this, but it is far from complete.
In a nutshell we could create a PHP userland advisory board to parallel internals, complete with it's own list named userland@.
As a straw man proposal there could be a set number of seats (~250?), divided up by how they are involved in PHP; corp developer, independent developer, framework vendor, hosting company, etc. They should participate as representatives of userland rather than as representatives of their own opinions. They would get to vote on things so we could gauge userland's interests, but their vote could only be used to veto an accepted RFC, and internals@ could override the veto if, say, 90% of internals@ members voted to do so.
We could also have requirements for these delegates to contribute in areas such as documentation, testing, and for those who are representing commercial interests, possibly even sponsorship funds (although this latter would require an entity to receive those funds and AFAIK that entity does not currently exist.)
And this could reduce traffic on the internals@ list as debates that affect userland could move to userland@ list.
The only thing left about this proposal is actually how to implement it, which is something that a working group of people could get together and create a proposal. Assuming there are enough people that would embrace the idea to create said working group.
-Mike
As a straw man proposal there could be a set number of seats (~250?), divided up by how they are involved in PHP; corp developer, independent developer, framework vendor, hosting company, etc. They should participate as representatives of userland rather than as representatives of their own opinions. They would get to vote on things so we could gauge userland's interests, but their vote could only be used to veto an accepted RFC, and internals@ could override the veto if, say, 90% of internals@ members voted to do so.
As a part of PHP community I like the idea. I'd propose something that could make the
proposal simpler in implementation.
Create a poll system where users are authorized to be registered and be able to vote if
they are github/gitlab users with >1000 commits in projects where PHP is one of the main
languages. I think something like that should be doable and will not require any "paper
work". It should give quite good estimation on the community preferences (even if it would
exclude non-open source entities).
I very much like the idea such vote would be a veto which would rise the bar for an RFC to
pass.
ps. first time poster, but I couldn't sit quiet seeing what's going on on the list recently.
--
Aleksander 'A.L.E.C' Machniak
Kolab Groupware Developer [http://kolab.org]
Roundcube Webmail Developer [http://roundcube.net]
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
As a part of PHP community I like the idea. I'd propose something that
could make the
proposal simpler in implementation.
Create a poll system where users are authorized to be registered and be
able to vote if
they are github/gitlab users with >1000 commits in projects where PHP is
one of the main
languages. I think something like that should be doable and will not
require any "paper
work". It should give quite good estimation on the community preferences
(even if it would
exclude non-open source entities).
I do like the idea very much as well. However, if this is to be automated,
I wouldn't base the right to vote on the number of commits, but rather on
the number of GitHub stars, as it's way too easy to create artificial
commits on a new account at any time.
For example, allow any repository owner or main committer (for orgs) for a
repo with >= 100 stars.
Or, avoid doing anything automatically, just decide on a baseline set of
requirements that can be verified automatically (like at least n commits to
public repos, or at least one public git repo with >= n stars, etc.) then
review each passing application manually. This way the number of
applications should be manageable, there could be a queue that all current
maintainers could have access to and take a few minutes here and there to
review.
By keeping the review process manual, we can also easily revoke someone's
voting rights if the application turned out to be fraudulent (accepted by
mistake).
— Benjamin
On Thu, Oct 10, 2019 at 3:30 AM Benjamin Morel benjamin.morel@gmail.com
wrote:
As a part of PHP community I like the idea. I'd propose something that
could make the
proposal simpler in implementation.
Create a poll system where users are authorized to be registered and be
able to vote if
they are github/gitlab users with >1000 commits in projects where PHP is
one of the main
languages. I think something like that should be doable and will not
require any "paper
work". It should give quite good estimation on the community preferences
(even if it would
exclude non-open source entities).I do like the idea very much as well. However, if this is to be automated,
I wouldn't base the right to vote on the number of commits, but rather on
the number of GitHub stars, as it's way too easy to create artificial
commits on a new account at any time.
For example, allow any repository owner or main committer (for orgs) for a
repo with >= 100 stars.Or, avoid doing anything automatically, just decide on a baseline set of
requirements that can be verified automatically (like at least n commits to
public repos, or at least one public git repo with >= n stars, etc.) then
review each passing application manually. This way the number of
applications should be manageable, there could be a queue that all current
maintainers could have access to and take a few minutes here and there to
review.
I've spent the last 14 years working on an internal system that is built
with PHP. I've been using PHP in one form or another for the last 20 years.
I've done some minor work on various open source projects, but not very
much. This requirement would mean that I don't get a vote, despite my many
many years of experience with the language.
I've proposed something similar in the past where various groups would be
able to apply for voting rights. Each group would get one delegate. The
difficult part is that a committee would need to exist that would review
and approve applications. This was rejected because it created a lot of
additional work for a small group of people that would be required to
manage those applications.
I don't think there is an EASY way to allow userland voting. I think there
are many ways it could be done, but all of them would require additional
time and dedication from people already putting in a lot of time and
dedication to the development process itself.
By keeping the review process manual, we can also easily revoke someone's
voting rights if the application turned out to be fraudulent (accepted by
mistake).— Benjamin
--
Chase Peeler
chasepeeler@gmail.com
I've spent the last 14 years working on an internal system that is built
with PHP. I've been using PHP in one form or another for the last 20 years.
I've done some minor work on various open source projects, but not very
much. This requirement would mean that I don't get a vote, despite my many
many years of experience with the language.
That's a good point, my reasoning does exclude people who don't contribute
to public projects, and they do deserve a voice as well. Still, doing as I
suggested would be a starting point, where decisions could at least include
userland developers maintaining libraries that other developers use.
I've proposed something similar in the past where various groups would be
able to apply for voting rights. Each group would get one delegate. The
difficult part is that a committee would need to exist that would review
and approve applications. This was rejected because it created a lot of
additional work for a small group of people that would be required to
manage those applications.
I don't think there is an EASY way to allow userland voting. I think there
are many ways it could be done, but all of them would require additional
time and dedication from people already putting in a lot of time and
dedication to the development process itself.
Applications from non-OSS contributors could be voted by accepted OSS
contributors; this would lighten the work of core PHP members. That being
said, it will be hard for anyone to judge someone else based on, basically,
his resume alone. Without public contributions of some kind, we can't
really judge if person X is more entitled to have a vote than person Y.
After all, why would a senior with 15 years experience be allowed to have a
vote, while a junior with 2 years experience wouldn't?
For that reason, I think we could just allow anyone to vote, but put them
in a third category.
Basically, voters would now belong to one of 3 categories:
- votes from core PHP members (the ones allowed to vote today)
- votes from reasonably influent, userland, open source developers
- votes from everybody else (we'd need to find some reasonably secure way
to avoid multiple votes from the same person, in this category)
And we could change the RFC process to either:
- require a 2/3 majority of votes in each category
- *or *require a 2/3 majority in the average of all three categories
- *or *give a weight to each category (like 50% to core members, 30% to OSS
developers and 20% to the rest of the world) and calculate the result
accordingly -
or even something like require a 2/3 majority in at least 2 of these
categories
... or any other rule we could think of.
I quite like this idea of splitting voters into 3 categories, where each
category has a weight that does not depend on the number of people who
voted inside it.
Something like this would seem fair to me. Thoughts?
— Benjamin
On Thu, Oct 10, 2019 at 3:30 AM Benjamin Morel benjamin.morel@gmail.com
wrote:As a part of PHP community I like the idea. I'd propose something that
could make the
proposal simpler in implementation.
Create a poll system where users are authorized to be registered and be
able to vote if
they are github/gitlab users with >1000 commits in projects where PHP is
one of the main
languages. I think something like that should be doable and will not
require any "paper
work". It should give quite good estimation on the community preferences
(even if it would
exclude non-open source entities).I do like the idea very much as well. However, if this is to be automated,
I wouldn't base the right to vote on the number of commits, but rather on
the number of GitHub stars, as it's way too easy to create artificial
commits on a new account at any time.
For example, allow any repository owner or main committer (for orgs) for a
repo with >= 100 stars.Or, avoid doing anything automatically, just decide on a baseline set of
requirements that can be verified automatically (like at least n commits
to
public repos, or at least one public git repo with >= n stars, etc.) then
review each passing application manually. This way the number of
applications should be manageable, there could be a queue that all current
maintainers could have access to and take a few minutes here and there to
review.I've spent the last 14 years working on an internal system that is built
with PHP. I've been using PHP in one form or another for the last 20 years.
I've done some minor work on various open source projects, but not very
much. This requirement would mean that I don't get a vote, despite my many
many years of experience with the language.I've proposed something similar in the past where various groups would be
able to apply for voting rights. Each group would get one delegate. The
difficult part is that a committee would need to exist that would review
and approve applications. This was rejected because it created a lot of
additional work for a small group of people that would be required to
manage those applications.I don't think there is an EASY way to allow userland voting. I think there
are many ways it could be done, but all of them would require additional
time and dedication from people already putting in a lot of time and
dedication to the development process itself.By keeping the review process manual, we can also easily revoke someone's
voting rights if the application turned out to be fraudulent (accepted by
mistake).— Benjamin
--
Chase Peeler
chasepeeler@gmail.com
-----Original Message-----
From: Benjamin Morel [mailto:benjamin.morel@gmail.com]And we could change the RFC process to either:
- require a 2/3 majority of votes in each category
- *or *require a 2/3 majority in the average of all three categories
- *or *give a weight to each category (like 50% to core members, 30% to OSS
developers and 20% to the rest of the world) and calculate the result
accordingly- or even something like require a 2/3 majority in at least 2 of these
categories... or any other rule we could think of.
I quite like this idea of splitting voters into 3 categories, where each category
has a weight that does not depend on the number of people who voted inside
it.Something like this would seem fair to me. Thoughts?
The problem in this is that - what good is a vote/RFC if no one is there to implement it?
Like you could get and overwhelming majority/weight in all the non-developer groups but what then? Are you then forcing someone to write the code? Pick someone from the group(s) who voted for or pay someone to do it (quite valid though)?
IMO even now all the discussion in the internals@ (hence the name) for the developer (RFC author) is just to see if any other code contributor has something to say about his idea. The rest can voice their concerns but as long you don't really contribute yourself I doubt you get to choose in the end..
rr