-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Meta issue on the VCDI deliverable #65
Comments
I agree 100%.. even without merging the open PRs, the section is unacceptable in its current form. See #54 We need to be much clearer with respect to that section.
Yes, this will happen, until the section is revised such that discussions can end because the section is comprehensible.
-1 to this, I would prefer we merge all the PRs, and then refactor the section to make it clearer. It's actually harder to do it the other way round, because there are not enough illustrative examples.
We have a problem with the charter in its current form, we should expect objections. The solution is to iterate faster, or it will simply take longer to get rid of the objections, and the discussions will continue to be about "the way we wish it was written" instead of what is actually written in the charter. |
I can close it now. Whether #77 or not, the discussions are clearly in direction to solve my original problem. |
I did not want to repeat the same comment on a number of PR-s (namely #47, #51, #50, or #63 but also on issue #54): I am a bit worried about the common thread across of all these. In my view, we are trying to do too much in the description of that deliverable. Namely, (and I admit that I am out of my depth as for the technical content) the various issues and PRs seem to intend to give some sort of exhaustive list of technologies that this deliverable would include, not even making clear whether those references and technologies would be a normative part of that deliverable or not (this came up, I believe, in the discussion on #50). Is this a realistic goal? Isn't it possible to restrain the charter to a more manageable and succinct description of the deliverable, and leave the exact choice of input technologies to the Working Group to decide?
Clearly, my worry is that we will continue to have no end to this discussion, dragging the charter discussion. I would prefer to suspend (close?) all those PRs and concentrate on a thorough re-formulation of the deliverable description. If we cannot have a succinct definition of the Deliverable in a short paragraph, we may have a problem with that part of the charter altogether.
Cc @brentzundel @Sakurann @msporny @OR13 @mprorock @bumblefudge
As an aside, and this came up in an issue raised by @samuelweiler in #56, the list of documents are not "Draft states". They are "Input documents". An important distinction that, unfortunately, the current template charter does not make, hence its presence in the current text.
The text was updated successfully, but these errors were encountered: