W3C home > Mailing lists > Public > public-test-infra@w3.org > January to March 2013

RE: Test Management Task Force

From: SULLIVAN, BRYAN L <bs3131@att.com>
Date: Sat, 23 Feb 2013 15:59:34 +0000
To: Tobie Langel <tobie@w3.org>, Robin Berjon <robin@w3.org>, "jet@mozilla.com" <jet@mozilla.com>, "yfuna@tomo-digi.co.jp" <yfuna@tomo-digi.co.jp>, Rebecca Hauck <rhauck@adobe.com>, Mclister Laurence <lmcliste@adobe.com>, Bob Lund <B.Lund@CableLabs.com>, "peter.linss@hp.com" <peter.linss@hp.com>
CC: "public-test-infra@w3.org" <public-test-infra@w3.org>
Message-ID: <59A39E87EA9F964A836299497B686C35109C9B4A@WABOTH9MSGUSR8D.ITServices.sbc.com>
I think we should keep all test management aspects in the same TF, including browser vendor interfacing (and in general externally-sourced test ingestion), and build process dependencies. The key need IMO is to get owners into the table at the TF wiki, and to begin building the notes for these items (including breaking them further down as needed).

Bryan Sullivan 

-----Original Message-----
From: Tobie Langel [mailto:tobie@w3.org] 
Sent: Friday, February 22, 2013 4:53 PM
To: Robin Berjon; jet@mozilla.com; yfuna@tomo-digi.co.jp; Rebecca Hauck; Mclister Laurence; Bob Lund; peter.linss@hp.com
Cc: public-test-infra@w3.org
Subject: Test Management Task Force

Hi all,

I've set up a home for the Test Management Task Force[1].

This task force's role is to look at test management and see how we can improve and simplify through lighter process and better tooling.

Like all other testing task forces we'll be using the public-test-infra@w3.org (mailto:public-test-infra@w3.org) mailing list. If you haven't already, please sign-up for it[2].

As you're probably well aware by now, I'm a strong proponent of moving to a GitHub-based workflow[3] and building lightweight tooling on top of it[4].

This raises a number of issues:

1. Moving to GitHub represents a number of different risks. These risks need to be assessed and a mitigation strategy defined and its cost estimated.

2. Moving to GitHub also represents an upfront migration cost. For certain group, this is trivial and doesn't even need to be budgeted. For other, however, this migration might be costly and complex (I'm thinking mainly about the CSS WG with its Shepherd tool, here). First of all we must enquire to see if these groups are interested in migrating. If so we must define what feature set such groups need in a new system and estimate their cost. We must also define a migration strategy and estimate its costs.

I'll be preparing a document for the first point shortly and will enquire on the risk mitigation costs directly with W3C sys team.

I'd be very interested to hear your thoughts on the second point, especially Peter's who is directly concerned.

Lastly, I've started digging two other tangentially related subjects, upstreaming and repo syncing with browser vendors, and handling test suites which have build steps (i18n, accessibility, WebIDL auto-generated tests, etc). Would you be happy to have this conversation within this task force or do you feel like we should create a dedicated task force for it?

Thanks for your input.


[1]: http://www.w3.org/wiki/Testing/Test_Management_TF
[2]: Just send an email to mailto:public-test-infra-request@w3.org

[3]: http://www.w3.org/wiki/Webapps/Submitting_tests

[4]: http://w3c.github.com/testing-task-forces/test-management-tooling.html

Received on Saturday, 23 February 2013 16:00:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:34:08 UTC