Re: Adopting the black Python code style

2020-10-21 Thread Andrew Overholt
 Hi,

Unfortunately I don't think consensus is possible with code formatting.
Partly for that reason, we (Fx engineering leadership and others) have
concluded that automatic, standardized code formatting is the right thing
to do. We've already done this for a few languages and Python is up next.

Ricky et al are the designated experts here and they recommend the plan
outlined up thread. They ran it by myself, Selena, EKR, and a few others in
management and we asked them to proceed.

If there are major showstoppers or something that wasn't taken into
account, please do let them know now. Otherwise I'd ask us all to try our
best to accept some of these things in the name of efficiency since we
won't all agree on everything :) Thankfully we can likely automatically
revert or re-format if we find issues -- once we get automatic formatting
working.

Thank you,

Andrew

On Tue, Oct 20, 2020 at 4:26 PM Jeff Gilbert  wrote:

> Well we generally don't seek consensus anymore for these sorts of
> things, it seems, but it's reassuring that I'm not alone.
>
> On Tue, Oct 20, 2020 at 1:17 AM James Graham 
> wrote:
> >
> > On 19/10/2020 22:01, Jeff Gilbert wrote:
> > > I'm disappointed by that.
> >
> > FWIW last time I looked at black, I found that the compromises it made
> > to be fully automatic and with minimal configuration meant that it was
> > liable to produce ugly or difficult to read code in some situations.
> >
> > I understand that we've decided that people will get used to reading any
> > code style over time, and therefore eliminating formatting concerns from
> > the code writing process is a net win for productivity. So I'm not
> > taking a position in opposition to this proposal, but it is not
> > something I would have advocated personally.
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: [ Intent to Change ] Enabling the Triage Lead role to see security bugs in their component

2019-08-29 Thread Andrew Overholt
 Thank you!

On Wed, Aug 28, 2019 at 1:51 PM Emma Humphries  wrote:

> When work on https://bugzilla.mozilla.org/show_bug.cgi?id=1417229 is
> completed and the patch deployed to Bugzilla, users who are a Triage Owner
> will be able to see security bugs in their components without needing
> membership in security group or access through a role.
>
> This follows the same pattern as access for users in the reporter, qa
> contact, assignee, or cc list roles to security bugs.
>
> If the triage owner for a component changes, the new owner will have access
> and the previous owner, unless they have access through another means
> (role, or group membership,) will not.
>
> We expect this to go to production within the next two weeks.
>
> Many thanks to DKL for working on a patch for this.
>
> Emma Humphries, Bugmaster
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to unship AppCache

2019-08-22 Thread Andrew Overholt
It's been a long time coming :) Do you know if Chrome plans to drop
support, too?

On Wed, Aug 21, 2019 at 5:01 PM Jonathan Kingston  wrote:

