Orion/Meeting minutes/20120301

Note that this was also a retrospective on the 0.4 release vs. just talking about what we were working on

Feel free to add anything that you'd like to capture with regards to the retrospective or that was captured incorrectly in the minute taking.

Attendees

• Andrew
• Andy
• Kris
• Gosia
• Szymon
• Susan

• Ken
• Anton
• Max
• Mark
• Simon
• Grant
• John
• Felipe
• Silenio
• Libing

Other Stuff

0.4 Is OUT! Yay! Announcement on Planet Orion

Committer list? Anton, Grant, Ken, Max, Andrew, Kris, Andy - Start that this afternoon. You can still ask for reviews on code.

Existing non-committers can you please describe your workflows here: Git Workflows

Retrospective on 0.4 release

• Andrew - Locally vs. Server. If using funky git commands it's better to run locally. Need better git support? Waiting for everything to load before doing an Orion Git command can be slow as well.
• Andy
• Kris
• Gosia
• Szymon - If you find something wrong with the flow, please open a bug. In this way we can track the issues. Communication improved a lot in this release. Collaboration was great for coming up with new ideas. The biggest pain were the changes made late in the cycle. Try to introduce sweeping changes earlier in the cycle.
• Susan - Can we wiki up the workflows of the non-committers? Like the idea of some releases that have the extra milestone stealing from other releases. So like stealing from the summer release to make time for 0.5? Perhaps 3 milestones in particular releases. Really back end crazy. Our blueprints for new header came in the last week of M2. Try to find the hard use cases early on. Try to find adopters for your code.

• Ken - Agile (daily builds/deploys). Need more testing locally. I would like to mandate JSLint clean code.
• Anton - The Non-committer workflow might be quite a bit different and existing committers might not see this? Update at beginning of Dev call would be helpful. Option to open in new page.
• Max -
• Mark - Communicating in mailing list about where we were in the release.
• Simon - Documentation usability issue with Git? How do I do X? The end game was a panic especially for Susan. Doesn't seem to be a difference from M2 and RC1. RC1 is just like another milestone. Should we reduce to 2 week end game being very strict. Really like keyboard commands.
• Grant - Susan's suggestion from last week about testing on different browsers than we typically develop on (eg.- IE) should become a regular characteristic of test passes. At least some testers should be explicitly assigned to test on these browser, similar to SWT test-pass assignments.
• John - Crazy productive, great number of new features. 4 fold increase in bug reporting and fixing. Successful from that point of view. Little bit on the edge. Frequently broke daily builds. Might be more of a statement about tests. They might not be testing appropriately at the page level. Daily builds and deploys are good. JS Unit tests went up and feedback for failures is improving. Minification failures. On the community aspect we are doing posts, plugin pages, is the documentation adequate for getting started? OrionHub is actually being used. 0.4 M2 717 people used it but only 200 people downloaded it. They see the announcement and can click. Is our warning a little too harsh? Can we focus on broadcasting the really scary changes that are coming up.
• Felipe - Surprised that the short releases work. Was happy that work can get done in a short timeframe. Work with Mozilla went well. Things that came from them was beneficial for the project. Trying to use the editor in the blog was a whole set of different problems and was beneficial. Pet projects on the side using the editor it might teach us more about reusability. Learned about require.js and i18N in the editor.
• Silenio - Debugger integration is something that he sees as limiting. We have to move forward on this. Even being able to add a breakpoint and step in the editor.
• Libing - Compare view. Needs improvement. (John - should we have other compare views?). Related pages is very useful.
• McQ - With a 4 month release cycle it's difficult to work on features that might span multiple releases (really big items). Do we maintain separate branches for release features.