- From: Dan Connolly <connolly@w3.org>
- Date: Wed, 15 Aug 2001 11:34:59 -0500
- To: Brian McBride <bwm@hplb.hpl.hp.com>
- CC: rdf core <w3c-rdfcore-wg@w3.org>
> Brian McBride wrote: [...] > It was suggested that parseType="Literal" could be dropped but Ron > Daniel and Eric Miller spoke up that there are users who use it. It > was suggested that the parser adding namespace definitions to the > literal might break an XML signature. Concern was raised over entities > in the literal. After discussion it was concluded that we needed to > investigate the applicability of the XML fragments spec. That's unclear, if not inaccurate. I, for one, did not agree that we *need* to investigate the applicability of the XML fragments spec; as I said, there's a perfectly reasonable design (using triples all the way down) that does not depend on XML fragments in any way. Moreover, I don't recall the chair actually explicitly asking that question of the group. Please be extremely careful about documenting decisions of the group. Ideally, for decisions made in telcons/ftf meetings, a question should be proposed, scribbled down by the scribe, read back to the participants by the scribe or chair, then any dissent should be noted, and finally, the chair should announce the disposition of the question (e.g. "ok, then we are agreed." or "ok, then we have consensus", or, in exceptional cases "ok, we don't have consensus, but we've discussed this as long as is productive and there's a clear majority in favor, so with the objection of Fred and Wilma noted for later review per W3C process, the motion passes"). Often you can get by with less ceremonty than that. But the record must be crystal clear regardless. It should have a special notation for decisions. I prefer RESOLVED: that frotznorbs are blue in all cases. Per W3C process[1], there are three dispositions for decisions: Unanimity/Consensus/Dissent. It's not essential to distinguish Unanimity from Consensus, but it is essential to document Dissent for later review. I particularly don't like the "it was agreed..." form used above in running prose because in this case, I'm quite certain the chair didn't put the question to the group, but the same "it was agreed..." form is used in cases where questions where formally put to the group, e.g. | It was _agreed_ that anonymous nodes in the model can be | distinguished from nodes with | supplied URI's. with _agreed_ linked to: [23:18:30] dajobe AGREED: answer to 1) YES with 2 abstentions [[[ 4.1.2 Group Consensus and Votes The W3C process requires Chairs to ensure that groups consider all legitimate views and objections, and endeavor to resolve them. Decisions may be made during meetings (face-to-face or distributed) as well as through email. The following terms are used in this document to describe the level of support for a group decision: 1.Unanimity: All participants agree. 2.Consensus: No participants object (but some may abstain). 3.Dissent: At least one participant objects. Where unanimity is not possible, the group should strive to make decisions where there is at least consensus with substantial support (i.e., few abstentions) from all participants. To avoid decisions that are made despite nearly universal apathy (i.e., with little support and substantial abstention), groups are encouraged to set minimum thresholds of active support before a decision can actually be recorded. The appropriate percentage may vary depending on the size of the group and the nature of the decision. A group charter may include a quorum requirement for consensus decisions. In some cases, even after careful consideration of all points of view, a group may find itself unable to reach consensus. When this happens, if there is a need to advance (for example, to produce a deliverable in a timely manner), the Chair may announce a decision to which there is dissent. When deciding to announce such a decision, the Chair must be aware of which participants work for the same (or related) Member organizations and weigh their input accordingly. When a decision must be reached despite dissent, groups should favor proposals that create the least strong objections. This is preferred over proposals that are supported by a large majority of the group but that cause strong objections from a few participants. The Chair decides when to resolve an issue in the face of dissent. In this case, a dissenter may request that any formal objections be reported at later review stages. Issues must be formally addressed In the context of this document, a Working Group has formally addressed an issue when the Chair can show (archived) evidence of having sent a response to the party who raised the issue. This response should include the Working Group's resolution and should ask the party who raised the issue to reply with an indication of whether the resolution reverses the initial objection. Formal objections must be archived and reported If dissenters say they can live with a given decision, this should be taken as an indication that the group can move on to the next topic, but the inverse is not necessarily true: dissenters cannot stop a group's work simply by saying that they cannot live with the decision. When the Chair believes that the legitimate concerns of the dissenters have received due consideration as far as is possible and reasonable, then objections must be recorded and the group should move on. A formal objection should include technical arguments and propose changes that would remove the dissenter's objection; these proposals may be vague or incomplete. The Chair must report an objection that includes such information to the Director at later review stages (e.g., in the request to the Director to advance a technical report to Candidate Recommendation). If an objection does not include this information, the Chair is not required to report it at later review stages. During an Advisory Committee Review, Advisory Committee representatives must be able to refer to archived objections. The Chair may reopen a decision when presented with new information The Chair may reopen a decision when presented with new information, including: additional technical information, comments by email from participants who were unable to attend a scheduled meeting, comments by email from meeting attendees who chose not to speak out during a meeting (e.g., so they could confer later with colleagues, for cultural reasons, etc.). The Chair should archive that a decision has been reopened, and must do so upon request from a group participant. Appeal of a Chair's decision Participants should always try to resolve issues within the group and should register with the Chair any objections they may have to a decision (e.g., a decision made as the result of a vote). When participants of a Member organization believe that their concerns are not being duly considered within the group, they may ask the Director (via their Advisory Committee representative) to confirm or deny the decision. The participants should also make their requests known to the Team contact. The Team contact is responsible for informing the Director when invited experts raise concerns about due process. Any requests to the Director to confirm a decision must include a summary of the issue (whether technical or procedural), decision, and rationale for the objection. All counter-arguments, rationales, and decisions must be archived. Votes Only after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, and that a vote is necessary to break a deadlock, should a group vote to resolve a substantive issue. In this case, the Chair must archive: the decision to conduct a vote (e.g., a simple majority vote) to resolve the issue; the outcome of the vote; any objections. A Working Group participant must be in good standing in order to participate in a vote to resolve a substantive issue. Working Groups may vote for other purposes. For instance, the Chair may conduct a "straw poll" vote as a means of determining whether there is consensus about a potential decision. Votes may also be used for arbitrary decisions. For example, it is appropriate to decide by simple majority whether to hold a meeting in San Francisco or San Jose; (there's not much difference geographically). When simple majority votes are used to decide minor issues, members of the minority are not required to state the reasons for their dissent, and the votes of individuals need not be recorded. A group charter may include voting procedures. ]]] -- 4 Working Groups, Interest Groups, and Coordination Groups http://www.w3.org/Consortium/Process-20010719/groups.html#WGVotes Thu, 19 Jul 2001 13:22:25 GMT -- Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Wednesday, 15 August 2001 12:36:04 UTC