Announcing a Hackathon event at the Prague IETF

**

*This is to announce that we are trying to ar*r*ange a*WEBRTC Hackathon
Event* at the IETF in Prague in March*.**

*

Specifically, as part of the IETF Hackathon event - March 23 and 24 (Sat
and Sun before the IETF). **

Some preliminary thoughts below. *Action requested:**//**We'd like to
have representatives of multiple browser development teams present -
ideally, we'd like one*

*person to be a contact point for each browser, with the responsibility
to make sure we have a test setup that will give us*

*the support we need before the meeting.*

*
*

Harald, for the chairs


**

*Suggested time: Prague IETF, Hackathon event*

*Suggested format: Grab a table during the IETF hackathon*

*

Target: Work on WEBRTC testing

Possible goals:

  *

    Get tests written that cover interesting use cases

      o

        WPT testable things

      o

        KITE testable things

  *

    Get browsers fixed to actually pass tests

      o

        Requires approvers to be present

      o

        Requires off-site resources available

Things that need to happen up front:

  *

    Get a list of things that need to be worked on (“the backlog”)

  *

    Make a setup to show improvements

      o

        Could have a KITE or a WPT testbench into which we can upload
        tested browsers and new tests

      o

        Test-writers’ goal is to cause more failures

      o

        Fix-writers’ goal is to reduce the # of failures

      o

        Make it a race :-)

We can NOT expect to actually submit code into respective canaries, so
if we want to show off merged results of fixing bugs, we need to have
some integration that collects the fixes on an “ad hoc” basis.

*

Suggested time: Prague IETF, Hackathon event

Suggested format: Grab a table during the IETF hackathon


Target: Work on WEBRTC testing


Possible goals:

  *

    Get tests written that cover interesting use cases

      o

        WPT testable things

      o

        KITE testable things

  *

    Get browsers fixed to actually pass tests

      o

        Requires approvers to be present

      o

        Requires off-site resources available


Things that need to happen up front:


  *

    Get a list of things that need to be worked on (“the backlog”)

  *

    Make a setup to show improvements

      o

        Could have a KITE or a WPT testbench into which we can upload
        tested browsers and new tests

      o

        Test-writers’ goal is to cause more failures

      o

        Fix-writers’ goal is to reduce the # of failures

      o

        Make it a race :-)


We can NOT expect to actually submit code into respective canaries, so
if we want to show off merged results of fixing bugs, we need to have
some integration that collects the fixes on an “ad hoc” basis.


*

-- 
Surveillance is pervasive. Go Dark.