> The design of AppCache brings many problems to the web platform from a
> performance and security perspective. Service workers have long solved the
> same use cases as AppCache.
>
> Removal of this code would bring a large reduction of code and complexity
> that is largely unmaintained.
>
> History
>
> Four years ago, in Firefox 44, we marked the API as deprecated[1].
>
> Back last year in Firefox 62, we disabled insecure AppCache and Chrome
> followed suit[2].
>
> Safari 11.1 added support for Service Workers, which are a replacement
> technology [3].
>
> Metrics
>
> Chrome measures a few different metrics here which suggest 2.3%[4] of
> secure page loads attempt to use the document visible API whilst only
> 0.27%[5] actually use the offline cache.
>
> Firefox metrics suggest around 0.01% of pages are using an AppCache[6]
> however we don’t have a distinct metric for the API usage.
>
> The last blocker for a removal was usage of AppCache by some Microsoft
> online products.  I’m enquiring into if this is still applicable and also
> want to ensure with this rollout plan that we don’t break these when the
> user has an online connection.
>
> Implementation
>
> Bug where the code will be implemented[7].
>
> Plan
>
>-
>
>In Firefox 70, Remove the previous preference
>“browser.cache.offline.insecure.enable” and related code, forcing all of
>the APIs to only ever be available over Secure Contexts despite user
>choice. Due to the insecure nature of insecure context AppCache it is a
>good time now to remove this fully.
>
>
>-
>
>Create a new preference that disables only the storage and use of
>AppCache data whilst permitting access to the dom property
>window.applicationCache and the “OfflineResourceList” interface.
>-
>
>   Disable access in Nighty and beta for 70 for two releases before
>   disabling for all other releases in 72.
>   -
>
>   Once storage is disabled in all releases:
>   -
>
>  Disable the API access in Nightly and beta via the existing
>  preference (browser.cache.offline.enable) in version 72.
>  -
>
>  Wait two releases and then disable in all releases in Firefox 74.
>
>
> This staged removal of AppCache is to reduce the risk of web compatibility
> issues of the API being accessible to page scripts. Despite the API
> presence it won’t have any ability to use the cache. We may look into
> shimming these APIs depending on how the rollout plan goes.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1204581
>
> [2]
>
> https://groups.google.com/forum/#!msg/mozilla.dev.platform/qLTTpdzcDkw/WKJeq-4HAQAJ
>
> [3]
>
> https://developer.apple.com/library/archive/releasenotes/General/WhatsNewInSafari/Articles/Safari_11_1.html
>
>
> [4] https://www.chromestatus.com/metrics/feature/timeline/popularity/1248
>
> [5] https://www.chromestatus.com/metrics/feature/timeline/popularity/1246
>
> [6] https://mzl.la/2TKRbvA
> [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1237782
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Crash-stop integrated by default for crash reports in Bugzilla

2019-01-17 Thread Andrew Overholt
That looks like it could be incredibly useful! Thanks for pointing it out
and for doing the work.

On Thu, Jan 17, 2019 at 11:50 AM Calixte Denizet 
wrote:

> Hi,
>
> A few months ago, we published the first version of the crash-stop addon
> [1]. The goal was to integrate crash data along with some analysis (ex:
> startup crashes) directly into Bugzilla. The goal is to help with bug
> prioritization and make it easier to determine if a patch has fixed the
> issue after it lands.
>
> Following the example of the Bugzilla Socorro Lens, we have decided to
> enable this functionality for everyone directly in Bugzilla given its
> impact and usefulness. Thanks to Kohei’s work, the table containing the
> data is now displayed in crash bugs directly without the help of the addon.
> As an example, see the bug below:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1519468
>
> Users who have previously installed the crash-stop addon can safely remove
> it now.
>
> For more information on the displayed data:
>
> https://crash-stop-addon.herokuapp.com/
>
> If you see something wrong or if you want to have more data, please feel
> free to file a bug:
>
> https://github.com/mozilla/crash-stop-addon
>
> Calixte
>
> [1] https://addons.mozilla.org/firefox/addon/bugzilla-crash-stop/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: Unprefixed Fullscreen API

2018-09-18 Thread Andrew Overholt
Congrats on getting this far, Xidorn! I know it's been years of work by you
and others.

On Mon, Sep 17, 2018 at 7:48 PM Xidorn Quan  wrote:

> As of Firefox 64, I intend to turn on unprefixed Fullscreen API by default
> on all platforms. It has been developed behind the
> full-screen-api.unprefix.enabled preference.
>
> Bug to turn on by default:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1269276
>
> Unprefixed Fullscreen API has been enabled in Nightly since Firefox 47. We
> once attempted to ship it at that time, but failed because of some
> webcompat concerns which happen only when unprefixed Fullscreen API is
> present. Since then, the spec has been revised to address some of the
> issues, but some of them were not fixable from our side, so I hoped to have
> other browsers do coordinated shipping with us.
>
> After years, Chrome / Blink eventually caught up the spec, and it reached
> a point that they are attempting to ship it now. I think this is the best
> chance ever we can have unprefixed Fullscreen API actually available on the
> web. Chrome will ship it in Chrome 71 which reaches stable on Dec 4, and
> Firefox 64 will reach release on Dec 11, so it's roughly the same time
> frame.
>
> Notably, there are two feature changes since our last attempt to unprefix
> Fullscreen API:
> 1. Fullscreen related events are now dispatched to element when it is
> still connected in the same document, which matches other browsers'
> behavior and provides better modularization opportunity.
> 2. Element.requestFullscreen() and Document.exitFullscreen() now return
> Promise which gets resolved when fullscreen change finishes.
>
> I'd also like to deprecate the prefixed Fullscreen API, but probably we
> should do that only after unprefixed Fullscreen API reaches release.
>
> - Xidorn
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: Array.prototype.values

2018-02-02 Thread Andrew Overholt
On Fri, Feb 2, 2018 at 8:45 AM, Tom Schuster  wrote:

> Chrome seems to
> want to add a kill pref for this,  from my experience more difficult
> for us with the way we define methods in SpiderMonkey. Should that be
> a requirement for shipping?
>

If it's not too difficult it does make it a lot easier to fix things if it
causes major breakage. I think we can even do a pref flip without shipping
an update which is pretty nice.

Is there a way to do per-site pref changes? Did we do this for Stylo,
Emilio?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to enable scrollbars by default for windows opened by window.open()

2018-01-17 Thread Andrew Overholt
We got a bug report that things are not working here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1429900. Ben, can you take a
look?

On Mon, May 23, 2016 at 2:25 AM, Ben Tian  wrote:

> Hi,
>
> I’m planning to enable scrollbars by default for windows opened by
> window.open().
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1257887
>
> This change intends to enable scrollbars by default when “scrollbars”
> doesn't appear in the feature argument of window.open(), and to disable
> only when opener pages specify explicitly. Currently window.open() disables
> scrollbars by default unless the feature argument enables explicitly or is
> an empty string. However in the majority of the cases the user will want to
> be able to scroll, and a lot of accessibility docs recommend enabling
> scrollbars by default.
>
> Chrome and Safari don't provide a way to disable scrollbar, according to
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1257887#c0
>
> If you have any concern or know of regression on pages relying on current
> behavior, please let me know.
>
>
> -Ben
>
> --
> Ben Tian,
> Engineering Manager
> System Engineering Lead
> Mozilla Corporation
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to implement (again): Shadow DOM

2017-11-28 Thread Andrew Overholt
Custom Elements is being tracked separately. Watch for an intent email
regarding them soon.
On Tue, Nov 28, 2017 at 8:05 AM  wrote:

> Is this just shadow dom or there will be also support for custom elements?
>
> Thanks
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Overriding JS to allow for opening in a new tab?

2017-10-26 Thread Andrew Overholt
On Thu, Oct 26, 2017 at 12:34 AM, Boris Zbarsky  wrote:

> Either approach would break at least some legitimate sites.
>

Thanks for confirming this.

In general, as Myk points out, the question of when web pages should be
> able to respond to what sorts of input, and whether they should be able to
> prevent the default browser respond to that same input, is something that
> keeps coming up.  It's not clear to me that there is a general
> context-independent answer here.


Ok, thanks for the clarification (also to Myk and Dave!). Sounds like in
this case there's no easy answer.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Overriding JS to allow for opening in a new tab?

2017-10-25 Thread Andrew Overholt
Is there precedent for doing what a user intended which would be contrary
to what the site is attempting?

In the case that prompted my question, the user was attempting to
middle-click open photos from a Facebook photo album in tabs but the
middle-click was handled by the page's JS:
https://bugzilla.mozilla.org/show_bug.cgi?id=1365260. Maybe this is just a
middle-click thing?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Adding Examples to Intent to Implement/Ship Messages

2017-10-21 Thread Andrew Overholt
Not a bad idea! You can feel free to add it to the wiki page under
suggested additions. And remember, they're just guidelines :)
On Sat, Oct 21, 2017 at 4:25 AM Philipp Kewisch  wrote:

> Hey Folks,
>
> One thing I've often been thinking when reading the Intent to
> Ship/Implement emails is "Hey, that sounds interesting, I wonder what
> that is and how I can use it".
>
> The spec and bug is usually linked, so I can go ahead and take a look at
> the spec, but what would make reading email a lot easier for me is a
> short summary of what the spec does and an example how it can be used.
>
> For example, the pointer events spec recently had an Intent to Ship. As
> I haven't read about it earlier, all I know is that the name suggests it
> has something to do with the mouse, but until I skim the first few
> screens of the spec until Example 1, I am not sure what it does. The
> following info would have been helpful:
>
> """
> Pointer Events are like mouse events, but more general. It provides
> similar information for devices like touchscreens, pen input, etc. Here
> is a simple example:
>
> window.addEventListener("pointerdown", function(event) {
>   console.log(event.pointerType); // "pen", "mouse", etc.
>   console.log(event.width); // width of contact geometry
> });
>
> """
>
> Do others think this information would be helpful, and if so, can we get
> this added to the process for Intent to Ship and Intent to Implement?
>
> Philipp
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Device Memory header and JS API

2017-09-06 Thread Andrew Overholt
On Wed, Sep 6, 2017 at 2:53 PM, Daniel Veditz  wrote:

> I do not know what are plans are about Client Hints in general, whether we
> intend to or when, and obviously that's a prerequisite.
>

Client Hints is https://bugzilla.mozilla.org/show_bug.cgi?id=935216, FWIW.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Response.body streams landing on trunk, default off

2017-08-11 Thread Andrew Overholt
On Thu, Aug 10, 2017 at 11:29 PM, Ben Kelly  wrote:

> Many thanks to Till and Andrea for their hard work on streams!
>

And to you, too, Ben! And to Boris and others for their reviews.

Congratulations, all, this has been some great teamwork and it's great to
see it get this far!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Extensions and Gecko specific APIs

2017-07-25 Thread Andrew Overholt
On Tue, Jul 25, 2017 at 3:06 PM, David Teller  wrote:

> Should we moz-prefix moz-specific extensions?


We have been trying not to do that for Web-exposed APIs but maybe the
extensions case is different?
https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Guiding_Principles
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Ambient Light Sensor API

2017-05-16 Thread Andrew Overholt
Did we make a decision here? If not, what are we missing to make one?

On Fri, Apr 28, 2017 at 1:55 PM, Anne van Kesteren  wrote:

> On Fri, Apr 28, 2017 at 7:10 PM, Eric Rescorla  wrote:
> > Rather, the policy is
> > that we will move to requiring all new features to have HTTPS [0].
>
> We should probably discuss that again at some point, since it's not
> meaningfully enforced and I don't think it has consensus within
> Mozilla either. It's also very much unclear what the scope of it is,
> whether a new CSS property should get that treatment, a new method on
> Node, etc.
>
>
> > [0]
> > https://blog.mozilla.org/security/2015/04/30/
> deprecating-non-secure-http/
>
>
> --
> https://annevankesteren.nl/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Ambient Light Sensor API

2017-04-25 Thread Andrew Overholt
On Tue, Apr 25, 2017 at 9:35 AM, Eric Rescorla  wrote:

> Going back to Jonathan's (I think) question. Does anyone use this at all in
> the field?
>

Chrome's usage metrics say <= 0.0001% of page loads:
https://www.chromestatus.com/metrics/feature/popularity#AmbientLightSensorConstructor.
We are going to collect telemetry in
https://bugzilla.mozilla.org/show_bug.cgi?id=1359124.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to ship: Storage API estimate method

2016-09-21 Thread Andrew Overholt
On Thu, Sep 22, 2016 at 2:03 AM, smaug  wrote:

>
> On 09/21/2016 04:42 AM, Shawn Huang wrote:
>
>>
>> ​Because ​Storage API needs to have SecureContext support, but currently
>> not having isSecureContext available in Workers (bug 1269052) is
>> problematic. Can we initially release the Storage API without Worker
>> support?
>>
>
> That sounds a tad worrisome. Is there a reason why we can't wait until we
> have SecureContext also in workers?
>

I encouraged Shawn to send this to gauge people's thoughts on whether we
could ship without Worker support. It seems you're on the side of waiting
until we have SecureContext support in Workers :)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Are we in favour of implementing the client hints header?

