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 show 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 more 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 from sufficient, especially for newcomers. The only solution I imagine is adding 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, today, the code contains almost no comments except function prototypes. That’s 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 announced 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 mediator
/ 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 next one, and start a new discussion in a more constructive atmosphere. Upcoming 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 test the popularity of a feature before he starts writing code, clearly stating 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 is 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 provides almost everything we need through issues (subscriptions/notifications, post edition, links to PRs and code blocks, and more), and only lacks an usable 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 metainfo and a link to the php-src github issue).
The mailing list should be restricted to questions and replies, announcing new RFCs, and general discussion about PHP internals. As soon as an RFC is published, it should evolve in its own space, and people interested in the subject would explicitely subscribe to the discussion. Even the vote should 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 vote (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çois
- 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 more 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 from sufficient, especially for newcomers. The only solution I imagine is adding 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, today, the code contains almost no comments except function prototypes. That’s 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).
Having been expanding docblock annotation in production code for many
years many of the current discussions cause me a number of problems with
the move to change just how we document in production. I've been back
inside the code again simply trying to keep my own KEY elements
available and it really does take a long time to understand some of the
way the code is currently structured. The phpng changes seem to be tied
up with a number changes to style of things rather than implementing the
change, but it IS only the person who developed the change that can
totally understand how to change every other extension in the same style :(
Currently I lost track of the bits I should be using as current notes
and searching just pulls up phpng or even older guides, so it would be
nice to have a single index for PHP7 with all of the good samples linked.
Oh and currently I can't even get master to compile ... which it was
doing here Friday ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
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 show strong support, it becomes an opposable
reference.
I'm mostly absent myself for some time now, so I have no idea how bad it
recently became but some comments:
RFC 1855[1] exists, even though it is just an "FYI" and not an official
accepted standard.
I don't believe extra rules are needed, but maturity by the majority of
the participants is, so i.e. if discussions become personal or anything
don't go to the same level but continue the discussion on a "sane" topic
etc. Also it would be great if there were people to moderate discussions
- not in the meaning of "pre censorship" but by collecting arguments
into summaries, stepping in (on- and even more off-list) if discussions
fade away to bring them back on topic etc. such a thing takes a hell lot
of time and bring the individual even less merits than most other form
of contributions but can help the community a lot!
johannes
Hi Francois,
Between my day job and my local user group meetup, I haven't had as much
time as I'd like to read and respond to this. You've got some great
suggestions here, though, so I'm going to rush through and add some
thoughts before I go to bed.
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 show
strong support, it becomes an opposable reference.
I think this would work best if it focused on positive statements that
everyone should do more - the risk with listing bad things is people can
start throwing them at each other as yet more noise, further distracting
from the real aim of the conversation.
A regular reminder could perhaps be useful; I've thought before about an
FAQ for the list, posted every month as was (I believe) traditional on
Usenet. A section of that could include succinct reminders of the list's
rules, as currently set out in the README file (sorry, I don't have the
link to hand).
- 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 more
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 from
sufficient, especially for newcomers. The only solution I imagine is adding
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, today,
the code contains almost no comments except function prototypes. That’s 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).
This is a great suggestion, and one even I could have a go at - I don't
really know enough of the core to suggest changes, but occasionally spend time reading it and trying to learn. If I sent in a Pull Request with nothing but comments, someone might even correct my understanding by improving the content, and it would be a double win.
- We also can encourage co-authoring RFCs. People are used to work alone
but it can change if there's a will.
Agreed.
We can also find a set of skilled
volunteers agreeing to give their opinion on RFCs before they're announced
on the list. That's just an opinion but it can avoid the discussion going
nowhere from the beginning.
I think this happens a bit behind the scenes - things have sometimes been talked over on IRC or something first. But perhaps it needs to be more visibly summarised - start the process with a summary of points already raised, and, importantly, acted on.
- The leadership of the language is left to consensus, so that when
consensus cannot be reached, someone has to take on the role of mediator
/ 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.
The problem lies in detecting/defining the consensus before the vote takes place. Some say the typehint RFC should not have been voted on in its current form due to lack of consensus, some that it should have been voted on in an earlier form, which Andrea felt lacked consensus. So we don't even have a consensus on how to spot a consensus. I don't know how to get out of that Catch-22.
- 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 test
the popularity of a feature before he starts writing code, clearly stating
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 is
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.
I think the current RFC template encourages the votes to happen in one go, as does the index by status. Perhaps to encourage multiple votes (and collaboration), we could come up with additional headings for the drafting stages.
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.
I think if there was more precedent for voting during refinement of the feature, the scalar typehints vote wouldn't have been labeled "final" (indeed, that label is only implied and assumed because there aren't any non-final votes).
An alternative, sort of coming back to the idea of multiple authorship, would be to have "amendments", as found in parliamentary procedures. So that a series of short votes, proposed by different people, could refine the text of the RFC, which would then be voted on as a spec. I'm not sure how well this would work, but thought I'd mention it in case someone wants to ponder it further.
- 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 provides
almost everything we need through issues (subscriptions/notifications, post
edition, links to PRs and code blocks, and more), and only lacks an usable
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 metainfo
and a link to the php-src github issue).
I've not used github enough to comment on whether it's suitable, but agree that it would be worth evaluating new tools. I think we need something that ties the discussion closer to the document, and separates sub-topics more readily than most email clients (GMail is particularly awful for navigating busy threads).
On the other hand, I think we should use the wiki more as a wiki - right now, it's a document repository running on wiki software, with rarely more than 2 editors touching a page, particularly if it's an RFC. What if we allowed absolutely anyone to edit draft RFCs, in the spirit of the original Wiki? People could add "thread mode" sections on contentious issues, then refactor them into summaries of the main points, either reflecting consensus, or leading to an interim vote.
Or at the least radical - remove the "author" and "version history" from the templates; those are document change control conventions, not collaborative editing ones. Instead, something like "primary sponsors" and, if really necessary, "major milestones".
The mailing list should be restricted to questions and replies, announcing
new RFCs, and general discussion about PHP internals. As soon as an RFC is
published, it should evolve in its own space, and people interested in the
subject would explicitely subscribe to the discussion. Even the vote should
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 vote
(but it will remain open).
That's an interesting way of looking at it, but there'd need to be some way of the discussion on these "breakout forums" making its way back to the main list in summary form, without it being yet another duty of the RFC sponsor. E.g. I'm not massively interested in DbC, but wouldn't want the whole thing to be discussed off-list, and land with a whole mass of dependencies and syntax extensions. Admittedly, this already happens if I don't skim-read the relevant thread, but it would be nice if it was easier to jump in, not harder.
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.
Again, thanks for the ideas, and I'm sure I'll have more to say on this as and when I get time.
Regards,
Rowan Collins
[IMSoP]
- The leadership of the language is left to consensus, so that when
consensus cannot be reached, someone has to take on the role of mediator
/ 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 next one, and start a new discussion in a more constructive atmosphere. Upcoming feature freeze was probably the reason but the result is that we need to restart everything from scratch in a bitter atmosphere.
To be clear: consensus is not leadership. Consensus cannot be
leadership. So the statement "leadership of the language is left to
consensus" is a very explicit and deliberate statement that the language
has no leadership.
That is, as I understand it, by design. But let's not pretend
otherwise. We have a leaderless language and development process, by
design, with all of the negative side-effects that such a power-vacuum
structure entails.
I'm not saying that as a criticism necessarily. It's just a fact, and we
shouldn't pretend otherwise.
- 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 test the popularity of a feature before he starts writing code, clearly stating 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 is 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.
The FIG ran into a similar issue a while back. The result is a somewhat
different two-stage RFC process as described here:
https://github.com/php-fig/fig-standards/blob/master/bylaws/004-psr-workflow.md
It's imperfect, but it does provide extra structure that has been a huge
improvement over the internals-like free-for-all that preceded it. In
particular, it allows members to vote on the concept of a PSR before the
implementation. IE, "do we want to have a spec dealing with HTTP
messages" is a separate vote from "is this particular implementation of
an HTTP message spec what we want to put our stamp on"?
Additionally, there's a separate spec and meta document. The meta doc
is specifically for things like "Why did you do X instead of Y?" and "we
rejected Z outright for these reasons". That said, people generally
don't read the metadoc any more frequently than they read the same notes
in Internals RFCs today, which often address the issue people are
talking about for the 5th time. :-(
An exact replica of FIG's process is probably not going to fly for
Internals for various good reasons, but it can hopefully serve as a
source of ideas.
--Larry Garfield
On Mon, Feb 16, 2015 at 7:48 PM, Larry Garfield larry@garfieldtech.com
wrote:
- The leadership of the language is left to consensus, so that when
consensus cannot be reached, someone has to take on the role of mediator
/ 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 next
one, and start a new discussion in a more constructive atmosphere. Upcoming
feature freeze was probably the reason but the result is that we need to
restart everything from scratch in a bitter atmosphere.To be clear: consensus is not leadership. Consensus cannot be
leadership. So the statement "leadership of the language is left to
consensus" is a very explicit and deliberate statement that the language
has no leadership.
On what basis are you making that assertion? Consensus can be viewed as a
form of "group leadership", so long as there are sufficient processes
involved to facilitate that. It need not necessarily lead to anarchy and
disorder, so I don't think it's necessarily a contradiction in terms.
The problem with having a single leader calling the shots in this case is
that it wouldn't make all the divergent views go away. Instead, we'd
probably see a good half a billion or so new hooks to PHP emerging as
competing projects. I think that would be far worse than what we have now,
even though what we have now is far from perfect.
That is, as I understand it, by design. But let's not pretend otherwise.
We have a leaderless language and development process, by design, with all
of the negative side-effects that such a power-vacuum structure entails.I'm not saying that as a criticism necessarily. It's just a fact, and we
shouldn't pretend otherwise.
- 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 test
the popularity of a feature before he starts writing code, clearly stating
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 is
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.The FIG ran into a similar issue a while back. The result is a somewhat
different two-stage RFC process as described here:
https://github.com/php-fig/fig-standards/blob/master/
bylaws/004-psr-workflow.mdIt's imperfect, but it does provide extra structure that has been a huge
improvement over the internals-like free-for-all that preceded it. In
particular, it allows members to vote on the concept of a PSR before the
implementation. IE, "do we want to have a spec dealing with HTTP messages"
is a separate vote from "is this particular implementation of an HTTP
message spec what we want to put our stamp on"?Additionally, there's a separate spec and meta document. The meta doc is
specifically for things like "Why did you do X instead of Y?" and "we
rejected Z outright for these reasons". That said, people generally don't
read the metadoc any more frequently than they read the same notes in
Internals RFCs today, which often address the issue people are talking
about for the 5th time. :-(An exact replica of FIG's process is probably not going to fly for
Internals for various good reasons, but it can hopefully serve as a source
of ideas.
The FIG is a good example of a relatively small group of individuals who
decided to draft their style preferences into a set of standards and tried
to impose that on everyone else by aggressively billing themselves as the
de-facto "official" standard. I recall on more than one occasion one of
their organizers posting here trying to get us to endorse their standard as
the official PHP standard. I've also seen them post on places like
StackOverflow on at least a couple occasions, interjecting on some
unrelated coding question to tell someone their code is not
standards-compliant and providing links to the PSR's.
I realize this is a tangent, but I always feel a need to push back now
whenever someone links to their PSR stuff as an example of what people
should be doing. You're fine citing them; I just had to put that little
asterisk in there. I'd hate to have to post a link to XKCD's "Standards"
strip again.... </soapbox>
--Larry Garfield
--
I think we should be careful not to make this more complicated than it
needs to be. Adding a complex new set of rules wouldn't make things any
more or less civil. On the whole, I think we do a fairly good job of that
on this list. There can be very heated disagreements, sometimes, but
you'll find that when you put any group of developers together. So long as
people behave like adults and make an effort to be civil, I don't think any
special action is needed on our part. Like the FIG, I'd tend to look at it
as a solution in search of a problem.
--Kris
To be clear: consensus is not leadership. Consensus cannot be
leadership. So the statement "leadership of the language is left to
consensus" is a very explicit and deliberate statement that the language
has no leadership.On what basis are you making that assertion? Consensus can be viewed as a
form of "group leadership", so long as there are sufficient processes
involved to facilitate that. It need not necessarily lead to anarchy and
disorder, so I don't think it's necessarily a contradiction in terms.The problem with having a single leader calling the shots in this case is
that it wouldn't make all the divergent views go away. Instead, we'd
probably see a good half a billion or so new hooks to PHP emerging as
competing projects. I think that would be far worse than what we have now,
even though what we have now is far from perfect.
"Flat consensus" vs. "strong dictator deciding everything" is a false
dichotomy. I make that assertion based on 9 years of experience in
Drupal, which despite having a BDFL in theory (Dries) is mostly
"consensus of whoever notices" run. It's a problematic structure that we
are currently having some difficult internal discussions about, because
it doesn't scale and it's leading to burnout issues, work slowdowns, and
other issues.
For background, see the presentation I gave on complex informal
structures at DrupalCon Amsterdam, which includes a wide array of links
to further reading on why informal semi-consensus structures are so
problematic:
https://amsterdam2014.drupal.org/session/managing-complexity
The FIG is a good example of a relatively small group of individuals who
decided to draft their style preferences into a set of standards and tried
to impose that on everyone else by aggressively billing themselves as the
de-facto "official" standard. I recall on more than one occasion one of
their organizers posting here trying to get us to endorse their standard as
the official PHP standard. I've also seen them post on places like
StackOverflow on at least a couple occasions, interjecting on some
unrelated coding question to tell someone their code is not
standards-compliant and providing links to the PSR's.I realize this is a tangent, but I always feel a need to push back now
whenever someone links to their PSR stuff as an example of what people
should be doing. You're fine citing them; I just had to put that little
asterisk in there. I'd hate to have to post a link to XKCD's "Standards"
strip again.... </soapbox>
That was how FIG started, certainly, under the name "PHP Standards
Group". I was one of those on the Internals list who called them to task
for the initial arrogance before they were booted off of php.net.
However, that was 6 years ago. FIG, while still far from perfect, has
evolved into a much more productive and useful organization, and I would
now put them squarely in the Force For Good(tm) category rather than
Force For Evil(tm). That wasn't the case originally, but it is now.
The creation of common baseline standards has been a major driver in the
PHP Renaissance, and is part of what made tools like Composer possible
and seeing the mixing and matching of code from Zend, Symfony, and
others as well as modernization efforts like Drupal 8, the new PHP BB,
ezPublish, etc.
(Disclosure: I joined FIG as the Drupal representative a few months
after they were booted off of php.net, a position I still hold. I also
co-authored the current voting/process bylaw with Phil Sturgeon.)
I think we should be careful not to make this more complicated than it
needs to be. Adding a complex new set of rules wouldn't make things any
more or less civil. On the whole, I think we do a fairly good job of that
on this list. There can be very heated disagreements, sometimes, but
you'll find that when you put any group of developers together. So long as
people behave like adults and make an effort to be civil, I don't think any
special action is needed on our part. Like the FIG, I'd tend to look at it
as a solution in search of a problem.--Kris
There sounds like there's a great deal of discontent with the current
minimalist process. The current RFC process was "OMG too much
structure" compared to the free-for-all that preceded it, but I don't
think many people would disagree that adding such structure has greatly
improved PHP and the tone of this list. Structure is not a bad thing;
bad structure is a bad thing. It's important to understand the difference.
Your opinion of FIG is noted, but don't let your distaste for its
founding (which I share) cloud you against a potential source of
positive inspiration to improve PHP and the PHP development process.
--Larry Garfield
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çois 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 show
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 more
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 from
sufficient, especially for newcomers. The only solution I imagine is adding
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, today,
the code contains almost no comments except function prototypes. That’s 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 announced
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 mediator
/ 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 next
one, and start a new discussion in a more constructive atmosphere. Upcoming
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 test
the popularity of a feature before he starts writing code, clearly stating
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 is
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 provides
almost everything we need through issues (subscriptions/notifications, post
edition, links to PRs and code blocks, and more), and only lacks an usable
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 metainfo
and a link to the php-src github issue).The mailing list should be restricted to questions and replies, announcing
new RFCs, and general discussion about PHP internals. As soon as an RFC is
published, it should evolve in its own space, and people interested in the
subject would explicitely subscribe to the discussion. Even the vote should
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 vote
(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çois