Comments (12)
If the intention is to rely on the Team's judgement that open issues raised in wide review are not inappropriately lingering, then the Process should say so.
Under the current text, I'm not sure the Team is actually even supposed to take that into consideration, but can consider Formal Objections, and I don't think we need even more of the Process to rely on filing of Formal Objections.
from w3process.
I don't think we should require that all view review comments have been addressed: it is a work in progress, and adding that requirement would be a lot more likely to dissuade people from publishing at all, rather than ensure exhaustive fixes. However, some exhortation to be processing the issues filed, and to have at least addressed some, would seem appropriate, as just flat out ignoring these comments isn't ok.
Not sure where to draw the line, but maybe we don't have to be to precise, and can indeed rely on team verification to judge whether a good faith effort at addressing issues is ongoing or not.
from w3process.
we can maybe require that they consider all open issues and make a 'decision' not to address some when publishing a specific update; that makes it subject to someone formally objecting, no? or maybe we could even say that not addressing an issue in an update is implicitly a decision not to do so, and such an (implied) decision can be formally objected to
from w3process.
plh: what worries me is Mike Champion's last request, that update requests be subject to the same requirement as transition requests.
That's @npdoty's "request", I just said I don't have any concerns about it. I said the Team should make sure corner cases in the Process aren't exploited, @npdoty asks for more explicit Process language about this scenario, and I could live with that.
from w3process.
In the meantime / as a backdrop, I would expect that if this practice were taking place, we would expect to start seeing Formal Objections to Update Requests, or to the Team's decision to approve an update request. But that doesn't seem like the preferred way to go: it adds the extra cost of handling more Formal Objections, and it adds an unnecessary burden (to those raising issues or horizontal review groups generally) to making sure that raised issues are addressed.
from w3process.
rely on team verification to judge whether a good faith effort at addressing issues is ongoing or not.
Right. The whole point of "living standards" is to reduce the bureaucracy and politics required to get a reasonably authoritative draft to those implementing and deploying a spec. This depends on "wide review" of DEPLOYED specs by users as well as spec-writers and implementers. It also assumes rapid iteration to fix real-world problems.
Yes, there is a potential for abuse, e.g. continuing to publish specs even if they are getting serious issues raised by horizontal review. I think that's where the Team comes in: They are supposed to be expert and neutral enough to recognize such situations, and with enough authority stop publishing truly problematic specs as if they were authoritative. Or stop continuing to support WGs that abuse the process.
Trying to fix such corner cases in the Process itself adds to the perceived "bureaucracy", and will drive more work other venues.
from w3process.
The lack of Formal Objections is essentially what "consensus" means in the Process. 🤷
I don't think the Process can anticipate all the reasons for not advancing a spec. It was traditionally the Director's judgment call. That judgment has mostly moved to the Team collectively, under the authority of the CEO.
from w3process.
Having addressed issues or not is the kind of thing that shouldn't be too difficult to describe in a Process document, even when it relies on judgement. For example, the W3C's Process already has that requirement for transition requests, where it's a single bullet point.
from w3process.
Sorry, I think I misunderstood the issue. I don't have any concerns about Update Requests being required to meet the Transition requirements
from w3process.
[[
Florian: is this relevant to the WHATWG MOU?
PLH: no
cwilso: yes
plh: what worries me is Mike Champion's last request, that update requests be subject to the same requirement as transition requests.
florian: ah yes. I Don't think we want to require everything be addressed; that would make it difficult to do CR updates.
florian: it's not clear that the team has the ability to say "you have made progress on issues that you care about, but ignored everything that others have reported, so your update request is denied"
+1 to florian
florian: something along those lines would be desireable.
plh: we did not introduce a requirement to address issues during the update requests, but we did introduce requirements to at least note which issues are flagged as needs resolution. Add horizontal-review restrictions on transition
]]
https://www.w3.org/2023/09/27-w3process-minutes.html#t04
from w3process.
My request was one of two things:
- either by formally requiring [addressing issues] for some Snapshot publication (maybe the current or next one),
- or for giving substantive guidance to the Team that they should evaluate open issues when determining whether to approve update requests.
Those are less strong than applying all the same requirements of Transition requests, although that would also satisfy this issue.
from w3process.
The Revising W3C Process CG just discussed CR Snapshots need to address wide review issues
, and agreed to the following:
RESOLVED: Merge PR 787
The full IRC log of that discussion
<fantasai> Subtopic: CR Snapshots need to address wide review issues<fantasai> github: https://github.com//issues/781
<fantasai> PR: https://github.com//pull/787
<fantasai> fantasai: People inside the group can object to publishing a CRS, but people outside the group can be ignored indefinitely
<florian> q+
<fantasai> fantasai: so this trying to fix this by giving the Team some discretion in denying a CRS
<fantasai> Changes: https://github.com//pull/787/files
<florian> fantasai: we already have CRD, which people can publish at will
<fantasai> florian: Fact that ppl can ignore issues is not true for transition requests (changing stage)
<fantasai> florian: This doesn't make it a requirement to address all the issues, but sets expectation that you should make some progress on such issues, and allows Team to deny CRS if not
<florian> fantasai: any other opinion?
<fantasai> TallTed: Just one grammar fix
<fantasai> florian: pre-existing wording, but could fix as we go?
<fantasai> PROPOSED: Merge PR 787
<TallTed> +1
<florian> +1, including TallTed's tweak
<cwilso> +1
<fantasai> RESOLVED: Merge PR 787
from w3process.
Related Issues (20)
- Chair should be required in charter HOT 38
- Run link checker on Process Drafts HOT 3
- Determining AC Consensus of Post-Review Changes HOT 8
- Description of the role of the AB HOT 9
- TAG appointment ambiguity about ratification by both AB and TAG HOT 14
- Ambiguity about (super) majority thresholds: of those voting, or of those eligible to vote? HOT 8
- Dealing with procedural disagreements within the Council
- Multiple possible outcomes of a successful AC Appeal HOT 2
- Align with Bylaws changes
- Making the Council's short circuit a little more flexible HOT 10
- Member Associations to Liaison Relationships HOT 2
- Creating a more visible banner for old process documents HOT 2
- Retire the "Streamlined Publication Approval" system HOT 3
- Proposed Recommendations aren't useful in the same way other maturity stages are HOT 5
- Switching tracks **and back** HOT 5
- Enhancing the W3C REC Update Process for Greater Efficiency and Engagement HOT 2
- FPWD and joint deliverables—the process may be missing an exclusion opportunity HOT 5
- Visibility of FO handling HOT 3
- repo name nit: it'd be nice if this were simply w3c/process HOT 9
- Inaccurate text about Membership Agreements
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from w3process.