Most of work is actually managing day to day communication: Answering technical questions, funneling ideas or identifying possible severe existing issues, connecting the right people to the according necessary tasks. This job can take up a lot of time during the working day, but is necessary to keep contributors motivated and pushing topics in development forward. This is not a decision-makers’ position, but more a person with a reliable time frame to be available for contributors, new initiatives etc on a day-to-day basis. We call this position the Open Development Manager. This position is open for anyone to apply, however, it should be clear that this position takes up a lot of time during daily business hours, so the employer should be involved when applying for this position.
Thanks for the insight, @benni. It reads more or less understandable.
One question popped into my mind: In the graph the “TYPO3 Strategy Group” is pictured, but never really explained in the text. It says “Core Product Team + GmbH”, but the “Core Product Team” is already “half-Gmbh”.
And is the “TYPO3 Project Leader” you?
I know it is difficult to put a “label” on the contributors (“Core Team Member”, “Active Contributor”) - now “Framework Mergers”.
Overall I did not grasp what exactly changed (apart from a different naming), as it looks pretty similar to how it works now anyway. But maybe I missed how the last two years of core development workflow went to be able to fully understand the crucial difference.
Maybe it is easier if we talk about it in person at some point.
The TYPO3 Strategy Group is something that I definitively need to clear up (and will add this), it’s basically a coordination group between TYPO3 GmbH and TYPO3 CMS Project Development, to define a bigger strategy that is not just focussed on the open source product, and see where the market leads.
What exactly changed is more like an official placement for parts that have been “attached” for a while now… Like Fluid - Claus’ maintenance job for fluid standalone did not have a special place in our roles, and opening up the parts and give them proper descriptions, permissions etc. will help a lot I’d say.
In addition, Initiatives are even more important for new functionality, as the work between maintenance and new features was very painful for most of the members - same goes with the Components - having to deal with only one part is easier for new people to join and focus on one area.
