- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Wed, 21 Nov 2012 07:11:26 -0500
- To: olli@pettay.fi
- CC: ext Olli Pettay <Olli.Pettay@helsinki.fi>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
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. > 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 12:12:05 UTC