Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103957 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 46760 invoked from network); 1 Feb 2019 01:03:54 -0000 Received: from unknown (HELO mail-oi1-f182.google.com) (209.85.167.182) by pb1.pair.com with SMTP; 1 Feb 2019 01:03:54 -0000 Received: by mail-oi1-f182.google.com with SMTP id m6so4048506oig.11 for ; Thu, 31 Jan 2019 13:43:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=18ojhbUhXIrrdB4h+m3TvhTcyYBAMtLDH1qGUhDcbmo=; b=ANU8V/AvDcMOWkwB9KAsge7fyqnyhLawTIRNuhf1aZ2Q7wnnOtfu6psTIwigQ71wqk T6oS7r9lZC7/mwB71M6LVI2NxebpWXU85G9rw8T8YT1eFMo7NAuz6SayCuhI3BpFGfOG ZsSb0+xFJbx4d+IRZurdveppAdj/PHVeybNreknNFGLx/FdKDDKFzLGv9gv994MwLpv+ JFrG+OCg1BC7Q2EmET/0KqvVL1FmKXAf3pohQ4RtRYMdpkE8bHtvePizE+bX9eBiEJvg C/32kTheZsC6TqyjDadws4O/o99485kMG6PgtRiyQIQ8EJLEnrT4KgyuP2nDA2WT7Q8b yPng== X-Gm-Message-State: AHQUAuazOMSnMSX5R7h0UgIarITsk68j+go2jrl0uh+Is/LkBmdRSu8i bqSKqDYl4BUcbr5NNuqnqrVHCalT7vkp9sFVuhA= X-Google-Smtp-Source: ALg8bN7A1hTmYz23Cj6GqkvKXRzwHZ1FJd75f5lHcpR/um+0UU749pmvoaaB8y9erZEUi2Y1njdV2j32AyHOzysvEC4= X-Received: by 2002:aca:f044:: with SMTP id o65mr15439179oih.145.1548971032186; Thu, 31 Jan 2019 13:43:52 -0800 (PST) MIME-Version: 1.0 References: <03f401d4b96b$18b9dc60$4a2d9520$@php.net> In-Reply-To: Date: Thu, 31 Jan 2019 23:43:40 +0200 Message-ID: To: Chase Peeler Cc: Zeev Suraski , Internals Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update) From: kalle@php.net (Kalle Sommer Nielsen) Den tor. 31. jan. 2019 kl. 20.17 skrev Chase Peeler = : > I don't know if there is a good way to implement it, but I definitely thi= nk there is value in some sort of voice being given to those that use PHP t= o build things, but don't contribute to the actual source. > > I think it's important, though, to make sure that developers that are out= there actually developing things with PHP (not to say that contributors do= n't belong to that group) have a voice - I'm just wondering if that needs t= o be defined in a more formal way. One statistic I just found says that alm= ost 6 million websites are running PHP7. Even if we assume that it averages= out to where there is 1 developer for every 100 sites, that's still 60,000= developers being represented by 175 voters. I do believe that the right to vote is a privilege of actually contributing to the project, which in our case is seen by code as we are a scripting language project, I think that is a fair definition. However I do believe that because it is also a privilege it should be considered as something you earn by dedicating yourself to the project, if you are dedicated to the project then I would assume (and I'm certain that I speak for most core developers) when I say that those voting for changes in PHP does it in PHP's best interest. Because they understand the complications and impact changing things have. We can take an example by looking at some of the more recent change proposals for PHP8 that goes to show that not a lot of thought about the implications and effect changing a few functions may have. For your open source framework that have lets say maybe 10.000 users, that is not a big deal, but when you take that number and maybe multiply it by 1.000 (or you can swap around the zeros), then the impact of which we change things are set in a very different perspective. Okay we do have procedures for how to deal with some of these things for what can and can't go into a branch. My point here is that when you are apart of the project and more or less integrated with it, you would also understand the ramifications on a project of the scale. I do not want this to sound unwelcoming or so at all, I would like more to join the project and put effort into improving our code base. However like Johannes said in a mail earlier in this thread, if the maintainers (core developers) are overruled by a third party, then a point they simply loose interest and stop contributing and the project will begin to halt. I would feel that same way myself. > Maybe the voice that we currently have in the form of being able to parti= cipate in these discussions is enough. I'd be interested in knowing how oft= en voters are persuaded to take a position on an issue after discussing it = with non-voting developers - whether via these discussion lists or on other= mediums. I think the AFUP did something rather interesting, which we could use as a model; If you are not familiar with the AFUP (Association Fran=C3=A7aise des Utilisateurs de PHP), then it is the french usergroup for PHP. Every now and then, we used to get emails from a member of their group that would post a small summary of their thoughts regarding a certain RFC, whether they were infavor of it or not and potential problems they see as userland. That I believe could work much better, as in giving external projects or organization a way to comment on an RFC (which I would hope more would have done instead of just being silent) about the pros and cons. As core developers we take comments and feedback (Yes we have heard the striking feedback about the standard library) as close as we can to make sure that we don't just do something that would literally render a PHP based project unusable by a change we have done. > Maybe instead of giving all members of PHP-FIG a vote, the RFC can be ame= nded to specify that PHP related groups with a certain number of active mem= bers are given a single vote. Or, instead of membership numbers, an applica= tion process of some sort can be put in place for various groups to petitio= n for representation. If accepted, that group is given a single vote. A com= mittee can be put together that is in charge of addressing the applications= . Please no committee or more bureaucracy as it just makes everything so much more political and complicated for no satisfying reason. --=20 regards, Kalle Sommer Nielsen kalle@php.net