2016-03-07 Thread Andrew Overholt
 Implement Client-Hints HTTP header
https://bugzilla.mozilla.org/show_bug.cgi?id=935216
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: W3C Proposed Recommendation: Web Storage (Second Edition)

2016-01-07 Thread Andrew Overholt
On Thu, Jan 7, 2016 at 4:27 AM, Anne van Kesteren  wrote:

> On Thu, Jan 7, 2016 at 10:24 AM, L. David Baron  wrote:
> > Could you give a brief explanation of what the storage mutex is, and
> > why it was/should be removed?
>
> It prevents races for storage and cookies when your tabs run in
> independent processes. It was removed because nobody cared for
> implementing it.


Is that related to https://bugzilla.mozilla.org/show_bug.cgi?id=666724 ?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Collecting web platform features implementation status

2015-10-30 Thread Andrew Overholt
Harald (on CC) is working on it here:

https://github.com/mozilla/platatus
On Oct 29, 2015 6:38 PM, "Tom Schuster"  wrote:

> Seems like this kind of died. I still would like to see this happening. Is
> this on somebody's agenda?
>
> On Tue, Jul 21, 2015 at 8:40 PM, Tom Schuster  wrote:
>
> > I see 3 (now 4) old pull requests that are unmerged.
> >
> > On Tue, Jul 21, 2015 at 8:19 PM, Anthony Ricaud 
> wrote:
> >
> >> On 16/07/15 21:26, Anthony Ricaud wrote:
> >>
> >>> Potch and I are working on a website to present Mozilla's point of view
> >>> on various web platform features. Other browsers have similar websites
> >>> [1] [2] [3]. This project has been in lingo for a while so, to get it
> >>> out the door, we're going to focus on one information: what is
> Mozilla's
> >>> opinion on features that have not been shipped yet. We see 4 possible
> >>> answers: in development, favorable, not favorable, no opinion.
> >>>
> >>> In order to get accurate data and update it regularly, we need your
> >>> help. Please go to the following etherpad and insert any information
> >>> that can help us:
> >>> https://etherpad.mozilla.org/gecko-web-platform-dashboard
> >>>
> >>> Thanks for your help!
> >>>
> >>> [1] https://www.chromestatus.com/features
> >>> [2] https://status.modern.ie
> >>> [3] http://www.webkit.org/status.html
> >>>
> >> Reminder: We need your help! Please submit a pull request against
> >> https://github.com/Rik/platform-status/blob/master/features.json.
> >>
> >> (I've only received one pull request since moving this JSON to Github
> :( )
> >>
> >> ___
> >> dev-platform mailing list
> >> dev-platform@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-platform
> >>
> >
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Tracking bugs for preffing on Service Worker (1059784 for initial pref-on)

2015-06-10 Thread Andrew Overholt
We're using this meta-bug to track shipping Service Workers to the release
channel on desktop and Android:

https://bugzilla.mozilla.org/show_bug.cgi?id=1059784

For B2G-specific Service Worker issues we're using this meta-bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1131322

And for post-v1 bugs we're using this meta-bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1173500

When you're testing and filing bugs (of course you are), feel free to hang
them off the v3 meta-bug (1173500) or just file them in
Core::DOM::Service Workers. Testing network interception in non-e10s mode
is especially appreciated (because SW will hopefully ship first on a
non-e10s release)!

Thank you.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to implement: BroadcastChannel API

2014-10-01 Thread Andrew Overholt

On 01/10/14 04:46 AM, Mounir Lamouri wrote:

On Wed, 1 Oct 2014, at 10:51, Jonas Sicking wrote:

On Tue, Sep 30, 2014 at 3:54 AM, Mounir Lamouri mou...@lamouri.fr
wrote:

On Thu, 25 Sep 2014, at 02:49, Jonas Sicking wrote:

Yes!

Though as previously expressed, I don't think we should ship this until
it
supports sending Blobs.


What do other UAs implement?


I don't know. Does anyone else implement BroadcastChannel yet?


It seems an information that would be worth adding to Intent to
{Implement,Ship}.


Good idea.  Done: 
https://wiki.mozilla.org/index.php?title=WebAPI%2FExposureGuidelinesdiff=1020648oldid=1003407 
.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Tips for standardizing web APIs

2014-09-08 Thread Andrew Overholt
A few of us have written some tips and suggestions to make standardizing 
web APIs easier.  They're mostly intended for Mozillians and are most 
useful for those doing this for the first time.  If you have 
suggestions, please let me know.


https://wiki.mozilla.org/WebAPI/DesignGuidelines
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


30 minute weekly offline sync-ups Wednesdays at 8 AM Pacific

2014-06-10 Thread Andrew Overholt
Tomorrow (Wed June 11th) we're starting short weekly sync-ups on our 
Service Worker efforts with a primary focus on offline functionality for 
the web.


*Where*: WebAPI Vidyo room
*When*: see this URL for the time in your timezone:
http://arewemeetingyet.com/Toronto/2014-06-11/11:00/w/Offline%20sync-up

All of you lovely readers are welcome to join to hear how we're doing 
but I won't be sending reminder emails.  If you want me to send you a 
recurring calendar invite, email me.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Strengthening special cases language in API exposure guidelines

2014-04-21 Thread Andrew Overholt

Hi,

I've been told that it would be nice if we had stronger language in our 
API exposure guidelines [1] around when we deviate from them.  This is 
mostly applicable when we expose things to Firefox OS applications.  The 
changes I propose to the Special cases section [2] are:



-There will of course be special cases where we deviate from this
+There may be special cases where we deviate from this
 goal.  New user-facing products like Firefox OS may need to ship
 APIs that have not yet been embraced by other browser engines or
 thoroughly discussed by standards bodies.  This allows Mozilla to
 provide functionality that other browser engines aren't working
 on or the majority of the Web community isn't interested in at
 that time.  Examples of such functionality include telephony and
 Bluetooth.  This functionality is most often only exposed to
 Firefox OS applications of elevated privileges and not via the
 Firefox OS browser application.
+It is '''highly unlikely''' that we will expose this functionality
+to the web at large.


If you agree with the intent but have wording suggestions, please send 
them to me and let's avoid bikeshedding on the list.


If no one expressed disagreement here by Friday 25 April 2014, I'll make 
the changes on the wiki.


Thanks,

Andrew

[1]
https://wiki.mozilla.org/WebAPI/ExposureGuidelines

[2]
https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Special_Cases
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Mozilla development bootcamp

2013-10-31 Thread Andrew Overholt
I'm thinking all new contributors (volunteer or paid) and presented 
online as a series of videos (where applicable) with accompanying 
documentation.


On Wed 30 Oct 2013 04:14:17 PM EDT, Josh Matthews wrote:

Who is the audience? Where will this information be presented?

On 10/30/2013 02:58 PM, Andrew Overholt wrote:

I'm planning to coordinate development material for new contributors and
I'd like your input on what should be included:

   https://etherpad.mozilla.org/mozbootcamp

Thanks!


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Suggested API exposure guidelines redux

2013-10-30 Thread Andrew Overholt
After some more suggested revisions (thanks again), I made these 
guidelines official as of October 22, 2013.


Even though they aren't rules that are set in stone or anything like 
that, please consider these guidelines when exposing things to web content:


  https://wiki.mozilla.org/WebAPI/ExposureGuidelines
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Mozilla development bootcamp

2013-10-30 Thread Andrew Overholt
I'm planning to coordinate development material for new contributors and 
I'd like your input on what should be included:


  https://etherpad.mozilla.org/mozbootcamp

Thanks!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Suggested API exposure guidelines redux

2013-09-17 Thread Andrew Overholt

Hi,

When we expose new things to web developers, I'd like us to consider 
some suggestions.  Due to a number of factors, I've made them 
suggestions and not a set of pan-module hard rules.


  https://wiki.mozilla.org/User:Overholt/APIExposurePolicy

I've incorporated lots of feedback given on previous revisions (thanks!) 
and feel like this is ready to go.


Let me know if you want me to hold off on presenting these at an 
upcoming Tuesday engineering meeting and moving them out of User:Overholt.


Thanks,

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


WebAPI Meeting: Tuesday 20 August @ *8* AM Pacific [1]

2013-08-19 Thread Andrew Overholt

Last notice:  we've moved the meeting 2 hours earlier!

  8 AM in California
  11 AM in Toronto and New York, etc.
  16:00 in the UK and Portugal
  17:00 in most parts of Europe
  23:00 in Taipei

http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130820T08p1=224am=30

Meeting Details:

* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office

* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130820T08p1=224am=30
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


WebAPI Meeting: Tuesday 13 August @ *8* AM Pacific [1]

2013-08-12 Thread Andrew Overholt

We've moved the meeting 2 hours earlier!

  8 AM in California
  11 AM in Toronto and New York, etc.
  16:00 in the UK and Portugal
  17:00 in most parts of Europe
  23:00 in Taipei

http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130813T08p1=224am=30

Meeting Details:

* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office

* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130813T08p1=224am=30
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


WebAPI Meeting: **NEW TIME** Tuesday 6 August @ *8* AM Pacific [1]

2013-08-06 Thread Andrew Overholt

We've moved the meeting 2 hours earlier!

  8 AM in California
  11 AM in Toronto and New York, etc.
  16:00 in the UK and Portugal
  17:00 in most parts of Europe
  23:00 in Taipei

http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130806T08p1=224am=30

Meeting Details:

* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office

* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130806T08p1=224am=30
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


WebAPI Meeting: **NEW TIME** Tuesday 30 July @ *8* AM Pacific [1]

2013-07-29 Thread Andrew Overholt

We're moving the meeting 2 hours earlier!

  8 AM in California
  11 AM in Toronto and New York, etc.
  16:00 in the UK and Portugal
  17:00 in most parts of Europe
  23:00 in Taipei

http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130730T08p1=224am=30

Meeting Details:

* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office

* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130730T08p1=224am=30
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


WebAPI Meeting: Tuesday 23 July @ 10 AM Pacific [1]

2013-07-22 Thread Andrew Overholt

Meeting Details:

* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office

* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130723T10p1=224am=30 



Please comment on potential new meeting time:


https://groups.google.com/d/msg/mozilla.dev.webapi/ySb3gLSCYS8/1frJTXelNhUJ
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


WebAPI Meeting: Tuesday 16 July @ 10 AM Pacific [1]

2013-07-15 Thread Andrew Overholt

Meeting Details:

* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office

* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130716T10p1=224am=30 


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


No WebAPI Meeting July 9th

2013-07-08 Thread Andrew Overholt
Due to most regular attendees being at a work week this week, we'll skip 
our call and restart it next week (July 16th).


Send email or hop on #webapi for any issues.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Making proposal for API exposure official

2013-07-04 Thread Andrew Overholt
Thank you to everyone that provided feedback.  I've read everyone's 
comments and taken them into account with my new draft:


  https://wiki.mozilla.org/User:Overholt/APIExposurePolicy

In general I tried to make it more of a set of requests and guidelines 
than a set of musts.  I also clarified some of the wording around what 
it means for something to be standardized or ready for shipping.


It's ready for another round of feedback when people have time.

Thanks again!

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


WebAPI Meeting: Tuesday 2 July @ 10 AM Pacific [1]

2013-07-01 Thread Andrew Overholt

Meeting Details:

* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office

* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130702T10p1=224am=30 


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Making proposal for API exposure official

2013-06-26 Thread Andrew Overholt

On 24/06/13 01:50 PM, Kyle Huey wrote:

1. at least one other browser vendor ships -- or publicly states their
intention to ship -- a compatible implementation of this API

Because Apple and Microsoft generally do not publicly comment on
upcoming features, and Presto is no more, in practice this will boil
down to a minimum condition of the Blink developers stating their
intention to ship an API (in Chrome, presumably).  That feels too
restrictive to me.  Blink's policy talks about positive signals from
other vendors which is much more vague.  I worry that the proposed
language is too rigid and will either restrict us from innovating or
worse, be ignored.


What if we clarified earlier in the policy that things hidden behind 
flags are exempt from these requirements, like Ehsan pointed out Blink does?



4. Disputes between the API review team and the API developers will be
decided by the module owner for the API's area.

I'm not sure that there is even a module owner here to decide things.


How do you feel about Ehsan's suggestion of using the DOM module owner 
as an arbiter?



5. Once one week has passed [...]

This seems unnecessarily heavy-handed to me.


Agreed so I'll remove it.  I'm actually thinking we still have the email 
request but only to inform those who are interested in the feature 
landing but haven't been following the bug closely.  What do you think? 
 What about you, Ehsan?


Thanks for the feedback!

Andrew

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Making proposal for API exposure official

2013-06-26 Thread Andrew Overholt

On 24/06/13 05:52 PM, Ehsan Akhgari wrote:

There are two things that I think can use clarification.  One is what
we're going to do about trivial changes?  Do all web facing features
ned to go through this process?


I was going to put a blurb about trivial changes but thought it would 
be too hard to define.  Would you be okay with it being in there with 
something like definition of triviality is left up to the module owner?



The other question is, what we're going to do about negative feedback
from the API review phase but where the feedback cannot be incorporated
because of other concerns?


I was thinking the module owner (or I guess the DOM module owner in 
certain cases) would make the call.  But maybe I'm misunderstanding what 
sort of feedback you're thinking of; can you give an example?


Thanks,

Andrew

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Making proposal for API exposure official

2013-06-26 Thread Andrew Overholt

On 25/06/13 12:15 PM, Mounir Lamouri wrote:

  Note that at this time, we are specifically focusing on new JS APIs
and not on CSS, WebGL, WebRTC, or other existing features/properties.


I think the JS APIs here is unclear. I think saying Web APIs would
be more appropriate, assuming this is what you meant.


I waffled on this but if you think [Ww]eb APIs is more clear, I'll go 
with that.



Also, I do not understand why we are excluding CSS, WebGL and WebRTC. We
should definitely not make this policy retro-apply so existing features
should not be affected but if someone wants to add a new CSS property,
it is not clear why this shouldn't go trough this process.


My hope was to get something in place for APIs and then build up to 
other web-exposed things like CSS, etc.



1. Is the API standardized or on its way to being so?
2. Declaration of intent
3. API review
4. Implementation
5. Shipping


I think 2) should be Declaration of intent to implement and we should
add an item between 4) and 5) named Declaration of intent to ship.
Those two distinct items are important I believe.


