Re: [admin] Seeking comments re Issue tracking

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