Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107472
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>
In-Reply-To: <CAG9XoMTU+X1zTjdZekjHE6b0nDnckxryLKhbNumWa_d45B6tqw@mail.gmail.com>
Date: Thu, 10 Oct 2019 13:09:38 -0400
Message-ID: <CAPKYkKyKGHyDL4_VkvKDHBofZ_hkB7Bmcbx8Bik4x2nE9ANcLw@mail.gmail.com>
To: Benjamin Morel <benjamin.morel@gmail.com>
Cc: "A.L.E.C" <alec@alec.pl>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000162f8905949178b9"
Subject: Re: [PHP-DEV] Constraints and userland@
From: chasepeeler@gmail.com (Chase Peeler)

--000000000000162f8905949178b9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 i=
s
> > 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 preference=
s
> > (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 >=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.) th=
en
> review each *passing* application manually. This way the number of
> applications should be manageable, there could be a queue that all curren=
t
> 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).
>
> =E2=80=94 Benjamin
>


--=20
Chase Peeler
chasepeeler@gmail.com

--000000000000162f8905949178b9--