Done.  Although note that others have expressed concern about the 
intent to ship-shipping situation.



2. at least two other browser vendors ship a compatible
implementation of this API


I will join Henri: browser vendors should be browser engines and


Fixed.


ship is too restrictive. If a feature is implemented and available in
some version (even behind a flag) with a clear intent to ship it at some
point, this should be enough for us to follow.


I changed it to at least two other browser engines ship (regardless if 
it's behind a flag or not in their equivalent of beta or release) -- a 
compatible implementation of this API .  How's that?  I don't want to 
see us basing our decision to ship on another engine's use of their 
nightly equivalent for experimentation (whether this happens right now 
or not).  Am I worried for no reason?



3.  at least one other browser vendor ships -- or publicly states
their intention to ship -- a compatible implementation of this API
and there is a specification that is no longer at risk of significant
changes, on track to become a standard with an relevant standards
body, and acceptable to a number of applicable parties


Actually, with this point, point 2) sounds barely useful. The only
situation when we could have 3) applying but not 2) would be if two
engines implement a feature that has no specification.


That was the situation I was thinking of :)


2. ecosystem- and hardware-specific APIs that are not standard or of
interest to the broader web at that time (or ever) may be shipped in
a  way to limit their harm of the broader web (ex. only on a device
or only in specific builds with clear disclaimers about applicability
of exposed APIs). An example of this is the FM Radio API for Firefox
OS.


