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

[Jigal van Hemert]

Thanks to all who replied (and to all who didn't),

First of all my apologies for my lack of diplomatic talent. What I've 
written and the answers below are not meant as critique; I wanted to 
start a discussion which could lead to ideas for improvements.
For the best possible result it is important that nobody judges others 
(not that anybody did) and that ideas flow freely. Maybe a bad idea 
leads to another bad idea and finally to a brilliant solution.

Francois Suter wrote:
>> It's very demotivating if someone takes the trouble of writing a patch
>> for an existing problem or a new feature and the RFC is not reviewed.
>>
>> It's very demotivating if that person sees other RFCs get votes within
>> hours or days after posting it to the core list.
> 
> I fully understand your point of view. As Steffen already said, this is 
> unfortunately not a new situation, but it's true that we are very few 
> active core team members currently and that doesn't help (plus some of 
> us are concentrating on specific tasks, like Benni on the release of 
> 4.4, myself on the documentation, etc., which leaves us very little for 
> "day to day" patches).

The first part of the problem is lack of (wo)man power. This leads to 
very little time for reviewing. Any help with making patches is less 
effective (demotivated) by the lack of reviewing. And thus there is a 
vicious circle.

The real question is how to break that circle?

>> 1. As suggested by Susanne, provide a step-by-step explanation how to
>> reproduce the problem and how to test the solution.
> That definitely helps the most.

Okay, this will make reviewing quicker and make it easier to get patches 
through.

>> 2. Provide unit-tests so it becomes easier to test and review (Oliver
>> did a presentation at T3CON09 [1], although the real How-to is missing
>> from the slides)
> 
> That helps too, but it is nowhere near enough to waive patches through. 

True. It can help to identify problems in existing functions caused by 
patches. In case of code clean-ups, extended functionality, etc. the 
existing tests should still pass in such cases.
For new functions, it helps to identify parameter values which were not 
included in the tests.
It's not the holy grail, but it helps.

> Some patches are pretty. Some look very simple, but experience has shown 
> that some may have far-reaching consequences. It's often not easy to 
> judge whether a given patch can have consequences. This is especially 
> with patches that touch on versioning, localization and things like 
> TCEmain in general.

True. Don't fully rely on any helpful tool. It's just a help, just like 
a spell checker can help catch spelling errors, it will never be 100% 
correct.

>> 3. A "REMINDER" should trigger the core devs to review an RFC or at
>> least respond with remarks on what's missing, etc.
>>
>> 4. A "REMINDER #2" (or higher) should trigger someone higher (release
>> manager?) to take action. This could be assigning a core dev to review
>> it or ...
> 
> As was already mentioned, we are all volunteers, so there's no forcing 
> anyone.

The whole TYPO3 community is volunteer. You can be voluntarily be 
assigned to do something. Benni has volunteered to arrange the 4.4 
release, but I'm sure that he now feels a moral obligation towards that 
task. Of course there are (probably) no contractual consequences if he 
suddenly decides to step down, he committed himself to do this.

> I think I already said that elsewhere, but rest assured that we are 
> fully conscious of these issues and trying to improve on them, but it's 
> not as simple as it might seem.

I don't think it's simple, but it won't hurt to collect ideas. Not all 
ideas will involve new tasks for the core devs as was shown by Susannes 
suggestion for test instructions.
If all desires and ideas are combined the collective mind may come up 
with surprising solutions...

-- 
Jigal van Hemert.