François Laupretre wrote on 16/02/2015 12:27:
De : Rowan Collins [mailto:rowan.coll...@gmail.com]
Please can we take Andrea at her word:
> This isn’t a judgement of the PHP community nor the internals mailing
list, you’re all wonderful people and it’s really been a pleasure, and I
mean that completely honestly.
If people want to express their own frustrations at the community - and
do so in a constructive way - then by all means start your own thread.
But it's kind of annoying to see everyone leaping to attach motives to
Andrea's exit which are completely different from those she stated, just
because it fits their world view and gives them an excuse to talk about it.
You're right. I am probably expressing my own frustration when I imagine that
withdrawing four important RFC s a few days before vote ends has little to do
with time management issues.
Let's stay politically correct and don't express anything about the atmosphere
in the community, which has nothing to do with Andrea's decision. Anthony was
more honest when he left, but you're right, that's probably more constructive
to see people leave and say nothing. We have so many skilled and motivated
internal developers !
Yes, that's frustration. I was just trying to express something beyond 'OK, we
understand you're too busy, see you soon', but I am stopping now as you find it
*annoying*.
If YOU are frustrated, send a message about YOUR frustration. Yes, I
think there *might* be more to Andrea's decision that she hasn't
explicitly mentioned; that might be exactly what you're guessing, but it
might be something extremely personal which is none of our business.
Saying "that's enough" isn't even a productive comment. Enough what?
What is it you are asking to happen next?
So, let's take Andrea at her word, and think productively about the
implications:
Working on core features for PHP is very time-consuming, why is that?
Off the top of my head...
- 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.
- 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.
- 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.
- 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.
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.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
