W3C home > Mailing lists > Public > public-pointer-events@w3.org > October to December 2012

Re: [admin] Seeking comments re Issue tracking

From: Rick Byers <rbyers@google.com>
Date: Wed, 21 Nov 2012 09:48:31 -0500
Message-ID: <CAFUtAY-nZtUmMV9GZHEKMcjJMxhewAAgL=QOXZfeDsYUntu6HA@mail.gmail.com>
To: Arthur Barstow <art.barstow@nokia.com>
Cc: olli@pettay.fi, ext Olli Pettay <Olli.Pettay@helsinki.fi>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
On Wed, Nov 21, 2012 at 7:11 AM, Arthur Barstow <art.barstow@nokia.com> wrote:
> On 11/21/12 6:48 AM, ext Olli Pettay wrote:
>>
>> On 11/15/2012 04:25 PM, Arthur Barstow wrote:
>>>
>>> All,
>>>
>>> I'd like to get some feedback re how the group will track issues. A meta
>>> issue here is what we mean by "issue"and to a large extent, it depends on
>>> the
>>> context. In some cases, Issues are relatively broad e.g. "should spec A
>>> implement feature X" and in other cases an Issue could be much more specific
>>> e.g. "should parameter foo be a long or an unsigned long".
>>>
>>> If we want to try to track issues, I think the main options are:  a)
>>> Issues are bugs so just use Bugzilla(or whatever bug db we decide to use);
>>
>> Bugzilla please. Tracker is not open.
>
>
> This is a good point re Tracker.
>
> It also touches on the topic if this group should consider Issues (as used
> in the context of WebEvents and tracked via Tracker) the same as Bugs. I
> suspect this view (used by WebApps WG) is more common and eliminates the
> "oh, so is `X` an Issue for Tracker or a Bug for Bugzilla?" type questions.
>
> Using Bugzilla for Issues too is OK with me and does help "keep things
> simple" so it gets a +1 from me. If anyone can't live with that, please
> speak up.

Sounds great to me - +1 for simplicity.

>>  b) use
>>>
>>> Tracker (as is done by WebEventsWG); c) Issues should be explicitly
>>> identified in the appropriate spec.
>>
>> Not sure what c) means, but certainly bug reports should describe what the
>> bug is about.
>
>
> c) is about the Editor using an explicit "Issue block" in the spec as a way
> to clearly identify a part of the spec as an issue, problem, area for
> feedback, etc. (See <http://dev.w3.org/2006/webapi/clipops/clipops.html> for
> some examples).
>
> -Art
>
>
>
Received on Wednesday, 21 November 2012 14:49:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:24 UTC