Protocol of Team Meeting during T3BOARD12

By: Oliver Hader

During T3BOARD12 in Laax/Switzerland there was a spontaneous TYPO3 v4 Core Development Team meeting. Albeit not the whole team could participate, the 13 participants took the chance to discuss several topics and come up with accordant suggestions.

Protocol of the Core Team meeting(s) in Laax 2012

March 1st & 2nd 2012, 5:00pm-6:30pm CET

Attendees

Oliver Hader, Steffen Gebert, Steffen Ritter, Xavier Perseguers, Susanne Moog, Michael Stucki, Helmut Hummel, Georg Ringer, Peter Niederlag (only first meeting), Ingo Renner, Christian Kuhn, Jens Hoffmann (only second meeting)

The protocol is recorded by Helmut Hummel.

(New) Version Scheme

There had been quite some confusion and a long discussion in the internal core list about the proposal by the Steering Committee to change the version number scheme of TYPO3 v4 and the naming of that version and the upcoming Phoenix release. Nobody of the core team disagreed on the second proposal on the list.
That's why Olly asked again if everybody would agree on the fact that at some point there could be a 6.0 Release of TYPO3.

Every attendee agreed.

Steffen Gebert pointed out that having FAL in the next release could justify a 6.0 and we had the chance to do further clean-ups and breaking changes that never had been possible before a new major release.
Stucki pointed out that we need to keep the LTS strategy in mind. In a short discussion we agreed that a LTS version cannot be a X.0 but rather a X.2 or X.3 which means that the 6.2 or 6.3 could be a LTS again if we would start with a 6.0 with the next release.
Peter agreed on the 6.0 topic and in the same time resigned as an active Core Team Member and told us he will be officially inactive from now on, but would love to stay on the internal core list. Everyone thanked Peter and stated to be fine having him on the internal list.
Xavier asked the question what this would mean for the release cycle and it has to be clearly decided and communicated what makes a new major TYPO3 version. We discussed this as a separate topic.

Release Cycle

We discussed if we should change the 6 months release cycle as versions are currently popping us very fast and we also almost never could really release in 6 months anyway.
Although we agreed that 6 months is not very much if we take the holiday times into account but in the end all agreed that we still like this rhythm and would like to try to have an April and an October release. Doing so we must assure that the Core Team will not only meet in spring/summer, but also in autumn/winter and that we do more code sprints for the Winter release because in that time no other TYPO3 meet-up is taking place. We also agreed that we must not fear a "zero feature release", because even if one version does contain less features it's still good to have it.
We shortly talked about always branching master after the first beta like we did for 4.7 now. We will see if this turns out to be good.

While discussing the release cycle we also talked about future security releases. We all agreed that a security release will be based on the last regular bug-fix release, thus not containing other fixes than security fixes (this has already been published on the core list in some release minutes some time ago).

Release Manager

Helmut has been suggested being the release manager for the next release. He will be supported by Susanne Moog and Christian Kuhn.
All three take the responsibility for this job if the whole (or the majority of the) core team officially agrees. A voting date has not been set up yet.

Possible Feature Set for a 6.0 Release / Roadmap

While brainstorming several possible features for a 6.0 release, we discussed if we could make the next TYPO3 release a 6.0.
We agreed that we should not be tempted to try to put "everything" in a 6.0 and then failing to deliver it in a reasonable time.
Also having FAL in place, which on one hand is a major feature and on the other hand has the potential to break a lot of extensions with the addition that it has been promised for the next release we came to the conclusion that it would be good to have a 6.0 instead of a 4.8 for the next release.

When discussing which of the brainstormed features could be done in 6 months, Jens made the point that a 6.0 must incorporate visual changes and "end user features" to be a real major release.
While we agreed on that many team members raised concerns if we could really revamp the whole back end in such a short amount of time.

Nevertheless we tried to identify which brainstormed feature would be doable in 6 months. The list with the features along with responsible persons (if we already have any) will be posted separately.

Internal List

Everybody in the core team already agreed, that we should discuss more things publicly instead of on the internal list and in general communicate more often about the things going on.
Francois once put it this way: "If a team does not communicate, it does not exist." which pretty much is the essence of the problem not communicating.
So we need to define which topics should be public and which ones should only be discussed internally.

We agreed on the following:

Everything should be discussed publicly on the typo3.core list except:

• pretty much all organisational stuff (e.g. travel costs, organisational things for meetings ...)
• really private things (e.g. PHPStorm licence)
• personal things
• highly controversial topics (like changing the version numbering scheme)
• if in doubt, post first internal and if everybody is fine, the discussion can be moved to a public list.
  

This is a bit overhead and requires a bit discipline. Any "fight" between core team members should be avoided in public discussions. We should act and communicate as a team in the public.
Reading the core-internal and the public core list on a (almost) daily basis should be self evident for every core team member

Team Clean-up

First of all it has been pointed out that there are former/ honorary members of the core team which are clearly not part of the team any more, and currently inactive members.
Like Francois suggested some time ago, we should have a place to mention former/ honorary members to thank them for their contributions.
This topic is about core team members which are still officially part of the team despite lack of activity.

The core team has many members, but the members are not equally active. In fact some members did not contribute (neither code wise nor otherwise) for quite some time.
This is why Olly suggested to do some "team clean-up" and officially mark not contributing members as inactive. Inactive members will not be invited to meetings and cannot claim money from the budget. (Did we talk about commit rights?) Nevertheless every inactive member can become active any time if he/she starts contributing again.

This is a delicate topic and we had a slightly heated debate about if and how "contribution" could be measured to avoid marking somebody inactive only out of a personal dislike.
Since we are a development team code contributions are the most obvious criteria. This is why Olly will get some metrics out of Gerrit which will be the initial indicator for an inactive team member.
Nevertheless it still will be a case by case decision whether one will become inactive or not.
Olly will ask the members identified as inactive if they are fine with changing their status to "inactive member". For the case that the person disagrees, Peter made the suggestion the whole team votes (anonymously) for each person. But we have not decided to really do such a voting.

In any case any inactive member can of course become a regular member again by starting to contribute.

The "team clean-up" will happen next month. Olly will be responsible for this.

---