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

[Tolleiv Nietsch]

Hi - just wanted to say that I agree with the majority of your points 
and I hope people read to the end to understand that this (as most 
communication in these days) wasn't a personal thing.
Cheers.

Jigal van Hemert schrieb:
> #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".
>

-- 
twitter.com/tolleiv
blog.tolleiv.de - www.aoemedia.de