After the apps team meeting today, it looks like we still have some work on notification left until we can merge branch with the trunk.
We predict that this should be done by Monday Aug 22.
It seems reasonable to expect we will need 1 week of bandwidth to test this and work out all the issues. This means that we will have to delay the release at least 2 week.
Since there is still some uncertainty, we have decided to wait until next Tues to announce this slip in schedule. By this point we will know if we have started the merge and if we can expect to slip further than one week.
Philippe had some concerns around expectations (on his part) for how long this work took. He felt that he might not have understood the extent of this particular project. The team discussed some reasons why this may have happened and brainstormed some ideas for improving the communication next time.
Sets was a large project with many dimensions.
We might have had better cross team visibility.
Could we have involved the apps team earlier in the team discussions and design.
How can we facilitate the discussions better and make sure there is a shared understanding. What about with remote people. We need to think about this for future projects when we have various contributors.
For recurrence, identifying a shared task list to find out who needs to be involved and who needs to have a shared understanding was particularly helpful.
Should there be some kind of standing meeting for a large project. How to integrate with remote people. The IRC approach Katie has been using has had mixed results.
A future approach might be to identify up front, all the people who might be involved early and communicate decisions, meeting notes etc via the dev list or email the group to keep others on top of the progress and issues.
Running acceptance tests/unit tests
What should the expectations be around developers responsibility for running acceptance tests on the builds.
This issue came up from a request for the sets team (john, alec, morgen, ted) to run all unit tests and qa acceptance tests on the branch before it's merged with the trunk.
We would like to develop a culture where we try and encourage people to care about this.
In this particular case (merge of branch to trunk), it's a good chance to start using this. Use this case as a context. In these kinds of situations, this is what we expect people to do.
Aparna is going to send an email to dev explaining this and our motivations for having the developers participate in this process.