Re: Issue closing procedure


I've been re-opening issues because they lack evidence that they been

We did agree that DCAT and Conneg close issues, but only after they have
been placed in the agenda. As DCAT is down to editorial issues, those
are noted briefly. The decisions that lead to closure do appear in the
meeting agendas, and the nature of the changes (not just the closure
decision) is often listed in the "due to close" comments in the issue.

Admittedly we have been more liberal with Conneg as it seems to be on
its own trajectory with the IETF work. However, the Conneg work has
followed procedure and I do not recall any instances (I try to read all
issues being closed - I may miss a few) where commenters have not been
asked if they now find the proposed solution to satisfy their concerns
before an issue is closed. It is this back-and-forth that shows that the
spirit of W3C procedure is being followed.

To close issues, there should be _consensus_ by all issue commenters
that the issue has been resolved. Resolved is not simply that a change
has been made to the document - it means that there is agreement that
the issue has been resolved and that is agreed by the person who opened
the issue or by those who have commented on the issue. Editors do not
decide on their own that an issue can be closed, that decision is a
consensus decision.

In addition, the entire WG must sign off on the publication of
documents. The reason why we asked for changes and issues for closure to
be brought before the group through the meeting agendas is that the
process of review by the whole group is spread out over the many
meetings which should speed the final review of the documents by the WG
at the point of vote on publication. If the group hasn't been "in the
loop" regarding changes, a longer review period will be needed to give
the WG members a chance to catch up when a draft is presented. Philippe
gave us this procedure as something he has found successful with the
"publish often" approach. It seems to also be useful for the "publish
less often" approach that DCAT is using. It remains to be seen how much
time will be needed for Conneg review as we haven't gotten there yet.

I will reiterate procedure:

1) meetings have agendas, and are scheduled to the extent possible to
include all WG members who wish to attend.
2) meetings are followed by minutes that record discussions and
decisions; these latter are subject to review by the WG
3) any member(s) of the group can bring up issues, up to the point that
a vote is taken and a WG decision is made; even that can be re-visited
if anyone asks for that
4) all decisions ultimately are decisions of the WG as a whole
5) all comments, whether from WG members or external persons, get
considered, and work is done to satisfy the commenter; if there is
disagreement, there is a procedure for "agreeing to disagree". Please
see the consensus document [1] which states:

"Consensus is a core value of W3C. To promote consensus, the W3C process
requires Chairs to ensure that groups consider all legitimate views and
objections, and endeavor to resolve them, whether these views and
objections are expressed by the active participants of the group or by
others (e.g., another W3C group, a group in another organization, or the
general public)."

That document also says:

"To avoid decisions where there is widespread apathy, (i.e., little
support and many abstentions), groups should set minimum thresholds of
active support before a decision can be recorded."

I also suggest reading the section on "Formally Addressing an Issue"
[2]. It says:

"In the context of this document, a group has formally addressed an
issue when it has sent a public, substantive response to the reviewer
who raised the issue. A substantive response is expected to include
rationale for decisions (e.g., a technical explanation, a pointer to
charter scope, or a pointer to a requirements document). The adequacy of
a response is measured against what a W3C reviewer would generally
consider to be technically sound. If a group believes that a reviewer’s
comments result from a misunderstanding, the group should seek
clarification before reaching a decision."

In this context, "reviewer" can be someone in the Working Group or an
outside reviewer. The response takes the form of an explanation that
(one hopes) will satisfy the reviewer. The reviewer can respond if not
satisfied. It's basically iterative.

There are a number of issues relating to the profiles vocabulary which,
in my opinion, have not been formally addressed. We can take a look at
specific issues and discuss this aspect if that would help, although I
admit that the number at this point is rather daunting (33 open issues
that are the result of external feedback [3]; 88 total open issues)[4].
There must be some form of resolution for all issues before any work
item can become a recommendation.



On 8/22/19 2:18 PM, Nicholas Car wrote:
> Hi Karen,
> It may have been decided when you were away but we are not following the
> procedure you mention below whereby Issues are marked due-for-closing by
> editors and then closed only by chairs. Since that note on March 19 you
> refer to, we discussed procedure in a plenary meeting and the Conneg
> editors, not the chairs, have closed many Conneg issues. The DCAT
> editors, not chairs, have closed dozens of DCAT Issues. 
> For a DCAT example, see for a
> single closed example and
> see and
> note that there are at least 2 pages of DCAT Issues closed since March
> 19, not by chairs.
> Looking back at previous plenary meeting minutes, I’ve previously
> statically listed many Conneg Issues marked due for closing,
> e.g., and
> DCAT only has only done so once or twice: certainly not all the Issues
> they have closed have been listed. Mostly a link to the GitHub Issues
> has been provided only.
> So, please stop re-opening all Issues we close by default. If you have a
> specific reason to reopen an Issue we have closed, please do so, as
> anyone may, but in general, it is for editors, not chairs, to close
> Issues and we will be closing them as we need to as we tidy our issues. 
> Generally we will try and mark Issues due-for-closing for a week before
> actually closing but this is not a hard rule: sometimes we will directly
> close Issues we discover that have been superseded or have been dormant
> for a long time and should have been closed previously.
> Thanks,
> Nick
> — 
> Nicholas Car
> Data Systems Architect
> SURROUND Australia
> 0477 560 177
> <>
> On 23 Aug 2019, at 1:59 am, Karen Coyle via GitHub <
> <>> wrote:
>> @nicholascar The roles in 2pwd are not what was "determined" from the
>> discussion. In fact, there were no agreed roles or definitions as that
>> discussion was only just getting started and consensus was far from
>> being reached.
>> Also note that as per the [March 19
>> meeting](
>> github issues are to be marked "due for closing" and @pwin  and I will
>> close them if we feel they should be closed. Please mark issues but no
>> not close them.
>> -- 
>> GitHub Notification of comment by kcoyle
>> Please view or discuss this issue at
>> using
>> your GitHub account

Karen Coyle
skype: kcoylenet

Received on Friday, 23 August 2019 00:09:40 UTC