What is your idea about?
Make upgrades easier with support by typo3-rector, thus keeping TYPO3 instances on a working and current code base.
Typo3-rector takes the already existing extension scanner of the core to the next level as it does not only scan, but also apply the necessary changes if possible.
Extensions can be easier upgraded to newer versions and their code bases kept up to date all time.
What is the potential impact of your idea?
The overall TYPO3 extensions eco system can be easier maintained/upgraded to newer core versions.
It is easier and faster to evaluate and execute necessary changes, caused by changing LTS version.
Typo3-rector is based on the official changelog, so the value of the docs increases and provides a useful combination to learn new functionalities inbetween versions (thus providing useful knowledge for certifications)
In general time is saved which is making upgrades more affordable and TYPO3 more competitive.
Who can / should implement your idea?
I will take care along with Sebastian Schreiber, the main developer, and others of the TYPO3 community
thank you for your application. The goal of the TYPO3 Association is to reduce the amount of money spend on worktime for code. Instead the money should be used to enable people to be part of teams or to enlarge the community. Can you please explain why -in your special case- money for code should be spend?
With the upcoming v12 branching and its breaking & deprecation changes, there will be a lot to do again with the possibility of creating new rules, which would need the guidance of Sebastian - this is time intensive, but gets community members easier into TYPO3 upgrades and the core in general.
You could take me as an example, who contributed more for the core and detected bugs or documention flaws simply due to the time is saved with rector. I had more time for learning and reviewing the code instead of writing it on my own. This led to more reading the docs and detecting issues within it. Also it prepared me a lot more for the certified dev exam (outstanding in my case) as rector changed code segments i would never came across or notice that it changed.
In general it brings much value and fun, along with less frustration.
I cannot speak for the deciding people, if the overall target of increasing teams or the community is met enough with this added value. But i’m already happy with having the chance to present this application.
A general “community enriching” value i would see is the reduced inhibition due to “complex upgrades”.
Maybe we bring rector far enough so you could say TYPO3 upgrades are close to automatically done, which would prevent customers, CEOs etc. from being afraid of necessary big budgets for keeping the system up to date.
This can increase the community by eliminating one often named “pain point” in decision making.
This is so important. Rector saves our community members massive amounts of time when they upgrade their projects and extensions, and being able to work efficiently with the product is very helpful with developer retention.
I think that TYPO3 Rector is one of the best framework specific libraries, if not the best library, in the Rector ecosystem. We were able to increase the visibility and awareness of TYPO3 in the broader PHP community a lot. Sometimes coding itself is the best marketing you can do in our technical driven industry.
I just had a monthly call yesterday evening with french TYPO3 agencies community members, and the thematic was Rector. I just wanted to let you know that we all agreed on that:
1 - agencies are more competitive when they sell TYPO3 migration
2 - developers don’t stress anymore when they think about migrating big projects
3 - some of them even implement Rector in their CI to anticipate compatibility
4 - having TYPO3 community members making such bridges in other important ecosystems increase TYPO3 visibility
