# TYPO3 Active Contributors Meeting 2014 Nuremberg ##**Monday, March 31st 2014** ###**Short Term Decisions** Branching TYPO3 CMS 6.2 * keep master branch for TYPO3 CMS 6.2 for the next few weeks * possibly branch of TYPO3\_6-2 after the code sprint in Bremen (May 2nd-4th 2014) * Ernesto is going to coordinate pressing issues for TYPO3 CMS 6.2.1TravisCI bot voting in Gerrit * share experience with TYPO3 Flow/Neos team about integration and high pace during code sprints * running tests on our environment needs to ensure, that tasks cannot be hijacked and misused from spammers * if travis runs for each patch set, the service should just vote down in case of failures, but no positive votes * thus, the regular voting process by human beings still appliesTravisCI integration in general * maybe the code-sniffer execution can be integrated into TravisCI as well * Christian and Stefano are going to evaluate whether this is possible (note from lolli / stefano: it is probably not too hard to do the sniffer stuff in travis) * the functional tests need to be enhanced in terms of speed (note from lolli: that is probably harder) * Helmut and Christian are going to evaluate on this (note: we will push at least a patch to get rid of failed builds due to starvation)Friendly Ghost * Jigal mentions that he gave up on this topic - too many reminders were required without any action * Helmut mentiones that the "friendly ghost" could be replaced by "field of responsibilites" or a team of friendly ghosts * Christian says, that acutally not many people directly popped up with "hey, I'm new and want to contribute to TYPO3..." * thus the visibility of the friendly ghost failed in a way * Stefan N suggests to have two groups of people, maybe triaging and fixing * Philipp mentions that not all contributors are used to the Gerrit workflow, but are giving feedback or putting patches directly to Forge * Fabien suggests to have Forge/Gerrit statistics public available * Mattes raises the question about the actual scope of friendly ghost * closing bugs shall happen automatically after 90 days if there is not feedback and the status is on "needs feedback" * **@todo:** create text snippets for that - suggestion: \url{https://notes.typo3.org/p/typo3cms-forge-nofeedback} * fields of responsibilities ("competences") needs to be more public * should be mapped to forge categories for easier association * Felix points to the PSL as a last instance if something does not get fixed * categories must be re-checked and cleaned * use "community contact" like in TYPO3 Neos team * this means * community contact (people from the outside) * bugs triaging (not assigned yet) * field of responsibilities * automated closing of bugs * cleaning up the categories * closing issues in Forge with unsupported versionsA-Badge-Extension ("A-Class-Extension") * \url{https://notes.typo3.org/p/A-Badge-Extensions} * instead of some official group judging an extension, there are basic rules for the badget and up to the community to actually control whether the rules are followed * Philipp mentiones that implementing this would not be of a problem for the TER team * Tom suggests to have an online checkbox form that extension developers need to agree on * foertel says that there should be a time-limit for the badge - thus, after e.g. one year the badge needs to be renewed to ensure continuity of a particular extensions ###TYPO3 CMS 6.2 Retrospective * Ernesto shows the development phases and gives some statistics about the code sprints * the conventions for reverting issues and how to communicate about and how to ensure issue documentation are shown * feedback round on positive and negative aspects during the last few years (4.5 to 6.2) * Achievements: 13+ * Workpackages: 7+ * Communication Channels: 3-, 1+ * LTS Release vs. Service Packs: 8- * developer view * agency/marketing view * problem of the "lean back for three years" approach * communication, actually next LTS development starts right now * Enhancements for End Users: 6- * Feedback from Community/Agency: 3-, 1+ * Release Manager: 6+, 1- * Team Culture: 5+, 6- * Common Concepts \& Vision: ###TYPO3 CMS Future * Why are we working on TYPO3 CMS? * Are we feature complete? * Are we stable? * Why should agency invest time and money into TYPO3 CMS in the future? * Does it make sense to push agencies towards TYPO3 Neos? * Splitting up into groups and imagine the situation in three years (each group is answering the four questions) * **Why should customers build on TYPO3 CMS then?** * lots of satisfied customers that are still statisfied with TYPO3 CMS then * USP are flexibility, interoperability, backwards compatibility, TCA/Extbase * TYPO3 CMS has a broad eco-system with a large base functionality * TYPO3 Neos still needs time to evolve and TYPO3 CMS is established in the market * if the UI is mobile ready, everything is still fine * customers with large amout of content and custom applications still need TYPO3 CMS and benefit from the structural design (backend/frontent, pagetree, etc.) * **Why should we as developers contribute to TYPO3 CMS then?** * since we still use the produce, we still contribute to it - in terms of knowledge and tools * it depends on the vision for TYPO3 CMS (features or maintenance mode) * it depends on whether one still earns money with it * trust and commitment inside the community to solve even complex task * because it has great documentation (then) * it depends on whether TYPO3 Neos is a competitor that solves the demands of current TYPO3 CMS * some side questions * can TYPO3 CMS co-exist besides TYPO3 Neos * is it healthy that TYPO3 CMS is developed further besides TYPO3 Neos * shall TYPO3 CMS concentrate on a more specific market (which problems can be solved by which product) * we must not head into the same direction like Neos * if we concentrate on TYPO3 Neos, large parts (DataHandler etc.) is not taken care of * if we consider TYPO3 Neos as competitor like Drupal or Joomla, we still continue * knowledge - we know the project very well * still a lot of enhancements are possible - we identified the drawbacks already * because there are still a lot of possible achievements and enhancements * there is an open-minded community and it is actually fun to contribute and participate in code sprints * **What makes TYPO3 CMS unique at that time?** * it's the most mature CMS * it's the last monolythic CMS at that time * still many fans and enthusiasts * TYPO3 CMS has a broad eco-system with a large base functionality ("it's reliable") * integrators can solve almost 90% of the tasks without writing custom applications (just by plain core functionality) * backwards compatibility \& upgrade paths * TCA is awsome and flexible! * we can write books about the system (editor knowledge is reusable, training once means trained forever) * any trained integrator can work on any TYPO3 installation * community, spirit and the huge amout of events * TYPO3 CMS is a real community driven project, there's no company steering the project * **Do we see TYPO3 CMS phasing out then?** * no - but maybe in 5-10 years - maybe depends on next LTS that still satisfies user requirements * TYPO3 CMS might be a fail-safe CMS in case TYPO3 Neos fails * TYPO3 Flow and Neos are not looking back in time (e.g. "Berlin Manifesto") * no - there will be a TYPO3 CMS in 3 years - otherwise we cannot sell TYPO3 nowadays * no, not at all * no, not in 3 years, but maybe in 5 years - which depends on the acceptance and adoption rate towards TYPO3 Neos * in general we see a possible movement either towards TYPO3 Neos in the future, and if that fails, a movement to some other project * General * maybe it's not possible that agency tell the community, what needs to be done - but the other way round * how do the problems of our customers change during the next few years? ##Tuesday, April 1st 2014 ###Flash-Light session "how do you feel today" ###Community Communication Mattes is showing the main results and learning from the Altleiningen communication workshop in November 2013. In general problems boil down to self-reflection of own actions that lead to a situation, then maybe stepping down, being humble, agree to disagree in the end (which is quite natural for individuals) or to just accept other opinions. note: would be cool to have the slides somewhere ###Mid-Term Topics UXW2014: will happen, Jens will still organize it. Help offered by Felix and Ernesto. More news on that starting in May. Will most probably take place in October or November. ###Rolling Releases Tom is presenting the idea behind the "rolling release topic". The cycle consists of "development", "release" and "feedback" with the feedback round being the most important part here. The whole process is related to continous integration process, where artifacts are e.g. created on a daily basis. The questions are raised what running a "rolling release means" in terms of completely testes code and behaviour. In order to get this cycle faster deployment, updating, migration and eventual rollback have to be automated. It's required that the core has upgrade and downgrade wizards (not only doing dump files of a current state, but having the possibility to rollback an upgraded and modified data-set). The most interesting and possibly problematic parts are custom applications and extensions - thus API versions need to be in place. Benefitial is the process because of the gained knowledge about the whole deployment, update, migration and eventual rollback process and casted into code, which represents the knowledge. The processes have to be changed from former implicitly defined (manual steps) to explicitly defined (automatic steps). This leads to a standardization of these across the users/agencies. These could also contribute back and improve the processes for all stakeholders again. Helmut points out, that either way, we need a complete documentation about what has been changed and have these changes covered in automated tests, upgrade and rollback services. This is valid as well, if we won't follow the "rolling releases" way. ###Release Cycles \& LTS Releases For agencies and customers it's basically important to have a reliable and stable core that gets security fixes when required. Besides that, it happend during TYPO3 CMS 6.2 development, that agencies still build websites with TYPO3 CMS 4.5, since it has been the recent LTS release being available at that time - even if the version was out-dated in terms of technology. ###Discussion groups on future topics * Editor Enhancements \& Usability * Vision: "Improve workflow for every-day users" * feedback from editors * ask agencies with own editor groups for accordant feedback (@todo: Nicole \& Olly directly ask "their" groups) * more user friendly backend design * better styling/theming (e.g. "flatdesign" extension as basis) * follow mailing lists (e.g. "English/German List") concerning topics and expectations * UX backend * in general reduce the possibilities and streamline them * avoid frames in general to be ready for mobile touch devices * features/changes * improve search/auto-suggest wizard to actually deliver correct results * drag and drop clipboard functionality * frontend editing * solve the problem of content origin (e.g. Fluid rendering does not include the data origin to e.g. "tx\_myext\_table with uid 13" * ViewHelpers are required to have the functionality of TypoScript's "editIcons" * enhance the whole interface with a toolbar * maybe evaluate on Aloha again * backend page module * on creating new contents, the wizard can be replaced by a toolbar (e.g. like in GridElements) * the localization handling and representation can be enhanced in general * better visualization/integration of "other" records on a page (avoid switching between page and list module, just for the sake of finding those records) * revamped task center module * have it more role-oriented * have tasks that are required to be done (eg. "localize these new content elements from English to German") * interaction with a dash-board * integrate an additional backend user level for "super editors" (not an admin, but not just a simple editor - permissionwise) * integrate a possibility to directly simulate a particular frontend user, not just the group (MaBaHe mentioned he has a solution for that) * better workflow system and visualization in the frontend (non-technical, but concentrated on the actual content change) * versioning for file contents (binary data) * functionality like in GridElements/MultiColumn - easily breaking out of the defined column concept on demand * consistent and common trees * Element Browser * Category Tree * File Tree * Page Tree * Content \& Structures * Vision: "TYPO3 is a data management system" * Strength (page structure), visible elements (localization), but record management in the end. * Record management module (bring list module to next level) with the possibility to have mass manipulation possibilities with predefined filters, facettes and types as a central place (annotation: e.g. like "vidi"). * i.e. could be used in syslog viewer, beuser admin and many more modules * Felix Kopp mentiones that this component needs to be able to handle structured data and large amounts of data as well (eg "load more" functionality) * Compatibility \& "Rolling Releases" * three major tasks * communication * information: past, present and the future - tell about the "why" and the benefits * target groups: "skippers" only upgrading from LTS to LTS and the early adopters * internally: raise the requirements to avoid that current development state (master branch) can be broken * announcement/documentation: give examples of different scenarios and the possibile impact * technical * increase testing framework coverage \& pre-merge checks (TravisCI running tests before the actual merge) * mid-term: add some layer of behaviour tests (behat ....) * metrics around "risk of changes" / identifying hot spots in the code to automatically evaluate risks * infrastructure * upgrade-script / scheduler task performing the upgrade, execute migrations, test the involved installation, report on problems, roll back if neccessary. * TER should support branches / composer support * Extension Manager needs to be adapted to filter available extensions and deal with the snapshot releases * Architecture \& Technology * Vision: "Be a good web application framework for your web application" * looking to others (Neos, Drupal, Joomla) using or building a framework * doing really good mobile UX * scalability * being ready for the cloud * CQRS approach to overcome the LAMP stack limitations / stack flexibility (choose the right tool for the job) * detach from the current SQL storage * support alternative PHP runtime * Community, Team \& Communication * strengths * social skills - being nice and respectful toward others * trying to avoid rules, but eleborate on guidelines and are open for any input * all of our actions should be inclusive (eg getting feedback from agencies, editors, etc.) * enormous knowledge inside the community * having the ability to discuss thing on a technical level (like in Gerrit, commenting and voting on changes) * weaknesses * language barriers * communication between teams could be improved * communication style within the teams sometimes can get rough * communication to the outside could improve * future * create awareness of communication issues to foster changes (i.e. workshops during events) * write down some guidelines for communication (one cannot force somebody to do things) - \url{http://typo3.org/community/code-of-conduct/} * improve communication between teams which need to work closed together * having a community contact for TYPO3 CMS (like Christian Müller does for TYPO3 Flow/Neos) * having TYPO3 Planet for collect contents from the community and present that knowledge to others * work on a "Values" for the CMS team, or adapt the Neos ones if they fit: \url{http://neos.typo3.org/contribute/values.html} ###Doctrine DBAL Integration Stefano is showing the aims and progress on Doctrine DBAL integration into TYPO3 CMS. Stefano basically finshed the practical part and is currently writing the thesis - which will be done by end of May 2014 and will be available for the public then. The extension: \url{https://github.com/Konafets/doctrine-dbal} The modified core: \url{https://github.com/Konafets/TYPO3CMS-DoctrineDBAL} During the presentation the topic of general Doctrine integration and general integration of TYPO3 Flow popped up and has been shifted to some other date for further discussion. ###Media Management Module Fabien is showing the current status of the media management module. ##Wednesday, April 2nd 2014 ###Security Workflow \& Interaction * current workflow * there is a mailing list for TYPO3 CMS security and active contributors (called "core team members" in the past) * issues are collected in a private project on forge.typo3.org * changes are collected in a private Git repository on review.typo3.org * if a particular fix has enough votes, it's not merged, but cherry-picked on the upstream branch on the release day * after an issue has been resolved and releases, the issue still stays private to avoid direct exploits * but at a certain time later, the issue can published - assuming that enough time passed by, that sites have been upgraded * priorities are defined in the forge project ("must have", "should have", "could have") and e.g. extended by a specific target version * communication * there will be a dedicated group on Slack for that * interested active contributors are invited ###Team Culture * at the beginning we started with the question "what drives us and what motivates us", but there was not question about possible frustration levels * todos * setting up groups of interest in Slack - document that in a blueprint at some time * talk about situation again during Bremen code sprint * think about an additional meeting prior to T3DD14 since the next ACME is in Munich in September 2014 ###Collecting topics of interest for the next 6 months Must-Haves: * Marketing / Communication * Roadmap * Marketing * General * Solve all Security Issues * Clean up Forge / Issues * Technical Documentation * Performance Topics: * Performance * UX * page tree * page model * structured content * task oriented UI * record editing and manipulation ("data management") * drag and drop clipboard * drag and drop to create content elements * fe editing * mobile * video ce * new backend skin ("flat design") * "end user happiness" * language handling in the backend * Extension Management * Composer support * Improve UX * Add features * Extension Developer Low Entry Level * Closed User Area (Registration, Profile, Forgot Password ...) * Easier Configuration, replace CSC * Create Content Elements without creating an extension * Easier Modelling * DBAL * Doctrine Integration ("Enterprise" Label to TYPO3 CMS) * Architecture * Extbase / Flow * Flow integration, Add more Flow code into Extbase * More intelligent Extbase Persistence * Web Services: RESTfull API for Core API * Get Logging Done, use Logging API * Decoupling of Classes * Migrations * Shell API * Core Bootstrap Cleanups * Testing (Prepare for the rolling release) * Integration Framework / Travis * Test Environment improvement * better coverage (i.e. Extbase) * Functional Tests ###Result of voting on the major topics * Extension Manager: 12 - admin topic * UX: 9 - user topic * Architecture: 8 - integrator topic * Testing: 8 - one important foundation of "rolling" topic * Clean-up: 7 * Extension Developer lower Entry Barrier: 6 * Doctrine: 5 "Relieved of the outcome, but not relaxed. Many things to be done."