This sits well with me. There will be a lot of dotted lines from group to group (e.g., our Auth Bridge is going to be intimately related to the Auth Server and the Client Implementation on FirefoxOS, particularly with the First-Time Experience flow on device), but high-level, this seems like a good breakdown.
I am on PTO this week. Terrible timing, given all the momentum and convergence among our projects. But there it is. While I am gone, I deputize Austin to be the point of contact for the PiCl Auth Bridge team. Looking forward to coming back after next week and digging in with you all. Cheers, j ----- Original Message ----- > From: "Lloyd Hilaiel" <[email protected]> > To: [email protected] > Sent: Friday, August 9, 2013 5:35:08 AM > Subject: Breaking down this problem > > Yo all, > > In a recent letter to the identity team I proposed breaking down the team by > well defined projects, and having single leadership for each project. What > does leadership mean in this context? Here's how I defined the expectations: > > > > > 1. Run the project meetings - agenda's ahead of time, clear goals, > conclusions, action items, etc. > 2. Communicate - Weekly status updates (where we were last week, where we're > going next), with important bits bubbled up in our monday meeting > 3. Define the schedule and milestones > 4. Make decisions when you lack consensus (or escalate if there are important > cross-functional ramifications) > 5. Interface with other groups as needed. > > So how does this relate to the sync effort? I propose effective immediately > we decompose this problem into the following groups with the named leaders: > > 1. (dcoates) Picl Authentication Server (including scrypt helper) - This is > the current server that speaks a REST API, serves no content, and allows one > to authenticate and access key material > > 2. (jedp) PiCL Auth Bridge - This is a facilitation server that allows us to > build UI in HTML that interacts with the authentication server. It will be > used in any environment where we get benefits from HTML as the UI (web, > firefoxos, and maybe even desktop, more on this in a subsequent email). > > 3. (lloyd) Client Implementation - This is implementation for desktop and > mobile that will land in mozilla central. I name myself as the lead here, > but this is going to be a large cross functional group. (another email about > this). > > 4. (chris karlof) Future Storage Implementation - This is defining the > simplest storage protocol that can work reasonably across our initial data > types, bound by the MVP definition. > > The goal here is to accelerate implementation. While things may seem > uncertain, in my mind they are not. The only thing we don't know is whether > we can build a new storage implementation that handles bookmarks perfectly > jn under a year. Apologies if I oversimplify, but I'm a simple man. > > How's this sit with folks? > > lloyd > > > > > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev > _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
