On 1/28/13 8:12 PM, Ben Adida wrote: [Catching up from a workweek, sorry for being so late to the party.]
This module covers server-side code and some client-side code to integrate into Firefox (Desktop, Android, and OS) services tied to the user's identity. The immediate goal is to give users access to their core browsing experience (bookmarks, tabs, passwords, apps, contacts, and history) once the user has authenticated using Persona/BrowserID. This is, essentially, a rethink of FX Sync with a mobile-first view, adding important features such as backup.
I'm rather confused as to why we have two teams working on different sync-like features, and how this all fits into current product plans. But I'll just sidestep that, because it's not really relevant to my other concerns.
BrowserID has done OK as a module, but I'd note that it was (1) very self-contained, with minimal interaction outside itself and (2) only partially finished for desktop/mobile; the UI is incomplete and the DOM implementation isn't yet enabled in Nightly builds (ie, it effectively hasn't shipped at any scale). It seems to have had mostly minimal, FirefoxOS-only activity since it landed in the middle of last year.
Core code that involves "bookmarks, tabs, (etc)", however, touches nearly every corner of the browser and is a pretty high bar for ownership. But I'm unclear what the actual boundaries of this module would be, and what it means to "overlap" with other modules. Part of the definition of a MO is the ability to review/evaluate the code within it, so it wouldn't seem to make sense to overlap with areas where the input/review of other MOs is required.
Generally, I think modules work well as a recognition of how things are already effectively operating. As a result, changes/additions have often lagged behind the actual work they reflect. For example: work on Weave started in 2007, but it didn't become a formal module until 4 years (!) later. Given the other ambiguities here, it might be best to carry on with getting the work done, and revisit module creation when it's clearer as to what the module actually is and why it's needed.
Finally, procedural nitpick. :-) The whole process of creating a module is unfortunately vague, but ISTM the last few proposals have all waited to add entries to the wiki's module list until _after_ discussion and approval. I would suggest we do the same here, so there's no confusion for people reading the wiki. [Or if there's a good reason for listing new modules during discussion, they should be clearly labeled as "under discussion" or "proposed".]
Justin _______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
