Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107477
MIME-Version: 1.0
References: <67911D3D-CBC1-4847-9F4B-3C895EF84741@newclarity.net>
 <4ed1fb31-a8e4-bff7-54f5-c66c95c692c4@alec.pl> <CAG9XoMTU+X1zTjdZekjHE6b0nDnckxryLKhbNumWa_d45B6tqw@mail.gmail.com>
 <CAPKYkKyKGHyDL4_VkvKDHBofZ_hkB7Bmcbx8Bik4x2nE9ANcLw@mail.gmail.com>
In-Reply-To: <CAPKYkKyKGHyDL4_VkvKDHBofZ_hkB7Bmcbx8Bik4x2nE9ANcLw@mail.gmail.com>
Date: Thu, 10 Oct 2019 20:25:48 +0200
Message-ID: <CAG9XoMQQJb_ggFMzZ-nU05+ju0GCXD5-FALmN3uD_B9OJ7AWKA@mail.gmail.com>
To: Chase Peeler <chasepeeler@gmail.com>
Cc: "A.L.E.C" <alec@alec.pl>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000085b85e0594928896"
Subject: Re: [PHP-DEV] Constraints and userland@
From: benjamin.morel@gmail.com (Benjamin Morel)

--00000000000085b85e0594928896
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> 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 year=
s.
> 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 man=
y
> 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 ther=
e
> 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?

=E2=80=94 Benjamin

On Thu, 10 Oct 2019 at 19:09, Chase Peeler <chasepeeler@gmail.com> wrote:

>
>
> 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 b=
e
>> > 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 preferenc=
es
>> > (even if it would
>> > exclude non-open source entities).
>>
>>
>>
>> I do like the idea very much as well. However, if this is to be automate=
d,
>> I wouldn't base the right to vote on the number of commits, but rather o=
n
>> 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 >=3D 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 >=3D n stars, etc.) t=
hen
>> review each *passing* application manually. This way the number of
>> applications should be manageable, there could be a queue that all curre=
nt
>> maintainers could have access to and take a few minutes here and there t=
o
>> 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 year=
s.
> 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 man=
y
> 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 ther=
e
> 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 b=
y
>> mistake).
>>
>> =E2=80=94 Benjamin
>>
>
>
> --
> Chase Peeler
> chasepeeler@gmail.com
>

--00000000000085b85e0594928896--