Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83371
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <010b01d049fd$9a09a020$ce1ce060$@php.net>
References: <010b01d049fd$9a09a020$ce1ce060$@php.net>
Date: Sat, 21 Feb 2015 07:08:22 +0530
Message-ID: <CAP9Mp8gPpxkH+rmOvqwyfpP8NZoYRZn=xohiq1G5K7sdY1zh+A@mail.gmail.com>
To: francois@php.net
Cc: Rowan Collins <rowan.collins@gmail.com>, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113417f4752ba5050f8f39d3
Subject: Re: [PHP-DEV] Proposing [constructive] solutions (was: I quit)
From: ppasindud@gmail.com (Pasindu De Silva)

--001a113417f4752ba5050f8f39d3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Guys

on the point of "new blood"

I am new to internals therefore been going through some blogs, books,
slides, docs. I been trying to fix some bugs and commenting on some, I
would like to do something more get more involved.

I am not sure a procedure on getting new comers involved like
http://openmrs.org/help would work here. Some kind of point of contact for
newcomers (kind frightening to open a thread for the first time).

I been hacking around and doing some things.

https://github.com/pasindud/sing-php  <https://github.com/pasindud/sing-php=
>-
a localized php syntax (kind of esoteric languages for fun)

https://github.com/pasindud/php-extension-st-snippets - Sublime Text
Snippets for PHP internals. ( more to do )


I would like to pitch and help, great if someone can point me in the right
direction.
(not sure whether this is the right list to post in)

+1


On Mon, Feb 16, 2015 at 9:01 PM, Fran=C3=A7ois Laupretre <francois@php.net>
wrote:

> > De : Rowan Collins [mailto:rowan.collins@gmail.com]
> >
> > Saying "that's enough" isn't even a productive comment. Enough what?
> > What is it you are asking to happen next?
>
> Maybe an initiative to write an RFC about the rules we should follow when
> writing to the list. People who agree could show their support by a vote.
> The vote would never end and would just mean 'I agree and will try to
> follow these rules'. It probably already exists somewhere but refreshing =
it
> wouldn't be useless. It's purely symbolic but, once people explicitly sho=
w
> strong support, it becomes an opposable reference.
>
> > - There is a lack of expertise at the core level of the code, so
> > collaboration on each feature is low. RFCs tend to have a single
> > sponsor, who has to see the whole process through to the end.
>
> - One thing we can encourage, while indirect in this case, is writing mor=
e
> comments in code. With PHP 7, Sara's book is almost unusable and nobody
> will write another one soon. 'UPGRADING' and friends are fine but far fro=
m
> sufficient, especially for newcomers. The only solution I imagine is addi=
ng
> comments in the code. I know it is annoying when you don't have much time=
,
> but comments can be improved at any time. They can be written by the
> feature author, but also by other people, who needed a (too) long time to
> understand a feature, and write explanations to help followers. As an
> example, I spent some time understanding the multi-level architecture of
> str_[i]replace functions and added a lot of comments along with the patch=
 I
> will propose. Actually, everywhere you spend time understanding what's
> going on, more comments are needed. That's really important because, toda=
y,
> the code contains almost no comments except function prototypes. That=E2=
=80=99s ant
> work and I am far from perfect about comments in my own code, but it can
> make a difference, especially making the project more attractive for
> newcomers (and we *need* new blood).
>
> - We also can encourage co-authoring RFCs. People are used to work alone
> but it can change if there's a will. We can also find a set of skilled
> volunteers agreeing to give their opinion on RFCs before they're announce=
d
> on the list. That's just an opinion but it can avoid the discussion going
> nowhere from the beginning.
>
> > - The leadership of the language is left to consensus, so that when
> > consensus cannot be reached, someone has to take on the role of mediato=
r
> > / chairman / leader for the feature, and try to push through a
> compromise.
>
> I have no democratic solution for this. In the PHP spirit, as Zeev
> explained, if the RFC process doesn't bring a consensus before the vote,
> the discussion should stop and the RFC should be modified. Trying to push
> it to a 2/3 approval while people are fighting is counter-productive. In
> this regard, IMO (and I told her), Andrea should have withdrawn her RFC
> much sooner. It would have allowed to take more time for building the nex=
t
> one, and start a new discussion in a more constructive atmosphere. Upcomi=
ng
> feature freeze was probably the reason but the result is that we need to
> restart everything from scratch in a bitter atmosphere.
>
> > - The RFC process traditionally has only one voting phase, with a
> > Proof-Of-Concept patch completed, and voters expecting few
> > implementation details to change. So a lot of time has to be committed
> > to the details of a feature which might be outright rejected. It might
> > be more efficient if the principle of a change, details such as syntax,
> > and final implementation, could be considered separate phases.
>
> That's the tradition but I think it is quite open for improvements. While
> we are traditionally using one final vote with multiple options, nothing
> refrains anyone to organize informative pre-votes during discussion to te=
st
> the popularity of a feature before he starts writing code, clearly statin=
g
> that it is not the final vote. This would allow a better information from
> the community to the RFC author. The interest of such running pre-votes i=
s
> that they can contain many more options than the final vote and can be
> started and closed at anytime during discussion. The only requirement is
> that everyone understands that it in *not* the final vote.
>
> Considering the final vote, that's normal to demand a proof of concept
> patch, as the feature implications are generally not clear (even in
> author's mind). But the final vote does not require the final PR to be
> completed. The same for documentation. You just need to prove that your
> future changes won't create side issues that couldn't be discussed. That'=
s
> quite understandable and that's a point the scalar type hints RFC was
> failing because the vote would have ended with a lot of remaining open
> issues.
>
> > - The internals list is quite high-volume, and the same points end up
> > being raised multiple times, so a feature sponsor has to give the same
> > counter-point or explanation each time.
>
> That's the main issue to the RFC process, IMO, and I'd really favor
> switching to a more elaborate system. It was often said but it's a pity
> that a language like PHP, which runs so many high-level collaborative
> environments, uses such archaic tools for its own purpose. Github provide=
s
> almost everything we need through issues (subscriptions/notifications, po=
st
> edition, links to PRs and code blocks, and more), and only lacks an usabl=
e
> voting system. A lot of people are asking for it, but github is not very
> receptive at user's requests. Maybe we can use it and keep the final vote
> elsewhere, as the most important is the discussion. If everyone agrees, I
> can try writing my next RFC this way (a wiki page containing just metainf=
o
> and a link to the php-src github issue).
>
> The mailing list should be restricted to questions and replies, announcin=
g
> new RFCs, and general discussion about PHP internals. As soon as an RFC i=
s
> published, it should evolve in its own space, and people interested in th=
e
> subject would explicitely subscribe to the discussion. Even the vote shou=
ld
> ideally take place only among subscribed people as there is no reason for
> someone who did not follow the discussion to participate in the final vot=
e
> (but it will remain open).
>
> > Most of these don't have easy solutions, but hopefully they're specific
> > enough points that we can come up with some concrete ideas on how to
> > improve things.
>
> This post is way too long but that's just ideas. If you think some may be
> worth starting a separate thread, just tell me.
>
> Regards
>
> Fran=C3=A7ois
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a113417f4752ba5050f8f39d3--