[TYPO3-v4] Minutes of the 10th meeting of the 4.7 Release Team

[Jigal van Hemert]

#Because of problems with Thunderbird I'm not sure if it was sent at 
all; mailarchive at lists.typo3.org shows only one message in this group 
for february... sorry if it's sent twice!#

Hi,

First of all, if I mention someone's role I am not targeting at the 
person who has that role currently. It may be about the way that a role 
functions currently, but it should not be seen as a personal attack.
Please, also read to the end before answering parts of this post.

On 30-1-2012 20:34, Steffen Ritter wrote:
 > Am 30.01.2012 19:37, schrieb Steffen Gebert:
 >>> TYPO3 4.7
 >>> > ==========
 >>> > Nothing special has been discussed about TYPO3 4.7.
 >>> > The FAL Team - currently meeting up at Stuttgart B:Dreizehn GmbH -
 >>> > announced that they plan to push the first patches within this week.
 >> Seriously? "Nothing special"? We have two weeks until Feature Freeze and
 >> it feels like development of 4.7 hasn't been started at all.
 >>
 >> What's with all the other BLE tasks?
 >
 > What exactly do yo mean?
 > - the whole Frontend/Accessibility stuff is already integrated
correct

 > - external Extensions have been releases do TER
I must have missed that in the weekly minutes.

 > - FAL - biggest solo part is on work right now
I have asked questions about this one earlier, but there was never a 
clear answer: FAL is part of BLE; BLE is finished as a paid project and 
delivered to the client; why does it need so much work to move it from 
one branch (the incubator) to another branch (the core master)? If it's 
ready (= done done) it should be a matter of some git magic and maybe 
solving a few conflicts.

 > - Government Package is not related to a Feature Freeze

It's not??? If you want to present it with the release of 4.7 it should 
be tested as part of 4.7. In that case it is related to a Feature Freeze.
If it's not subject to the Feature Freeze I can predict the result 
already: the final package contents are ready a few days prior to the 
release of 4.7. Everybody is busy with the last bugfixes for this 
release; nobody takes a look at the Government Package.
After the release government bodies take a look at the package and find 
bugs and problems (simply because it wasn't tested in a lot of different 
environments). How does that make TYPO3 look for Government bodies?

 > The ExtJS 4 migration has been dropped and reverted. Therefore the whole
 > VIDI, and new File-Module, Custom Record Tree ist out of scope.

There are still questions about how this happened. The ExtJS 4 migration 
was not part of the BLE project, yet there are three subprojects who 
depend on this !?!?
If they were completed and delivered (= done done), how could it be that 
nobody (neither developers, testers and client) didn't notice that the 
rest of the TYPO3 backend had serious problems because of the ExtJS 4 
migration?
It wasn't about a list of well hidden features which didn't work any 
more; the page tree, the extension manager and loads of other often used 
parts were broken.
It simply against all logic that the ExtJS4 migration was not part of 
BLE, yet three parts of BLE depended on it. Then you either can't 
deliver these parts because they don't work with ExtJS3 or you can't 
deliver these parts because the ExtJS4 stuff they need breaks the rest 
of the BE. It just doesn't add up somehow...

 > The one outstanding Topic is the Console-Application. Which indeed is a
 > standalone product which would need an init.php Refactoring which Oliver
 > Hader did...
 > This would has been working for the time of the BLE close-up. The
 > reasons why Olly never pushed it to Gerrit are ? I do not know :P

Why do you not know? Olly is the v4 Core Team leader, which means that 
you have regular meetings with him. If the Console-Application was on 
the list of features for 4.7 you must have discussed it with him, I guess...

 > Then there are Grid-Elements. Which are finished and released to TER.

Tolleiv asked if the was the extension 'gridelements'?
This is "just" an extension. I can understand why some functionality is 
not in the core, but there is no way that this can be presented as a 
core feature:
- it's not shipped with the core
- it's registered to a person (two authors mentioned), no sign that 
anyone from the core team is somehow involved or related to this
- there is no manual
- nit picking: it doesn't comply with CGL ('#' comments)
 From my experience it shows Joey is very dedicated to TYPO3, but as a 
personal extension no core team member will feel responsible for this 
extension.

 > As it applies for all projects - especially the last 3: At the end the
 > contributors within the teams have to request their stuff to be
 > integrated or push something.
 > We - or better I - just can follow up on them and keep Track. But It
 > makes no sense to write "nothing new from this project" every week.

