[Bug 9187] Need transparency in issue and bug status in databases & document.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9187





--- Comment #10 from Maciej Stachowiak <mjs@apple.com>  2010-03-10 22:41:30 ---
(In reply to comment #6)
> Re: "I will try to split these up into one bug per issue."
> 
> Please don't. I submitted what I think is a coherent "bug". 

You made at least five concrete suggestions, and I would like the bugzilla
record to reflect which of those specifically was accepted or rejected. If
you'd like, I can make those five separate bugs in addition to this bug, rather
than instead of.


> I pointed out some examples of the "bug" and gave some proposed solutions, I'm
> not sure I've really hit them all, or the proposals that I made were the
> "right" ones. The main point of the "bug report" is that the process should
> maintain the integrity of the information about comments on specifications: for
> the record, for the next version, for reviewers, for all of the reasons why a
> standards process should be "open". 
> 
> I think there is requirement that comments get a response *from the working
> group*. There are several paths through the current process where a comment
> gets a response from one individuals (the editor) or a few (the chairs, who set
> a schedule for change proposals and judge whether the proposals are proper),
> and where the working group opinion isn't assessed except by the absence of
> objections, or (worse) the absence of anyone willing to both put in an
> extraordinary amount of "work" (one might even say "abuse") that comes along
> with making proposals. These steps may be necessary in order to get the
> document and the process stabilized quickly, but losing the visibility of the
> cases in which that happened isn't really in the best interest of anyone.
> 
> So, if we're following the current process, please, editors of the process
> document, either accept this bug 9184, resolve the bug, mark it as NEEDSINFO,
> WONTFIX or whatever, but don't split it up.

To be clear: the Chairs are using bugzilla to track issues with the decision
policy document because we need some way to track issues, and bugzilla is
available and convenient.

However, we do not intend to make the Decision Policy a publication of the
Working Group and therefore the Decision Policy does not really apply. Likewise
for bugzilla components such as "HTML WG website" and "testsuite" that do not
correspond to a current or proposed Working Draft and which are not intended to
ever go to Last Call.

I would expect that when we have a revised draft of the policy, we will have
the same kind of WG discussion and eventual Call for Consensus as we did on the
original policy.

> (There's a separate 'bug' in the process, if the editor of a document can split
> up a 'bug' into several other 'bugs' and then reject one or more of them as
> 'already decided by rough consensus'; that would be counter to the requirement
> to actually address the comment. )
> 
> (The notion that we're using the process to discuss the process seems odd --
> reminds me of Reddit's Nommit; is this really appropriate?)

It's definitely appropriate to have some process for updating the process.
Since you have yourself asked for changes and clarifications, I am not sure why
you think it's appropriate to mock the chairs for taking feedback, tracking it,
and planning to make changes. Constant use of scare quotes and repeated
comparisons to Nomic are not courteous or constructive, in my opinion.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 10 March 2010 22:41:32 UTC