W3C home > Mailing lists > Public > www-dom-ts@w3.org > June 2001

SV: SV: Minutes in brief and action items

From: Dimitris Dimitriadis <dimitris.dimitriadis@improve.se>
Date: Fri, 1 Jun 2001 21:15:26 +0200
Message-ID: <9F67DC27F4CCD311ABA600508B6A66A44A66B2@VXOIMP1>
To: "'Fred L. Drake, Jr.'" <fdrake@acm.org>, "Arnold, Curt" <Curt.Arnold@hyprotech.com>
Cc: www-dom-ts@w3.org
In general, it looks as if we need to differentiate the site for
developing/issue tracking, from the site where resources will finally
reside, which is (primarily) www.w3.org/DOM/Test. Mirrors can be put
anywhere, which is good since we enhance visibility.

Curt, if you think I can contribute, could you add me to the admin list?


-----Ursprungligt meddelande-----
Från: Fred L. Drake, Jr. [mailto:fdrake@acm.org]
Skickat: den 1 juni 2001 18:57
Till: Arnold, Curt
Kopia: www-dom-ts@w3.org
Ämne: RE: SV: Minutes in brief and action items

Arnold, Curt writes:
 > The key configuration item is to define the categories of bugs and
 > groups.  Though these could evolve, it would be good to have a
 > reasonable starting set.

The first thing to do is to define the distinction between "Category"
and "Group" -- the last time I looked, SF did not provide any guidance
on this, but it makes a difference.  For Python, we use "Category" to
describe components/aspect of the software (documentation, build
system, parser/compiler, library modules, etc.), and "Group" to
describe the bug (irreproducable, not a bug, third-party bug,
platform-specific, etc.).  It's not clear that the bug, feature
request, or patch trackers should be separated -- I have a *strong*
suspicion that that adds navigational complexity without adding value.
I would suggest enabling only one of those three & calling it a "bug

"Documentation" is always a good category.  Note that comments on
project Web pages may also end up here.  For this project, perhaps
we should also consider "xUnit Conversion" (with *which* xUnit being
largely indicated by who it's assigned to) or have a "fooUnit
Conversion" for each "foo" that's covered.  Another category could be
"Schema/DTD", covering the schema/DTD and their generation.
Additional categories should be added for other "subprojects".

 > If anyone knows how I can remove mbrady (Michael Brady) from the
 > developer list, please let me know.

  It looks like you've figured this out already, so I'll replace the
text I started to write with this sentence.  ;-)


Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations
Received on Friday, 1 June 2001 15:16:05 UTC

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