When I read this, I read It is okay to have Mozilla ship a phone with
proprietary APIs. That means that we are okay with Mozilla creating the
situation Apple created on Mobile, a situation that Mozilla has been
criticising a lot. Shipping proprietary APIs on a specific device is
harming the broader Web if that device happens to be one of the most
used device out there...


The way you read it obviously not something we want to do.  What if we 
dropped the ecosystem-?  I can't see how we can allow ourselves to 
ship hardware-specific APIs that don't work everywhere without an 
exception like this.  Are there situations where we would ship such an 
API on desktop if there's very little chance of the required hardware 
existing there?



3. APIs solving use cases which no browser vendor shipping an engine
other Gecko is interested in at that time. In cases such as this,
Mozilla will solicit feedback from as many relevant parties as
possible, begin the standardization process with a relevant standards
body, and create a test suite as part of the standards process. An
example of this is the Push Notifications API.


I am not a big fan of that exception.


That was my attempt to not limit our ability to innovate without other 
engines.  I'm open to alternative phrasings.



Declaring Intent
API review
Implementation
Shipping


I think some clarifications are needed in those areas.


I changed the section headers to:

Declaring Intent to Implement
API review
Implementation
Intent to Ship and Shipping

How's that?


Intent emails
should be reviewed by dev-platform, not a API review team. In other
words, any one should be able to express its opinion and opinions will
be listened based on their technical value, not based on affiliation.


