In yesterday’s dev chat, a number of people volunteered to help with projects for 3.0. We agreed that each team will post weekly updates here on wpdevel so that the community can keep up with the progress and weigh in on decisions as they come up. The first one up is the team of AaronCampbell, filosofo, Strider72 and PeteMall. They’ll be working with westi on figuring out the infrastructure and processes around the introduction of core plugins. For the sake of transparency, below is the email I sent them to outline the scope of the project. If anyone has suggestions for the team to take under consideration, catch them in IRC at #wordpress-dev, or better yet, leave comments on their Monday posts here on wpdevel.
Hi guys. Thanks for volunteering to help get the core plugins system/infrastructure figured out. As you probably guessed, Peter is the lead developer taking point on this, but we thought it would be good to have a volunteer team to help move it forward.
At the core team meetup, we agreed that for core plugins to be successful as team development projects, they would need basically everything WordPress has: Trac, mailing list, support forums, etc. We also need to make it easier for there to be a multi-committer project. Peter has thought through a lot of these things, so hopefully you guys can chat and come to some agreement on what would be the most useful setup.
Once you agree on what we need to have in place for core plugin teams to start testing out the structure, if someone could write up what you propose we do, we can get some community feedback on it, and then pull in Barry to actually set up whatever we need systems-wise.
Aaron brought up a question this morning in IRC: what if a committer starts doing things that are not good for the core plugin? Part of your task is to propose the process by which such a person’s acts would be reviewed and dealt with. My instinct is for the other committers to bring it to the lead devs, and for the lead devs to remove commit privileges if someone is making bad commits. But again, if you guys can write up how you think it should be handled, then we can get community feedback before making any decisions on process.
The UI for core plugins in the admin is going to be a design challenge. I’m starting up a UI mailing list, and we’ll have a handful of UI design challenges for 3.0 to get more UI/UX designers involved as contributors.
At the core team meetup, we identified a bunch of areas where it would be good to have a core plugin, but we’ll also need a process for deciding which areas to create a core plugin for, how to choose the committers for each, etc. If you guys can brainstorm a little around that… you guessed it: write up what you propose and we’ll get community feedback. 
As mentioned in the dev chat, we want to do a better job of all the mini-projects being visible by having them post updates on wpdevel.wordpress.com. Since there will be about 6 mini-projects (you guys, menu management, bugs, merge, post types, etc), I think the best thing to do is what we did for the GSoC blog this year, which was to give each person (or in this case, project) a specific day on which they’re expected to post their update. That way wpdevel will be getting an update from someone almost every day. I’ll add all four of you as authors to wpdevel, and you can decide who is going to be responsible for posting an update once a week. Since you’re the first mini-project I’m emailing, I’m going to assign you Monday as your day for posting an update each week. That will work well, I think, since your first update can basically introduce what you’re going to be doing and let people leave suggestions in the comments to help get you started.
For the sake of transparency, I’ll also post this email on wpdevel so people know what you’re tasked with doing.
If you have any questions, suggestions, etc, feel free to contact me anytime. And have fun! This is going to change the WordPress ecosystem, and you’re in on the ground floor–how cool is that?
aarondcampbell, 
How about considering letting each core plugin have it’s own Trac or be in a core plugin Trac. Plugin Trac works, but it has a lot of noise from the other 7,000 plugins. I think it would be nice to filter content for people. The current plugin Trac seams overwhelming until you get use to it and filter data. I’d assume people are Trac novices. It would also give developers more features, e.g. they could add components or create roadmaps. I like the idea of a core plugin being like core development, but on a smaller scale.