Post Symfony Day Cologne 2010 Meeting Notes
- Nils
- Benjamim
- Jon
- Kris
- Lukas
- Daniel
- Pascal
- Bernhard
- Michel
- ..
At around 10:10 we started. Lukas gave a general overview of the discussions so far, the decisions (initial voting http://github.com/symfony-cmf/symfony-cmf/issues/closed/?labels=initial%20voting#sort=votes, mission statement) and current issues to address. There were a few discussions about JCR as well as the admin generator. Since a few people arrived a bit later, we split up for about 30min where Lukas gave the same speed to the late comers, while the others started discussing some technical ideas (?). We then came together again and decided to split up into research groups:
- Scrum (Lukas, Daniel, ..?)
- Admin Generator (Jon, Kris, Bernhard, Michel..)
- JCR Spec reading (Nils, ..)
- JCR PHP Interfaces review (Benjamin, David via IRC ..)
- Infrastructure (Frank)
After lunch and a bit more team research we can together again at around 16:00 to discuss the findings:
Apparently there are some initial interfaces ready, but still a few bigger decisions to take, where Fabien also needs to give feedback. The core idea is to provide a set of interfaces as a basis. One key aspect to solve well is the question of many2one and many2many references. On top of the interfaces the ORM/ODM/JCR specific things will be implemented. The idea is to make it possible to still use configuration generated actual code, but also be able to generate code from these configs. The entire system will rely a lot on twig's form integration to enable customization. Furthermore we clarified that we expect that if we use unobtrusive javascript, then we would make it possible for users to easily add dynamic functionality using a javascript library of their choosing. In order to facilitate this (as well as CSS styling) we should automatically set sensible css classes based on the the of widget, form element and group names etc.
(Kris:) This could be more of an "admin framework" which registers certain "views" based on a DIC tag. The person constructing an admin page will be able to do so by calling on these views (i.e. edit, list, show), embedding them in other views (i.e. side-by-side translation) using a thing configuration layer of some sort. The core admin library would be the glue between the model and these views. The core admin system will be built using views and the admin system can be enhanced using views -- everything is a view -- same idea as "everything is a bundle."
(Bernhard:) The idea for developing the admin was to undergo the following phases:
- draw mockups for different use cases
- implement these mockups
- improve their usability
- abstract the resulting code into modular and extensible code
A lot of the thoughts are based around what Karsten told at the Zurich meeting in September. Some information can be found here: http://news.typo3.org/news/article/scrumify-phoenix/
One major concern was where to find the product owners. Typo3 apparently uses a pool of their key developers for this. Maybe there are developer compatible sales/marketing people working in companies that are interest? Potentially some experienced developers with limited development time. For example Lukas isn't sure how much code he can contribute.
There was also the question of how to split things into more manageable scrum teams. We anticipate around 3-5 such teams. We discussed if teams should be split regionally or by topic. It was decided that regional criteria are a nice to have but by no means a must have. People should find each other based on their interests instead.
Team size should be no less than 5 probably more in the direction of 10, since its likely that some people might have limited time during a sprint. The sprints should be longer to again address the fact that the team will not be working full-time. We suggest 4 weeks. There should be daily scrums, but a daily scrum should never be delayed for people running late. Its not a problem to miss a daily scrum now and then. For cross timezone teams it would be suggested to alternate meeting times.
Everybody can write user stories, community can vote on the user stories to suggest priorities to the product owners. But in the end its up to the product owners to choose.
There should be a metascrum: Representatives from each team (ideal scrum master and/or product owner plus one alternating member of the dev team). So with 3-5 teams there would be 6-10 people plus product owner + scrum master. Responsible for keeping a common vision, separating the epic stories among teams, ensuring common standards, processes and infrastructure
We then talked about tools. We decided that our requirements for a scrum tool are not that high. Therefore we rater want to focus on having a great continuous integration solution than a scrum tool. Furthermore several people pointed out that they are not happy with Jira administration. Things seemed to lean towards using Redmine with the Scrum plugin and Hudson. We also discussed how to best deal with being able to report which commit breaks the build. We determine that the best approach would take an optimistic approach. Aka the build system runs the tests at regular time intervals if there was a change. In case of failure the system would automatically examine the last commits to determine which one broke something (backtracking through the commits via divide and conquer).
Jon also mentioned that ServerGrove had donated a server for Open Source use that is currently being used by Doctrine that is still quite underused. We decided that this would be the best place for our server infrastructure (assuming ServerGrove/Pablo approves, which we assume he will).
It seems David had already pondered about how to make the interface more PHP-ish. It seems several iterators should be changed to used the PHP interface. Furthermore property objects should be dropped and just be handled as array's on the client side. We also discussed that Jackalope's transport layer should serve to bridge differences between the PHP and Java world, like method names, object tree's vs. arrays. Speaking array's we felt that it should also be possible to support associate array's by simply saving them as two separate multi value fields, one for the keys and one for the values. The conversion to namespaces looks to be a big task that needs to be more or less done in one swoop (does the ZF conversion tool help?).
At 16:10 we concluded the meeting. We felt we managed to increase the understanding of the current state significantly and greatly benefited from meeting in person. We agreed that we feel that JCR is the right basis, because we expect that we can make it possible for people to not have to run a full JCR backend if they do not want to.
Lukas said that over the summer he didn't want to push the pace too much in order to not alienate people who are on vacation etc. However now he wants to pick up the pace. Therefore he will soon send out an email with a link to this protocol, an email to initiate user story writing, an email to start forming of teams. Furthermore the aim is to push forward pseudo code and proof of concept development with the aim to have code committed this month.