I added some wording to clarify that the email should do _both_.  I was 
also not assuming affiliation would necessarily define the API review 
team.



The issue with having dev-platform finding a consensus with intent
emails is that we might end up in a infinite debate. In that case, we
should use the module system and have the module owner(s) of the
associated area 

Re: Making proposal for API exposure official

2013-06-26 Thread Andrew Overholt

On 26/06/13 11:48 AM, Ehsan Akhgari wrote:

On 2013-06-26 11:21 AM, Andrew Overholt wrote:

On 24/06/13 05:52 PM, Ehsan Akhgari wrote:

There are two things that I think can use clarification.  One is what
we're going to do about trivial changes?  Do all web facing features
ned to go through this process?


I was going to put a blurb about trivial changes but thought it would
be too hard to define.


Sorry, I was wrong here.  I didn't put it in because I intended the 
policy to only cover new APIs.  I guess we could say new APIs or major 
changes to existing APIs ...


Andrew

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


WebAPI Meeting: Tuesday 25 June @ 10 AM Pacific [1]

2013-06-24 Thread Andrew Overholt

Meeting Details:

* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office

* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130625T10p1=224am=30 


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Making proposal for API exposure official

2013-06-24 Thread Andrew Overholt

On 21/06/13 06:05 PM, Benoit Jacob wrote:

