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 <franc...@php.net> wrote: > > De : Rowan Collins [mailto:rowan.coll...@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 > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