I disagree here. We have a couple of 'manager' roles; a core team 
(co)leader, a release manager, a community manager. Manager don't just 
observe, they manage. If there is no progress they should investigate 
what the problems are and how they can be solved. If more man power is 
needed they should act and see how this can be made available.
Publish lists (not too long) with things you want to be done, ask people 
if they can do parts of these things. If it is about paid development I 
can imagine that also some people are hired to test the stuff thoroughly 
to get it merged.

Could I do a better job managing this? No, certainly not. I'm not the 
manager type. Steffen Gebert mentioned that nobody cared for felogin any 
more, so I took a look at a few dozen bug reports, pushed a series of 
patches. And unfortunately hardly reviews. The few reviews that were 
made were mostly by reading only (which is completely useless in most 
cases IMO; hardly anybody will only test a patch without reading the 
code, so it doesn't add much to the voting) and the negative ones that 
asked for minor changes didn't bother pushing a new version (what about 
the "patch for a patch" rule we had?).

Yes, I'm worried about the progress too. Unfortunately I think the 
problem is not only with the developers but also with the management.

 > But you're right. Somehow it feels like development never started...
 > Look at how many people will attend the Developer days, look how many
 > pages have been submitted and reviewed. And read how often we adressed
 > lack of man-power during development.

Talking about these things doesn't help.

 > On the one hand there are complaints that nothing happens, on another
 > hand there are no reviews and a third position is, that the stuff which
 > has been done, get's merged so fast.

I'm guilty of all three:

- I do see that nothing happens, but on the other hand I also see that 
not enough is done to get things moving. Let's be blunt: during 4.7 I 
have hardly seen lists of issues which needed TLC, during 4.7 I haven't 
had a single request to do a review or make a patch. 4.5 and 4.6 were 
kickstarted during a core team meeting and there were sessions to list 
features for these releases and form teams to realize them. 4.7 had the 
bad luck to start without some form of meeting (even not in a list to 
have a discussion about what can be in this release). It was presented 
as "standards and accessibility" and the main features were from the BLE 
project.
Most of the BLE development took place outside the community by paid 
developers and some parts were moved in the core using the "fast way". 
This was done by following the rules and procedures for it, but the 
result is of course that there is very little community involvement. If 
there is not enough communication around it (buzz, postings, etc.) and a 
few of these features had undesired side effects it is not surprising 
that not too many developers feel part of these features.

 > Looking at the pending stuff for FAL-branch which already is in Gerrit
 > since weeks and noone looked at it I wonder how the really big parts
 > should get through if the authors of the different parts not just vote
 > for each other?

As said before, if things need to be done then there is also a part that 
the managers can play in motivating and mobilizing people to do this.
I don't do hardly any reviews. The reasons are simple:
- in many if not most cases patches do not apply easily for me. Yes, I 
know it's me that is incompatible with git; I'm slowly reading a book on 
it, but so far it hasn't helped me fighting the mysterious messages I 
get when trying to do anything but the simplest things.
- I could review the patches by reading. As said before that is hardly 
useful IMO. Only in a few cases you can do a review by testing without 
reading it.

Until my relationship with git improves substantially I will stick to 
making patches. There are indeed a few of my patches which linger in 
gerrit for months. This is hardly motivating

 > We started with a vision and arrived in Reality. That's hard, but I
 > think this is a lesson you have to learn in a unpayed community driven
 > ecosystem.

I don't think you are completely fair here.
There is another motivation then money for many developers. Achieving 
something great together as a team can be very rewarding. Maybe we need 
a bit of team building and more direct communication. The 'management' 
is also the glue which holds a team together, it should provide vision 
for the future, motivate people, etc.
For this release you don't rely entirely on an unpaid community. The 
features from the BLE project (a large part of 4.7) were paid and were 
supposed to be included in the core. If these paid developers do not 
deliver parts that can be included in the core the job isn't finished.

This may sound like a list of harsh criticism. Please don't treat it 
like that. It isn't about persons, it's not about evaluating if someone 
did a good job, it's only about finding which parts of the ecosystem 
need improvement. Everybody makes mistakes, every developer introduces 
new bugs. The important thing is that we see what goes right and that we 
learn from our mistakes. As a team we should learn how we can prevent 
mistakes from leaving "our kitchen".

-- 
Kind regards / met vriendelijke groet,

Jigal van Hemert.