Just to say, WebGL won't have to be an exception after all --- at least
not newer WebGL extensions.


Ah, thanks for letting me know.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Making proposal for API exposure official

2013-06-24 Thread Andrew Overholt

On 21/06/13 05:56 PM, Adam Roach wrote:

On 6/21/13 15:45, Andrew Overholt wrote:

I'd appreciate your review feedback.  Thanks.



I'm having a hard time rectifying these two passages, which seem to be
in direct contradiction:

 1. Note that at this time, we are specifically focusing on /new/ JS
APIs and not on CSS, WebGL, WebRTC, or other existing
features/properties

 2. This policy is new and we have work to do to clean up previous
divergences from it.


I expect that the first statement is the correct one, given that the
goal here is to prevent wholesale breaking of deployed sites. It also
aligns with what I've heard from parties who have been involved in the
conversations to date.


Yes, Don't break the web is an overarching goal but what I'm proposing 
deals specifically with new-to-the-web APIs.


The second statement you note above is me trying to indicate that we 
know we haven't been perfect at this in the past and need to go back and 
fix a few things.  Do you think I should just say that explicitly?


Thanks for the feedback,

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


WebAPI Meeting: Tuesday 18 June @ 10 AM Pacific [1]

2013-06-17 Thread Andrew Overholt

