#TYPO3 Active Contributors Meeting 2013 Nürnberg ###Participants Georg Ringer, Markus Klein, Stefan Neufeind, Steffen Müller, Xavier Perseguers, Nicole Cordes, Philipp Gampe, Andreas Wolf, Benni Mack, Felix Kopp, Anja Leichsenring, Christian Kuhn, Thomas Maroschik, Olivier Dobberkau, Steffen Ritter, Ernesto Baschny ##Agenda * TYPO3 Profile * Active Contributor role + workflows * plan implementation * results * kickoff TYPO3 CMS 6.2, 6.2+x // 7.0 ##Friday 2pm start Introduction and Expectations (30') * what will happen in the next two years * motivation and vision for the future (+3) * have one road(map) that all of us can commit to * having feedback on Christian's/Tom's/Helmut's vision * what are the expectations from the new contribution process (+2) * what is the "heart" or "soul" of TYPO3? * **short and realistic roadmap for TYPO3 CMS 6.2 LTS (+4)** * find out visions of the involved participants * clearification on the "future" * focus on stability for TYPO3 CMS 6.2 * how can transition from CMS to Neos be achieved? * support extension developers for working in 4.5 LTS and 6.2 LTS * gain self-motivation again * diversity of CMS and Neos * usability targets for future versions - reduce complexity * having a productive weekend Profile of TYPO3 * "TYPO3 CMS as the cash cow" * standard solutions are missing (TYPO3 in hospital environments, etc.) Things TYPO3 does not handle yet (in a good way), but TYPO3 should do right in the next years: * Better UI for Content Management (also: reponsive UI) * Stronger Decoupling of Content and Output (Cloud-Gedöns) * Unified and flexible way of template handling * Interoperability / APIs: e.g. WebServices / REST * Theme Repository for "Frontend Skins" * More flexibility in the Backend modules * Easier modelling processes \& workflows * Simple deployment * Content deployment / Content staging * A superfast system * Management UI should be completely customizable * Workspaces handling * Languages handling * Versioning of files and data (Revisions?) * TYPO3 should be the best system for a CMS and a Web Application What about this? \url{http://wiki.typo3.org/2013} Vision Document \url{https://docs.google.com/document/d/1DEjNmKtMbNrGCzcU3RzcbvF3SbKFs1lNESqAH67s0Sw/edit?usp=sharing} ##Saturday **GIT submodule breakup**: * we decided to first do the change in "master" and have a week for people to see how it works, before doing it for the branches. * script from Tom will be run during this weekend for master * the commit SHA1 *will* change for the whole TYPO3 history as we merge the submodule commits into it. This might potentially break existing local branches, review requests and deploy scenarios which are based on a SHA1 hash. This has to be properly announced and can be tested in "master" after the script was applied. * Where can this script be downloaded/checked? ~steffeng => \url{https://gist.github.com/tmaroschik/6f1b36a71dbe0ab0e1f8} **Active Contributor Role**: * Olly explained the origin of the change and the new roles * \url{https://docs.google.com/document/d/1467-JRkizudEBjNkhHl5f7DRUXrZ0dZDNUKLtC\_8WJk/edit} * Active Contributors * Also need take part of \url{http://forge.typo3.org/projects/typo3v4-core/wiki/FriendlyGhost} * "Trust" discussed * Fields of responsability - i.e. Stan with RTE we "trust" that he does it right, so in this area he can merge right away, but still asks for reviews if he is not 100% sure. This model will be kept * Christian admits that he "bended the existing rules" in the past and asks if this will be okay in future. * In these cases, Release Manager and Leader are the first contacts for contributor and decided on demand. * "Trust" is part of the rule-set, but also assumes "responsability" and this has to be gained (we "trust" that if something breaks with a change, this guy feels the responsability to fix it ASAP) * Roles explained **Interaction (or lack of) with UX/UI Team during the last year** * Team seems to be lack personal and time resources * We don't have new designers / usability experts * Idea (Felix): we also might need some infrastructure to be able to allow designers to "test" new development (patches) * Christian notes we could need this in multiple places: travis, performance, "demo installation", ... * Idea (Felix): use more resources from the "Design Team" which seems to be working well * Helmut argues that we need to "talk" more to people. Issue Tracker is a difficult channel to reach Lars / Jens. Also would endorse the "infrastructure" need. * ("What is a team?" and "How to establish a team?" - DevDays 2012) * Having a "TYPO3 Design Bootstrap" for the backend would be helpful - showing the available and common layout components * thus we're having a basic structure that can be worked on - "unify components" * designers can then review and work on the overview of all components (e.g. like \url{http://twitter.github.io/bootstrap/components.html} ) * Benni suggests first step "clean up HTML/CSS/JS" first to be able to work upon that * Consequences * accept that UX/UI team is currently not active and needs to be triggered * do the "homework" and create a style-guide for components * implement unified components in core to ease later improvements design-wise * discuss (technical) changes with UI/UX team * discuss interaction with design team as well **Role of "Team Quality Manager"** * Christian explains his working mode (post-reviews, keeping the overview, knowing the active contributors) * In the past Stucki did that work (post reviews) * Team Leader officially nominates Christian as the Quality Manager. Unanimous approval, one abstention from voting (was in the bathroom) :) * Christian notes that he might need more help in this area, especially now with the refactoring of the Core Team. So everybody is invited to care for the "Quality" * Suggestion for further visualisation: * "Quality Reports" about the work done and being doing * Do more "marketing" around it, especially in combination with Releases **"Reverts" and the Twitter Account @t3git\_master** * We decided as suggested by Helmut that every "Revert" commit message should also contain an explanation why the reversal was done * the t3git\_master is not an official communication channel but we didn't see a general problem with it either **Role of Team Leader explained** * Defines his Co-Leader teams (Benni's word: "his harem") * About "Co-Leaders" needing to be active contributors * Definition of "active contributors" is not bound to some metric ("amount of pushes" per week). Final decision about this group is done by the Team Leader **Mentoring** * Some kind of mentoring for the new active contributors from old contributors could help (i.e. for handling the Friendly Ghost Week) **TYPO3 Developer Days 2013** * Olly will send the "vouchers" he has for the TYPO3 CMS Team (20x) in the coming day(s) * Contributors need to register with the Voucher before 14.05.2013 * Hotel: * Georg / Steffen are at Hotel Zur Altstadt: \url{http://www.hotelaltstadtharburg.de/} * Most people don't seem to have an hotel yet **Change in Pushing to Gerrit:** * Keep Change-ID across backports to older branches * Don't set the "topic" when pushing anymore to the issue number * Remind to keep "Resolves:" line in the same "block" as Change-ID (no space in between) - else Gerrit "tr:" search does not work. This is checked in the last version of the "commit hook". * We will only use "Resolves:" instead of "Fixes:" when tagging the issue in the commit message (as "Resolves" is generic enough) * Remind people to update their commit hooks if not done lately * Markus updated Wiki accordingly * Ernesto will write up an "annoucement" to the mailing list on the changes **Documentation topic:** * Christian reminds that we need to take care of Documentation efforts when merging new / changed features * Make the "commit message" already a good boilerplate for a future documentation of the feature * **IMPORTANT: **After merging, create an issue in the Doc Team forge tracker about the need to document it. * Current "How to contribute" Wiki page states the need of documenting new features, but is very strict (need to push to gerrit etc). The doc team is thankful for a review request for the documentation, but we should make at least the "Forge Issue" with the information about the new feature a REQUIREMENT to minimize the "barrier" for developers which are not very good at documenting * Clone all documentation with \url{https://github.com/pgampe/TYPO3-Documentation\_clone} * PhpStorm support for reStructuredText \url{http://plugins.jetbrains.com/plugin?pr=idea\&pluginId=7124} ###TYPO3 6.2 LTS Kick Off * **Target Audience** * casual users, and enterprise scope on top * **Goals** * Smooth migration from 4.5 LTS * no core-only thinking (upgrade has to work in real life scenarios which use several and custom extension - to a certain extend) * check several scenarios, identify most used extensions and check their compatibility state concerning 6.2 * DAM Migrations needs to be possible somehow * Define a standard set of meta data fields * Define a set of migrations which must or should be possible with the DAM->FAL Migration wizard * Advice what to do with DAM Extensions (probably replacements) * Define a set of features and availability date for media extension (part of the roadmap) * Probably: allow installation of DAM in 6.2? * DETAILED upgrade walkthrough and checklist listing the incompatibilities and breaking changes * Deliver Product that is oriented on production environment ("Production Ready") * switchable Development Context * e.g. disable deprecation log per default * "auto-configure" stuff in install tool (Christian Kuhn) * Security Standards * i.e. enforce salted passwords * Usability Improvements (Felix) * finish "low hanging fruits" * **Task Brainstorming (see below for selection and ranking)** * Compatibility Extension? * Upgrade Check Extension? * PHP Code Migration Tool? * locallang.php->locallang.xlf * Installer (Christian Kuhn) * Less dependency on core bootstrapping * auto-configuration * auto-updater (see proposal in GSoC13) * Installer must not fatal if incompatible extensions are installed * System Environment Checker Extension/Tool * Design Foundation (TYPO3 Layout Bootstrap) * Installer for Production Context (auto-configure settings) * File Abstraction Layer * How to access files via TypoScript (without using the record compat layer) * Usability of "regular files" and "FAL files" (e.g. element browser et al) * Translation of Meta-Data and Translated "Files" (i.e. "PDF file" - maybe as "variants") * DAM 2.0 / Media Management Module * Enforcement of Salted Passwords * Extbase * Workspaces read-only (> Anja, Olly) * Localization read-only (> Anja, Olly) * Import \& Export Module in Backend * IRRE \& Nested Data-Structures * File Abstraction Layer Structures * revamped file transfer * Workspaces for IRRE \& MM * UUID support ("low hanging fruit") * TypoScript support * Package Manager Core (Composer base-support) * Functional Testing Framework * Finish Logging integration * Deprecation Logging * PSR-3 Compatibility? * Syslog Writer (to re-use the existing BE-module as an intermediate solution) * Concept \& decent default configuration * --- * Graylog Writer ("Enterprise level logging") * New Logging Module using the new API * Replace all old logging calls in Core with calls to new API * Exclude sys\_history from logging * Best Practices * Config for * Dev * Prod * Stealth * **Marketing** * Catchy Vision: * most stable and most secure TYPO3 * tested quality / future proof * fast, easy, powerful * Gather all features that were introduced from 4.5 up to 6.2 to sum up the benefits for a LTS->LTS upgrade Statistics: * MacBooks: 7x * Non-MacBook: 11x **Ranking of the tasks (voted in the team)** * **Tasks** 1. **11 - File Abstraction Layer** 1. **10 - Upgrade Check Extension?** 1. ** 7 - Design Foundation (TYPO3 Layout Guide)** 1. 6 - Installer for Production Context (auto-configure settings) 1. 6 - DAM 2.0 / Media Management Module 1. 5 - Installer must not fatal if incompatible extensions are installed 1. 5 - Package Manager Core (Composer base-support) 1. 4 - Extbase (workspace + localization read only) 1. 4 - Workspaces for IRRE \& MM 1. 4 - Functional Testing Framework 1. 4 - Finish Logging integration 1. 3 - Enforcement of Salted Passwords 1. 3 - UUID support ("low hanging fruit") 1. 1 - Compatibility Extension? 1. 0 - PHP Code Migration Tool? 1. 0 - Import \& Export Module in Backend ###Initiatives and "fields of responsibilities" Must Haves: * FAL / DAM (**Andreas Wolf**, Oliver Hader, Helmut Hummel, Felix Kopp, Benni Mack) * Upgrade-path (**Steffen Ritter**, Anja Leichsenring, Nicole Cordes, Markus Klein, Xavier Perseguers, Helmut Hummel) * Installation / Auto-Configuration (**Christian Kuhn**, Anja Leichsenring, Nicole Cordes, Markus Klein) * Package management (**Tom Maroschik**, Christian Kuhn, Steffen Ritter, Xavier Perseguers, Helmut Hummel) * Usability Foundations (**Felix Kopp**, Georg Ringer, Steffen Ritter, Benni Mack) Should Haves: * Workspaces/IRRE (**Oliver Hader**) * Extbase (Workspaces) (**Anja Leichsenring**, Oliver Hader) * Logging (**Steffen Müller**, Markus Klein, Georg Ringer) * Enforce saltedpasswords (**Nicole Cordes**, Helmut Hummel) * Functional Testing Framework (**Helmut Hummel**) Could Have: * UUID Support (**Tom Maroschik**) * Compatibility Extension (Oliver Hader) Won't have this time: * PHP Code Migration Tool * Fix Import/Export Module General Reviews (Philipp Gampe, Stefan Neufeind, Xavier Perseguers, Christian Kuhn, Wouter Wolters) ###Vision for 6.2 LTS * User Happyness * Smooth Migration * Modern Foundation ##Sunday ## Organizing "task forces". Tasks will be organized in "Initiatives" with groups working on it. Life-Cycle for 6.2 and later discussed * Concentrate on 6.2 now * 6.3 half a year later after 6.2 LTS release would probably make little sense, since it will be a very unused (as 4.6 also was). * So after 6.2 LTS we might want to make a larger gap of one year for developing new features / "experimental" features * To denote the introduction of new "experimental" features, we might * 7.0 release with newer "experimental" features * we start development for 7.0 with 6.2-beta1 or 6.2-RC Vision and Roadmap Document * Abstract (for decision makers) * Benefits explained * Reuse ready Flow components in TYPO3 CMS Core (no more "backports" i.e Caching Framework) * Enable to integrate Flow projects / packages into TYPO3 CMS projects * PHP Standards: easy integration of external PHP packages (i.e. integrate Symfony projects) while maintaining backwards compatibility with TYPO3 Extensions * Allow TYPO3 CMS to be used as an application framework * Share of time and competences * Bring community together, more contributors to Flow * Roadmap (what steps need to be taken in detail) * 1) ... * 2) ... * ... * ...) CR with compatibility layer? * ...) "Neos-like" or not far anymore * TODO Helmut: prepare the "split up" document until our meeting * Meeting at 10.05.2013 at 14h00: Helmut, Ernesto, Christian, Tom, Benni, Olly Submodules * Previous discussion concerning changes and namings * \url{https://notes.typo3.org/p/renaming-technical-todo} * Next steps / TODOs * Create new Git repository **git.typo3.org/Packages/TYPO3.CMS.git** * Check testbed \url{https://github.com/tmaroschik/TYPO3-Core-Without-Submodules} (play with blame \& log, diff filesystems to verify code is identical) * Adapt travis-ci.org for new repo * Jenkins job to mirror repo to github (grunwald / trabold / stucki / gebert) * Check, if gerrit hook for forge works * Forge work (repo links, ...) * Write announcement. Draft: \url{https://notes.typo3.org/p/TYPO3CMS-Submodule-Merge} Olly updated the Forge Core Team adding the "Active Contributors" as discussed. They can now merge into the Core.
{}