T3DD10/CoreTeamMeetingProtocol
From TYPO3Wiki
- 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
- Content Security already works
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 ;-)
- Introduction Package -- maintained on Forge
- 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