-
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
Two years continued restrictions on deliverables is problematic #114
Comments
@jandrieu, let me outline the thoughts behind this charter (as also presented at WG calls). Because the current charter ends in June, we are under the obligation to do something. I.e., at the minimum, to extend the current charter. An extension of 6 months would be almost automatic (taking into account that we have all our Rec track documents in CR) with the W3C management. A longer extension would probably not be allowed, we would be under the obligation to re-charter through an AC vote. These are the current W3C constraints. This charter proposal gives us a breathing space. Namely, in practice, it is an extension plus it ensures that the Recommendations, once published, will be maintained. The proposal is intentionally minimal, and would, hopefully, go through an AC approval in time before the current approval runs out. It would buy us 2 years and would save the WG the obligation to start, right now, the tedious discussion that should precede any new, totally re-worked charter. Personally, I do not believe the WG would have time and energy to conduct such discussion now. Once all Recommendations are published (hopefully Jan 2025), the WG will have time to conduct a relaxed discussion on where to go after this. We may even decide to start this discussion earlier (e.g., at TPAC) without any time pressure on us. A new charter can then be completely re-worked, new items added, etc.; we can plan to do so once the current work load disappears. We are not required to wait until the end of the 2 years to recharter; we can decide, at any time, to do so.
IMHO, It is to finish and to ensure continuous maintenance of the current work. |
@jandrieu are you satisfied with the answer I gave in #114 (comment)? We should then close this issue... |
@iherman I'd like to see this discussed on the WG call before we close it. There are several deliverables that were refused because of timing. To continue to refuse consideration of that work for two years, just because of a perceived logistical advantage doesn't seem appropriate. Of course, if the group has a consensus to push back the ability to advance new work, I'll support the charter. It just seems the charter scope is designed to simplify staff work, without consideration for how it will prevent the opportunity for AC/DC, confidenceMethod, and other features to be brought into the W3C VC sphere. I'd be much more comfortable with a 6 month extension to finish what we started, then a consensus driven discussion about where we go next. |
We should close this issue in some way or other very quickly. Some steps must be done quickly, because the current charter runs out in about 6 weeks. @brentzundel, can you put this on the agenda for the next call on 15th of May? (I may not be on the call for family reasons, but I do not think we should drag on with this.) |
@jandrieu would a 1.5 years charter limit be a possible compromise? That would give the group one year to agree on what future technical/recommendation work the group might want to pursue. I think the core disagreement we have is on the timing of that agreement. This is a social/practical issue: I just do not see the WG having enough time, energy, willingness, etc., to seriously discuss plans for fundamentally new recommendations now. The work necessary to finish the work within the coming half year will just take up all the group's energy, in my view at least. Case in point: it took three weeks to discuss only two issues that this charter extension proposal generated. If we restricted the timing to one year, as you propose, this would mean the group would have 6 months to get to an agreement (starting January). Looking at the time it required for this community to re-charter this WG or the DID WG, I do not think this is realistic. A full year may be o.k. (B.t.w., the load on the current WG has just been slightly increased by the introduction of yet another rec-track document, namely the controller document, to the lot of recommendations to be published next January.) |
What additions are you looking for in the charter, Joe? Your issue doesn't say. |
Do you have specific work items in mind that you believe the group should tackle? We've already increased scope to include the controller document spec. If there are other important pieces of work we should consider them individually. +1 to discussing on a call before making a deicision. |
The issue was discussed in a meeting on 2024-05-15
View the transcript2.1. Two years continued restrictions on deliverables is problematic (issue vc-wg-charter#114)See github issue vc-wg-charter#114. Joe Andrieu: There were decisions in Miami due to timing. Manu Sporny: The ACDC decision was not just about timing.
Manu Sporny: We want to have that discussion in a way that enables broad feedback. Ivan Herman: The experience with our own community is that creating a new charter is subject to long and tedious discussions.
Ivan Herman: I don't see anything happening on a new charter until January.
Joe Andrieu: We have a few things that are at risk. Ivan Herman: About two months ago there was a WG discussion. Manu Sporny: It used to be possible to publish a note and convert it to a recommendation.
Manu Sporny: Confidence Method and Render Method is right up there.
Manu Sporny: I would personally -1 to new work until we finish what we've started.
Manu Sporny: We could incubate these things in the CCG. Joe Andrieu: I think if we cannot include work that's currently noted as at risk, I will oppose rechartering. Manu Sporny: They're not getting done because people aren't doing the work.
Manu Sporny: A working group isn't required to use the extension points. Ivan Herman: We have 1 month left in our charter. Joe Andrieu: I want the charter change. Ivan Herman: At any time, we can decide what we want in a new charter and recharter.
Manu Sporny: I don't know what new text you want in the charter.
Manu Sporny: Once we add new things, there will likely be objections. Gabe Cohen: +1 to what Manu said.
Gabe Cohen: Let's also have a path to do new work like Confidence Method in the future. Brent Zundel: We're going to move on. Ivan Herman: I plan to submit the existing charter text to the AC. Brent Zundel: Joe, If we proceed with this charter, do you plan to formally object? Joe Andrieu: I want you to enable adding new items in this charter. Brent Zundel: We are going to stop talking about this. |
I'd be happy to support this charter if we can include deliverables based on current "at risk" content, such as adding confidenceMethod as a property in the VCDM and likely a specific method, e.g., DID Auth, as a deliverable. These are things that can be done under the current charter, but which would be precluded from this current proposal. The current proposed language prevents such normative work without rechartering. Given the conversation on the call today, I agree that it might take more than the time we have left to work through rechartering questions. We probably should have started charter development before the deadline became a forcing function. The haste with which this decision is being advocated is unfortunate. We should probably just take the "free" six month extension without any changes to the charter and take that time to (1) allow at risk items to resolve (2) develop an acceptable new charter. |
@jandrieu could you list the additional work items that you want included in this charter draft? |
Note that I have already notified the W3C management that the current charter proposal does not fly, and we ask for a 6 months extension. As we said on the call. This also means that the full charter has to be re-thought. The deadline for a WG consensus should be around the end of September if we would hope to have a new charter end of January. |
Yes. In part. It's not clear if Ivan has already pulled the trigger or not, but all I'm asking for is that current at risk features (which today have no restrictions on their development) are explicitly in-scope under the new charter, including any rec-track documents needed to support them. FWIW, @msporny expressed just now that his understood intention of the charter was that it would enable continuation of the current work (as defined by the CR and its associated specifications). If that's the intention, then I think this is just a wordsmithing problem. Because to my read, the current proposed charter does not achieve that goal. To be specific: the particular at-risk feature I care about is confidenceMethod. However, I don't know what work items might be needed to support that so I can't give an exhaustive list. No one can. Which is why the charter should not exclude doing what it takes to get these features standardized. Hopefully that answers your question, @brentzundel |
(Admin)
Yes, I have: see #114 (comment). As I also said: if we have a consensus on the content of a new charter (without editorial details) at, say, the end of TPAC, and if we do not hit some unexpected hiccup via FO-s during the AC voting procedures, there is some hope to have a new charter in place in February, i.e., we do not find ourselves in a complete hiatus (including maintaining the new Recommendations). |
(More on the content, but also Admin):
Note that the "at risk" features are supposed to be removed from the spec when we go to Proposed Rec. In other words, we will have to review them one-by-one, probably at TPAC. That might be the good place to make a list of those at-risk features which should be added to the charter as being in scope or not. But I am not sure that covers all the contentious issues. You referred to AC/DC: I do not think that is in the list of at risk features. |
So now is the time to review the at-risk features and decide if any are worth adding to the renewed charter, is that a correct understanding? Without calling out specific at-risk features the group will focus on I do not see how the features will ever not be at risk. |
Reacting on the form only (and not on individual features): If we decide to call out the (current) "at risk" features in the charter proposal, the (new) WG will have to issue a new CR-like document (the exact format will depend on the exact process we use, let us not go into this right now) and the exit criteria of the time will decide whether that particular feature would "make it" or not. It will be up to the WG to make the right judgement on the expectation of implementation: go into that particular step only if the implementations are really to be expected. So the features, in some sense, may be all in a situation of not at risk or they will simply be forgotten as far as the spec is concerned. The in-between "at-risk" situation may not occur. |
During the last VCWG face-to-face in Miami, there were several work items that were rejected because we "wouldn't have time given the current deadlines".
If we are extending the charter for two years, we really should give these work items a chance to be adopted as we continue the work of the working group.
If, instead, we just want the WG to complete the work it has already committed to, then one year is a more appropriate timeframe, especially as the refusal to consider the work in Miami meant that the NEXT charter is the correct place to consider the work. That would be now.
So, is this a charter to finish the work or to continue the work?
The text was updated successfully, but these errors were encountered: