[TYPO3-v4] Motivation for making patches or how to speed up the review process

[Michael Stucki]

Hi Steffen,

> Make core even more modular with sysexts. And make reviewing workflow
> for sysexts modular.

This raises the chance that someone who may notice a problem doesn't
know about that change.

> If there are too many core patches, move some part out of the core and
> put them into system extensions.

This can only mean that less people will look at it. I cannot see how
this should improve the quality in any way.

> Sysexts could have a different review workflow than core. e.g.
> rtehtmlarea already does that: Stanislas has full FYI rights, no six
> eyes needed. Nevertheless the extension is stable, because Stan is the
> rtehtmlarea expert. The same could apply to other sysexts.

Which ones? rtehtmlarea is quite special because it is almost
independent from the rest of the system. And for DBAL and t3editor we
already have similar agreements with Xavier and Tobias, for example...

> I could imagine different models where teams are built around a sysext.
> Patches for a sysext could afford one sysext team member review  + one
> non-team review.
> Non-members could proof their quality by providing good patches for a
> sysext and get invited to join the team of the sysext. (we already have
> that practice in core team)
> 
> That would break the static core member <-> nonmember structure into
> smaller, more flexible pieces.

What is the main problem after all? It's not that only core team members
know if a patch works or not. I'm very sure everyone else can do this
with similar care.

However, what we need to avoid are all sorts of conceptual breaks:
Someone may fix a problem for option A by breaking option B, because he
didn't know that option B is also possible. This can happen everywhere,
not only within new features. We need the feedback from the people with
this overall picture, and these are mainly the core team members.

- michael