тут всё зависит от конкретной ситуации и может быть несколько вариантов.
часто бывает, что в обсуждении конкретного issue обсуждаются и идеи, как это можно исправить
например, как здесь github.com/yiisoft/yii2/issues/10218
в таком случае, обычно отправляется Pull Request с обсуждённым решением.
иногда люди, при отправке issue, сразу предлагают в описании возможное решение, в таких случаях, если решение хорошее, делается Pull Request на его основе.
но в большинстве случаев приходится самому приходится придумывать решение.
в больших крупных проектах (да и не в крупных тоже) я видел ситуацию, когда issue на github привязывались к таскам, например, в trello, где уже было их детальное описание.
но в общем и целом ситуация такова, что вы видите список issues на github и берёте из списка открытых, ни на кого не завязанных багов/улучшений и делаете для него Pull Request
согласен, такая проблема существует.
как я сам замечал, баги мержатся напорядок быстрее улучшений, естественно, чем серьёзнее баг, тем быстрее. Баги по безопасности по опыту в топе.
данные советы как раз и направлены на то, чтобы пул риквест был рассмотрен как можно быстрее и удачно смержен.
ведь для команды увидить хорошо составленный отчёт об ошибке, толковый пул риквест с тестами к нему — это только в радость.
так всё же почему Вы выбрали такой стиль кодирования?
когда речь идёт о закрытых проектах — да, там может быть всё, что угодно, как принято в команде.
Но всё же Ваш проект в опен сорсе, его видят большое количество, которые привыкли к определённым стандартам в опен сорс проектах, привыкли контрибьютить по этим стандартам.
просто как мнение — может быть интереснее и правильнее было бы сделать этот пример, показывая, что модели эти могут иметь разные поля и как этим всем управлять
ну если рассматривать этот код как код исключительно проекта/приложения, то всё ок, согласен
честно говоря, лучше было бы оформить данный код как Laravel package, а не цельное приложение и вот там лично я бы composer.lock убрал, как советует доки по composer
ну и уже как личное предпочтение, в Laravel 5 хороший DI механизм, лично я предпочитаю его фасадам, как по мне статические фасады в Laravel было не самой классной идеей
Вы правы, насчёт того, что кроме RoR и Django нет ничего особо известного, не считая вариантов с Flask, Bottle, Sinatra
но есть такой нюанс — данные фреймворки так или иначе повлияли на имеющиеся в PHP.
та же ситуация и с библиотеками, например, behat, на который повлиял cucumber.
но я сходу не вспомню фреймворков/библиотек, на которые повлияли Symfony, Laravel, Yii.
да, PHP развивается, я как PHP-программист очень этому рад.
но иногда создаётся впечатление, что PHP играет «в догонялки» с другими языками.
а я бы искренне хотел, чтобы на PHP-инструменты равнялись, при создании инструментов в других языках
bitbucket например ;)
дело даже не в этом, Вы просто очень категорично к python отнеслись
мне как PHP-разработчику очень интересно работать с python/django, там есть чему поучится и что можно было бы применить/уже применяется в PHP мире
к примеру, тот же Symfony вдохновлён как Spring, так и Django, и Rails
часто бывает, что в обсуждении конкретного issue обсуждаются и идеи, как это можно исправить
например, как здесь github.com/yiisoft/yii2/issues/10218
в таком случае, обычно отправляется Pull Request с обсуждённым решением.
иногда люди, при отправке issue, сразу предлагают в описании возможное решение, в таких случаях, если решение хорошее, делается Pull Request на его основе.
но в большинстве случаев приходится самому приходится придумывать решение.
в больших крупных проектах (да и не в крупных тоже) я видел ситуацию, когда issue на github привязывались к таскам, например, в trello, где уже было их детальное описание.
но в общем и целом ситуация такова, что вы видите список issues на github и берёте из списка открытых, ни на кого не завязанных багов/улучшений и делаете для него Pull Request
как я сам замечал, баги мержатся напорядок быстрее улучшений, естественно, чем серьёзнее баг, тем быстрее. Баги по безопасности по опыту в топе.
данные советы как раз и направлены на то, чтобы пул риквест был рассмотрен как можно быстрее и удачно смержен.
ведь для команды увидить хорошо составленный отчёт об ошибке, толковый пул риквест с тестами к нему — это только в радость.
Я бы добавил как пример хорошего описания бага, на который недавно наткнулся, пример от SamDark
github.com/yiisoft/yii2/issues/8015
когда речь идёт о закрытых проектах — да, там может быть всё, что угодно, как принято в команде.
Но всё же Ваш проект в опен сорсе, его видят большое количество, которые привыкли к определённым стандартам в опен сорс проектах, привыкли контрибьютить по этим стандартам.
Это ведь сильно снижает читаемость кода, или нет?
Я так понимаю за счёт меньшего стека вызова, я прав?
Но как влияет хоть один из PSR на величину стека вызова?
Единственное, что школьник Саша выбрал не совсем «положительную» задачу для вычислений — подбор паролей ;)
появятся новые фреймворки, которые станут отличным примером для других языков
расширения для php писать будет ещё проще, в идеале расширения для php на php
появится строго типизированный диалект PHP — PHP++
сообщество будет расти и пополняться отличными программистами
ненавистники PHP наконец-то осознают, что PHP совсем другой, не тот, который 10 лет назад
а вообще в тему этих холиваров, PHP — Разрабатывай, Не Разговаривай ;)
честно говоря, лучше было бы оформить данный код как Laravel package, а не цельное приложение и вот там лично я бы composer.lock убрал, как советует доки по composer
1) папка vendor и composer.lock в репозитории
2) местами разный стиль кодирования, для open-source проектов лучше выбирайте PSR
3) нет тестов
4) местами макаронный код github.com/ZENLIX/LaraShop/blob/master/laravel/app/Http/Controllers/PurchaseController.php
ну и уже как личное предпочтение, в Laravel 5 хороший DI механизм, лично я предпочитаю его фасадам, как по мне статические фасады в Laravel было не самой классной идеей
но есть такой нюанс — данные фреймворки так или иначе повлияли на имеющиеся в PHP.
та же ситуация и с библиотеками, например, behat, на который повлиял cucumber.
но я сходу не вспомню фреймворков/библиотек, на которые повлияли Symfony, Laravel, Yii.
да, PHP развивается, я как PHP-программист очень этому рад.
но иногда создаётся впечатление, что PHP играет «в догонялки» с другими языками.
а я бы искренне хотел, чтобы на PHP-инструменты равнялись, при создании инструментов в других языках
дело даже не в этом, Вы просто очень категорично к python отнеслись
мне как PHP-разработчику очень интересно работать с python/django, там есть чему поучится и что можно было бы применить/уже применяется в PHP мире
к примеру, тот же Symfony вдохновлён как Spring, так и Django, и Rails