Meeting Details:

* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office

* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130618T10p1=224am=30 


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


WebAPI Meeting: Tuesday 4 June @ 10 AM Pacific [1]

2013-06-03 Thread Andrew Overholt

Meeting Details:

* Agenda: https://etherpad.mozilla.org/webapi-meetingnotes
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office

* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130604T10p1=224am=30 


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


WebAPI Meeting: Tuesday 28 May @ 10 AM Pacific [1]

2013-05-27 Thread Andrew Overholt

Meeting Details:

* Agenda: https://wiki.mozilla.org/WebAPI/2013-05-28
* WebAPI Vidyo room
* A room we can find, San Francisco office
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office

* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

Notes will be taken on etherpad:

https://etherpad.mozilla.org/webapi-meetingnotes

All are welcome.

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130528T10p1=224am=30 


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


WebAPI Meeting: Tuesday 30 April @ 10 AM Pacific [1]

2013-04-29 Thread Andrew Overholt

Meeting Details:

* Agenda: https://wiki.mozilla.org/WebAPI/2013-04-30
* WebAPI Vidyo room
* Amoeba conf. room, San Francisco office (7A)
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office

* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

Notes will be taken on etherpad:

https://etherpad.mozilla.org/webapi-meetingnotes

All are welcome!

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130430T10p1=224am=30 


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


WebAPI Meeting: Tuesday 23 April @ 10 AM Pacific [1]

2013-04-22 Thread Andrew Overholt

Meeting Details:

* Agenda: https://wiki.mozilla.org/WebAPI/2013-04-23
* WebAPI Vidyo room
* Amoeba conf. room, San Francisco office (7A)
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office

* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

Notes will be taken on etherpad:

https://etherpad.mozilla.org/webapi-meetingnotes

All are welcome!

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130423T10p1=224am=30 


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


WebAPI Meeting: Tuesday 9 April @ 10 AM Pacific [1]

2013-04-09 Thread Andrew Overholt

Meeting Details:

* Agenda: https://wiki.mozilla.org/WebAPI/2013-04-09

* WebAPI Vidyo room
* Amoeba conf. room, San Francisco office (7A)
* Spadina conf. room, Toronto office
* Allo Allo conf. room, London office

* Vidyo Phone # +1-650-903-0800 x92 Conference #98413 (US/INTL)
* US Vidyo Phone # 1-800-707-2533 (PIN 369) Conference #98413 (US)

* Join irc.mozilla.org #webapi for back channel

Notes will be taken on etherpad:

https://etherpad.mozilla.org/webapi-meetingnotes

All are welcome!

Andrew

[1]
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130409T10p1=224am=30 


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


WebAPI team plans

2013-04-03 Thread Andrew Overholt
Yesterday a number of people discussed future plans for the WebAPI team. 
 Our discussion resulted in the ideas and comments that are on this 
wiki page:


  https://wiki.mozilla.org/WebAPI/PlannedWork

We'll add items to that page as time goes by and we'll pop items off it 
as we work on them.  As always, we're interested in your suggestions and 
input so please feel free to get in touch via dev-webapi, #webapi, or 
our weekly meetings on Tuesdays at 10 AM Pacific in the WebAPI Vidyo 
room [1].


Thanks,

Andrew

[1]
https://wiki.mozilla.org/WebAPI#Meetings
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform