Translations
Info
All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

T3DD10/CoreTeamMeetingProtocol

From TYPO3Wiki
Jump to: navigation, search
This page belongs to the Core Team (category Core Team)
  • Start at 09:00 on Tuesday and Wednesday

Google Summer of Code Review

  • Karsten: Karol Gusak working on Localization/Internationalization
    • works very nicely, also uses TDD (Code Coverage 75%)
    • so far: it can already be used
    • CLDR is uses as repository for formatting rules
    • now working on Fluid ViewHelpers
    • also started working on XLIFF support
    • 3 weeks in advance of schedule
  • Steffen: extending the Media Player
    • was not in touch with TYPO3 before
    • division into 3 tasks:
      • creation of wizard for user input (copy/paste link from YouTube) -> done
      • getting video information (Rating, Description, Picture) from the video sites (YouTube API) -> 50%
      • Support for Playlists -- very complicated, not sure if this can be done.
    • General Status: 60% -- the first components can be directly used.
    • Code Quality: OK, Steffen reviewed it
  • Ingo: Pascal, working on Community Extension
    • based on Ingos Community Project, but based on Extbase, and "done done"
    • Test Installation at gsoc1004.typo3.org
    • still quite basic, but looks good
    • will be used on TYPO3.org
    • Side-Effect: re-done the comments extension in Extbase
    • General Status: on time
  • Thomas/Tobias: NextGen List Module by Nuwan Sameera
    • some start trouble (List module quite complicated)
    • now has an Extension which extends list module with Ajax functionality (works, but not "Done Done")
    • Code was just checked in a few days ago
    • Extension Key: nsdynamicc
    • We need to coordinate better with Jens in term of UI stuff
  • Robert: Content/Resource Security by Andi
    • Content Security already works
      • Example: Some people might only access Blog Posts with a certain string inside the Title --> You'll only see these posts
      • Persistence Layer is aware of this ("EnableFields on Steroids")
    • Resource Security comes next
      • Example: Download a restricted resource only once, without PHP involved

Global Roadmap / Transition

  • Transition Days were already two years ago
    • they were really an unexpected and nice success
  • Migration from v4 to v5:
    • the strategy must be better defined and documented: COMMUNICATION!
    • We want to get the two development branches closer, but we will NOT merge them.
    • We will be able to migrate content (98%)
    • We will also be able to migrate Extbase plugin content (mostly)
    • TODO: case study: how to port an Extbase extension from v4 to FLOW3 (real plugin)
    • Create an article on typo3.org! Benni
    • For new v4 releases: Put things into perspective with v5 (in the release notes)
    • The Spirit of TYPO3 is still there
  • Could we share the Introduction Package as well?
  • Transition of the User Interface possible?
    • Jens: definitely YES
    • first, streamline v4
    • then, use selected v5 UI principles to v4.
    • Lars and Jens will meet regularly for that
    • Example: Icons will "converge" in 4.5, 4.6
    • Talk about it again on T3CON
  • Extbase/Fluid as big features are perceived well
    • good step in the "transition"
    • however, tool support missing -> we need Extbase Kickstarter, Analyzer for persistence settings, Fluid Code Browser
    • we need to focus on Documentation for Extbase
    • Create a "Extbase Case Studies" site on typo3.org
    • everybody who uses Extbase: please contact Andreas Beutel with some links
    • Create an Extbase backend module in 4.5 for the core?
    • TODO to Discuss: A-Class-Extensions based on Extbase?
    • Take the fear out of using it.
  • What is the goal of transition?
    • closing the gap?
    • how do we "find together", and know what's going on?
  • New things which could be back/forward-ported
    • Forward: Install Tool
  • Things which can not easily be backported
    • TypoScript
  • Great: UI in 4.4 lends toward v5

How to handle breaking changes (in Extbase/Fluid)

  • put updated Blog Example into TER
  • Deprecated stuff: Communication: build up a list of removed functions in the wiki (deprecated)
  • Integrate it into Update Wizard, and deprecation log
  • try to avoid Breaking changes, but if they occur, document them in the release notes clearly.
  • what about Backend Modules?
  • Explain the @api annotation

Documentation

  • Infrastructure: how to render documentation on a common platform?
  • FLOW3 Book / Documentation should be a community effort
    • Simfony Community / Rails Guides: Write a book in three months, and translate it at the same time. This was not announced.
    • Which infrastructure did they use?
  • Documentation should be "Team", and not "Project"
  • for improving documentation, Do a "Documentation Day", like a "Bug Day"
  • Planned Workflow: first, create document in Wiki. When it is matured enough, move to real documentation (SXW, DocBook)
  • Technical resources needed, for investigating rendering errors, possible format switch, ...

TYPO3 4.4 Retrospect

  • first version with 6 months release cycle
    • having a fixed release date is really helpful
  • motivation is an issue; RM sometimes feels lonely
  • Features:
    • Introduction Package -- maintained on Forge
      • should have been announced more clearly that this would be included in the core
    • some more ;-)
  • There were features committed AFTER feature freeze
    • we need to watch out that this does not become a habit.
  • create the "Gold Master" two weeks before the release, to have time for Release Notes, …
  • have a "Priority List" of issues maintained by RM, for suggestions
  • How to communicate better
    • Possible to adapt Daily Scrums in v4?
    • Possible to have one Chat Room (Jabber)?
    • Maybe re-start beat (as "Twitter Aggregator")?
  • Have protocols of weekly meetings with Ben, Oliver, Benni
  • We could market version 4.4 better
  • the "release experience" was great (Introduction Package, Release Notes, Start Page)

Team Structure / Responsibilities

  • Is it motivation?
  • overview?
  • lack of time?
  • Problems
    • Chaotic core list
    • More rules to tag the issues on issue tracker
  • Organize Review Weekends?
  • Have regular meetings?
  • Would it help to have more teams like DBAL?

What motivates you / What makes you commit to something?

  • Honor?
  • Motivation to get deep into issues -> then commit!
  • Make special lists for special topics (e.g. indexed search, …)?
  • Improve reviews
  • Until tomorrow, think about demotivators and motivators
  • Benni Mack: ++ constructive feedback; -- feel alone, cannot rely on other developers
  • Tobias Liebig: ++ bring knowledge into team; -- hard to keep track of things going on; hard to start quickly doing smaller tasks, issue queue could solve this
  • Andreas Förthner: v5 member; very motivated
  • Bastian Waidelich: v5 member; very motivated
  • Michael Stucki:
    • MOTIVATE: keep TYPO3 bug-free, stable and great;
    • DEMOTIVATE: not really demotivated, but spending time in assoc and administrative things. Lowering the barriers to have something committed would work
  • Ingo Renner
    • MOTIVATE: being able to change things, and fix bugs. Now: care for professionality of product, GSoC, Bug Days;
    • DEMOTIVATE: Example: Reports Module, RFCs take quite some time
  • Rupert Germann
    • MOTIVATE: Meeting people in real life and discovering that then, you understand each other. Also: high professionality of product.
    • DEMOTIVATE: Bad Feedback on the Mailing Lists, and personal communication problems; longer inactive periods are demotivating as well.
  • Ben van't Ende
    • MOTIVATE: Results of meetings, social interaction, appreciation
    • DEMOTIVATE: email is a bad communication medium for feelings; code of conduct should be more present
  • Patrick Broens
    • MOTIVATE: development never stops. learning a lot is great. communication in the community motivates a lot.
    • DEMOTIVATE: there's more going on in Germany, in the Netherlands, are not that many devs. NO FEEDBACK during big projects like forms/installer. Maybe "Reviewer / Mentor" would help. Feedback will help a lot.
  • François Suter
    • MOTIVATE: participating in an open source project; community is great; discussions in ML are not a problem; in general, really good community, and people care for each other.
    • DEMOTIVATE: not demotivated, but more focused on documentation. demotivated to work on things where the effort is huge.
  • Ernesto Baschny
    • MOTIVATE: get to know the inner workings of the product, also showing that to customers.
    • DEMOTIVATE: would like to follow more what's going on
  • Susanne Moog
    • MOTIVATE: being part of the community, able to change things, make things better
    • DEMOTIVATE: not demotivated
  • Stefan Galinski
    • MOTIVATE: get the chance to implement features with great people, and learn a lot by talking to very experienced people; has a good Brötchengeber
    • DEMOTIVATE: lenghty discussions on MLs; difficult reviews (before starting to write an RFC)
  • Steffen Kamper
    • MOTIVATE: being part of this team, t3dd best event of the year; learning so much, really great to work in teams; code sprints are lots of fun
    • DEMOTIVATE: first, many people interested, and in the end you are the last lonely guy doing things (happened with new EM); long discussions which are drifting away on mailing lists; comments from core members are missing
  • Xavier Perseguers
    • MOTIVATE: being able to change things; forge projects work out quite well; easy to commit things (in extensions); social events very motivating; there's a small DBAL bug list which are easy to fix (within short time-frame)
    • DEMOTIVATE:
  • Steffen Gebert
    • MOTIVATE: professional product with trust; working with experts is fun; backend design was lots of fun (together with Lars) -- great collaboration; Bug Days
    • DEMOTIVATE: discussions about coffee in the introduction package; Lack of Reviews; T3UXW results not fully in the core
  • Steffen Ritter
    • MOTIVATE: interesting project, fix own itches, personal skype messages about asking for reviews and his help, being part of a worldwide project
    • DEMOTIVATE: no response to ideas or RFCs, sometimes feels like a "stupid little developer"; please pick some example -> tell Michael
  • Andreas Wolf
    • MOTIVATE: Events motivate
    • DEMOTIVATE: no time at home; flow of ideas is not that much there
  • Jens Hoffmann
    • MOTIVATE: in the beginning: Kasper; now: work recognized by community; contribute to something makes you feel good
    • DEMOTIVATE: struggle with persons being less skilled (mailing lists and usability...) -> wastes lots of time; working for the "trash can"; not too much passion after T3UXW
  • Christian Kuhn
    • MOTIVATE: in generally, motivated; If solution is ugly, try to come up with better patch. Try to keep promises; still much fun; Don't pick up threads with too much discussion
    • DEMOTIVATE: sheer amount of inactive core members
  • Andreas Otto
    • MOTIVATE: inspiring to see how TYPO3 evolves
    • DEMOTIVATE: too many mails on the core list (overwhelming), with limited time.
  • Nils Dehl
    • MOTIVATE: v5, new stuff is cool :) Motivated to work on one topic
    • DEMOTIVATE: not sure where to help out in v4
  • Christopher Hlubek
    • MOTIVATE: Robert's talk about FLOW3; designing large frameworks which make life easier; creating something I'll need in a project; SCRUM is great -> focussing on practical tasks which are "Done Done"
    • DEMOTIVATE: set up FLOW3, but it's getting easier
  • Thomas Hempel:
    • MOTIVATE: community, organizing events, User Group
    • DEMOTIVATE: not demotivated in general, but feeling of getting ignored -> interests shifted; reviews are hard to set up and time-consuming
  • Helmut Hummel:
    • MOTIVATE: community, real-life meetings, skype-sessions; learning things is much fun!
    • DEMOTIVATE: email / mailing list discussion; concerning Security: nothing changes; even if you devote a tremendous amount of work
    • Focus on things like better workflow
  • Robert Lemke
    • MOTIVATE: passionate colleagues / team mates; improving skills / learning new techniques; the challenge to do the impossible; teach, share knowledge, inspiring people, wake their passion; creating tools which are useful for many people
    • DEMOTIVATE: politics, rumors, wild speculations; (negatively) emotional, unconstructive discussions; lack of money;
  • Oliver Hader
    • MOTIVATE: generally motivated, as it is a great product and a great community. sharing work/knowledge/... is really great, too
    • DEMOTIVATE: discussions drifting away to personal things in MLs; hard to keep overview about what is going on; T3UXW results not yet fully in core.. We need responsible persons "to keep the fire burning"
  • Karsten Dambekalns
    • MOTIVATE: reaching set goals/solving problems of demanding nature; working in skillful teams; developing/sharing knowledge and skills; researching new techniques; making a product people will love
    • DEMOTIVATE: too much talking/discussion; politics & tactics instead of clear statements; fear of change in community; lack of trust/believe; lack of money leading to withdrawals regarding ambitious goals
  • GENERAL IDEAS:
    • Issue Queue


Counting Reasons for/agains voluntary TYPO3 work:

Motivation


  • Social Interactions / Meeting Persons in RL / Friendships / Sprints - IIIIIIIIIIIIIII
  • Share Expertise / Knowledge - IIIIIIIIIIIII
  • Get Expertise / Knowledge - IIIIIIIIIIII
  • Lowing the barriers to commit something - IIIIIII
  • You can fix something / Able todo things - IIIIIII
  • I like to work on big Projects / TYPO3 (see progress) - IIIIIII
  • Working as Team / be part of it - IIIII
  • Contribute to the Project - IIIII
  • Keep TYPO3 a great Product - IIIII
  • Get honored - IIII
  • Getting recognize as big player (personal/product) - III
  • Able to participle in a OpenSource project - II
  • Stay focused in one topic - II
  • Getting Feedback form Core guys - I
  • Reach real goals - I
  • Be a little Asshole to keep the Product professional - I
  • Initiate a Site Project - I
  • Development never stops - I
  • I don't have to do it in my spear time - I
  • Get direct Mail to a topic / Direct requests - I
  • Short list of bugs - I
  • Make meaning - I
  • Do it for others - I


Demotivation:


  • Core List is to Time intensive - IIIIIIIIII
  • Bad or not well formed feedback / Don't get Feedback at all - IIIIIIII
  • You know in advanced how hard it is to get a patch though - IIIIIII
  • Hard to keep Track / Amount of the Newsgroup - IIIIII
  • Working for a Side Project - IIIII
  • Behave Respect less / Personal (doesn't improves something) - IIIII
  • Repeating topics / discussions - IIII
  • eMail is a very bad why to communicate (No face2face disc.) - IIII
  • Lack of Time - IIII
  • Not enough action by core guys - IIII
  • You feel alone (In Holland) - III
  • Less core guys doing something - III
  • No one was helping, only talking (RTFM) - III
  • Huge amount of Problems (no learning happening) - II
  • Requires a lot of effort - II
  • Doesn't fit to me (found something else in the TYPO3 universe) - I
  • Hard to Start smaller Tasks - I
  • Need to get money to work for free - I
  • Doing Administrative stuff - I

Using Git / Gerrit

  • Sebastian shows the possibilities of Git and Gerrit
  • A team will evaluate the requirements for Git compared to the current v4 review and commit workflow. The team consists of Michael, Ernesto, Xavier, Andreas Otto
  • Michael mentions that at least two people should administrate the Git repository - Peter Niederlag (having a workshop on Git) will be asked
  • Using Git would be a descision with no return - using Git and SVN in paralell with merging things is dangerous and will not be done due to possible conflicts
  • FLOW3 wants to test Git first for own purposes since the team will switch so a similar review workflow (with +1s etc.) as we have in v4
  • I the descision will be pro Git, the it shall be considered as well to migrate extensions to Git
  • Question: Who wants to try Git? - Mostly everybody raised the hand... ;-)

Git

Election of the Release Manager

  • Ernesto
    • constantly following the lists, made lists of projects being worked on
    • 4.5 continuation of 4.4 ("The last 10 %")
    • FE rendering improvements
    • Backend Skinning / Tree improvements
    • focus on the organizational aspects and communication
  • Steffen
    • Backend improvements, JS, ExtJS
    • throw out Prototype/Scriptaculous
    • new Extension Manager
  • Focus on the details!
  • -> share this job between Ernesto + Steffen
  • Benni as Helping Release Manager
    • good for continuity
  • For coordination: weekly meetings (team: Ernesto, Steffen, Benni, Oliver, Ben)!
  • Main Release Manager: Ernesto
  • Technical Release Leader: Steffen
  • Supporter: Benni


TYPO3 4.5 kickoff

Work in progress:

  • frontend performance, caching (Rupert, Christian)
  • things pending from UX09 week
    • pagetree (Stefan)
    • context menu API (Stefan)
    • toolbar (Ivan, Steffen K.)
    • backend search (Michael Klapper)
    • transformation to ExtJS and creating API
    • module menu (Ivan?, Steffen Kamper)
    • grid view / page module (Thomas H., Joey)
  • TCE forms refactoring / rewrite (Andreas Wolf)
    • idea: view part should use fluid
    • IRRE: still messy
  • EM (Steffen K.)
  • Forms project (Patrick)
  • Install tool refactoring (cont'd) (Patrick)
  • Workspaces: Results of workspaces team efforts (Workspaces Team)
  • backend cleanup (IE compat etc.) (Joey / BE team)

More issues to work on:

  • UTF-8 by default (Michael Stucki)
  • "Tasks on steroids" (Tim Lochmüller)
  • Getting rid of prototype + scriptaculous (general goal, Steffen K.)
  • FE user login as a sysext based on extbase (Steffen R., Jochen Rau)
  • performance checks on extbase impact, if loading extbase doesn't slow TYPO3 down (Jochen?)
  • scheduler and related:
    • making cleanup and lowlevel cronjobs use the scheduler (Christian K.)
    • poor man's cron: reacing on page load called from other server (possibly Christian K.)
  • performance improvements in DBAL: API for parametrised queries and use it in core (DBAL "team" ;-)
  • init.php enhancements (Francois & whoever is turning up at the workshop at T3DD10)
  • reports module improvements (Ingo)
    • scheduler task to detect issues with the installation
    • scheduler task for extension list update, and update checks
    • get rid of the yellow alert box, and provide a clean replacement (e.g. icon in the toolbar)
  • improvements to the recycler (Olly, also communicating with Julian)
  • Lightbox integration: Making it more easy (Susanne, Ernesto)
    • The markup of CSS styled content should be suited to work with the usual lightbox libraries on the market
    • Provide a cleaner and consistent API to add this functionality to the click-enlarger
    • Possibly integrate one such library (at least in the intro package)
  • Image content element (Tobi is going to explore this)
    • Usability-wise it's bad right now (idea from Jens)
    • User interface should be along the lines of IRRE (but: workspace compatib. probs)
  • File abstraction layer (possibly usable for DAM) (Dan Osipov, Ben, suggestion was by Andreas W.)
  • Auto-clean up of localconf.php (Christian with Steffen K.)
  • getting rid of inline styles of CSC completely and externalize them to CSS files, due to govt. requirements (idea from Patrick)
  • HTMLmail as a replacement to t3lib_htmlmail (Ernesto)
  • Indexed search (Stucki, should also contact Dmitry & Christian about it)

Overall goals:

  • Streamline the backend usability
  • Make it the fastest TYPO3 ever (fast frontend, fast backend, less memory requirements...)
  • Keep the product strongly placed on enterprise level

Collaboration UI team / Core Team

  • Time constraints in UI team
  • Hard to find mockups when not involved directly
  • Solution:
    • All issues related to UI (including mockups provided by the team) should go to the forge project
    • Issues that the UI team wants to be handled by the core team should be posted to the core bug tracker (Mantis)
    • "Major issues" that needs to be solved for a certain release needs to be additionally communicated to the release manager
  • Issues of usability / design are mixed up
  • How to motivate developers to implement usability suggestions
    • Awareness could increase the situation
  • Goal: Creating a real "team" for usability, so it's no one or two man show
  • Documenting the workflow on typo3.org - Jens will do that
  • Everybody should feel responsible for UI changes, and pointing to necissity of UI approval

T3UXW

  • in general, last T3UXW were quite successful
  • Bad internet connection was quite good
  • UXW just for DAM, Security, … -> Sprints where a team is locked into a castle
  • Idea: do a one-week sprint, but have multiple topics (not just UX)
  • We must call it different then because its not only about User Xperience. Ideas:
    • T3W - Ernesto
    • T3SW = T3 Sprint Week - Ernesto
  • Create a "sprint environment"; size of sprint is determined by number of sponsorship
  • PROBLEM: no real goal for fundraising
  • Idea: Fundraisers for each country, who call agencies.
  • Please add your ideas here, or discuss them with Jens
  • How do we attract developers/persons/Project Managers to apply?
    • Core developers usually cannot spend a whole week away from their own businesses, that is probably the main problem.
  • How do we attract more sponsoring?
  • What teams should be created / which topics?
    • One topic could be "TER". It would be good to try and build a team that takes care of this central tool - François
    • Documentation was mentioned. I don't know if we can really manage to attract documentation writers, but it could be worth a try. I'm also not sure that I would have time to participate. - François
  • Idea: Propose a certain amount of teams and required members to allow sponsoring of certain specific aspects. Allow participants to join specific teams, allow sponsors to sponsor certain teams. E.g.:
    • 1x team of 4 members for Workspaces
    • 1x team of 4 members for DAM
    • 1x team of 4 members for Security
    • 2x teams of 4 members for UX
    • 1x team of 4 members for Documentation
    • 1x team of 4 members for TER