Team thoughts on continuous improvement 30
Revision as of 10:46, 5 August 2008 by David williams.acm.org (Talk | contribs) (→Things we'd like to improve on)
WTP 3.0 Debriefing 07/10/2008
Following our WTP 3.0 release, we'd like to have a short meeting with committers and contributors to discuss possible ways our project might improve.. These include things that you think we did well in this release and things that you think should be changed or improvements that can be made, process changes, etc. This feedback will become critical to our success for our next major release
Please use this page to express priorities, make notes, and brainstorm as many ideas as possible. This will serve as a seed list for the meeting on July 10th, 2008.
Things we've done well
- WTP 3.0 and Ganymede EPP package delivered successfully.
- Quick response time on critical questions from all teams
- Great number of bugs resolved
- Completing smoketest online and declaration of drivers
- Much better better experience from here than past release
- RAMP down was more smooth this time, less pushing of the envelop
- late last minute additions
- exception process, less drastic
- WTP is more mature in 3.0 than 2.0
- Planning process, keeping planning up to date, Raghu, kept on updating the plan throughout the release, keeping the plan up to date, Great job Raghu!
Things we'd like to improve on
- More educational material for users: articles, tutorials, documentation, etc.
- Action: Naci ...?
- Education: more material
- JavaDoc internal API, in depth comments, SSE, artical or user docs. user guidelines are up to date
- Programmers and committers themselves
- Some portions, private and protected method/classes with no doc, and hard to understand
- with patch creation, no internal javadoc, then harder to get up to speed for new ppl
- Some portions of WTP, standard compliance to the specs, false positives
- may break adoptors if changing these
- Eliminate build issues, JUnit failures, build breakages WTP Build Break Board
- Build breakage board => Keeps it going for next release
- Unit test pass before releasing code
- where the test are located, make it better and easier to run the test
- easier it is to run test setup
- JUnit test with each bug, UI might be harder and content consistent
- integration, and variation of the environment, where the test is running, synchronizing the code
- Team project with just the test themselves, Team -> export project set
- Improve collaboration:
- in resolving WTP-wide issues: infrastructure, architectural, etc.
- in organizing subproject teamwork when team members are spread across the world.
- Action: encourage more team meetings, investigate collaboration tools, such as ECF, IRC, semi-standard IRC clents
- Doing well
- subproject level - formulate planning, more interaction, not always up to date with the entire sub-project team, more ideas about planning
- using mailinglist instead of mailing list
- instant messaging
- ECF client
- long standing request for foundation to start running SMP, a messaging server
- IRC channels, Nitin and Dave C are on this, web interfact for IRC chat as well
- publishing yahoo and IRC accounts
- better communication for everyone
- release candidate, 4 RC, weekly, too stiffling, less RC and more time in between them
- 2 RC instead of 4?
- estimate the # of bugs complete
- too many bugs in RC1, always a rush, overestimate
- start development earlier, eliminate scope of our features
- only critical bugs in the RCs