Two years continued restrictions on deliverables is problematic

[jandrieu]

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?

[iherman]

@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.

So, is this a charter to finish the work or to continue the work?

IMHO, It is to finish and to ensure continuous maintenance of the current work.

[iherman]

@jandrieu are you satisfied with the answer I gave in #114 (comment)? We should then close this issue...

[jandrieu]

@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.

@awoie @SmithSamuelM @swcurran

[iherman]

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.)

[iherman]

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 […]

@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.)

[selfissued]

What additions are you looking for in the charter, Joe? Your issue doesn't say.

[decentralgabe]

@jandrieu

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.

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.

[iherman]

The issue was discussed in a meeting on 2024-05-15

• no resolutions were taken

View the transcript

2.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.
… I want to have that discussion.

Manu Sporny: The ACDC decision was not just about timing.
… We were trying to not add more work to the group.
… As for the two-year timeframe and no new work items, the reasoning was sound.
… We can do another 6-month extension.
… Why don't we do things that don't put enormous time pressure on the WG.
… We can do a two-year extension.
… We don't want to see what happened to the DID WG happen to the VC WG.
… Resulting in another round of formal objections.
… We're going to continue doing the work everyone agreed to do and finish it.
… We can recharter in 2025.
… Once we get done with our 11 work items, we can then think about rechartering.

Dave Longley: +1 to get existing work items done and then consider recharter on what to work on which will be a bigger discussion.

Dave Longley: (i.e., after current recharter which focuses on existing work items and just extending time).

Manu Sporny: We want to have that discussion in a way that enables broad feedback.
… The time to do that isn't now when we're a month away from charter expiration.
… We've made good progress.

Ivan Herman: The experience with our own community is that creating a new charter is subject to long and tedious discussions.
… Creating a new charter is a long thing.
… Even in the best of times, this requires ~6 months discussion.
… We need to finish what we've started.

Brent Zundel: and there's no reason those discussions can't happen anyway under the new charter.

Dave Longley: -1 to 1.5 years, let's take the time we need and not repeat a problem there.

Ivan Herman: I don't see anything happening on a new charter until January.

Manu Sporny: Plus, let's remember that we have active incubation in CCG, work can proceed there.

Dave Longley: +1.

Joe Andrieu: We have a few things that are at risk.
… Confidence Method.

Ivan Herman: About two months ago there was a WG discussion.
… Does the WG want to make changes to published recommendation?
… New features.

Manu Sporny: It used to be possible to publish a note and convert it to a recommendation.
… That loophole has since been closed.

Ted Thibodeau Jr.: I think it matters that this new Overview Work Item is not entirely new content, but rather collects content from other less-optimal places where we've already largely written it.

Manu Sporny: Confidence Method and Render Method is right up there.
… We're overloaded.

Dave Longley: +1 to getting existing work out the door and then look into recharter to add all of these great new things for the next phase.

Manu Sporny: I would personally -1 to new work until we finish what we've started.
… People have the chance to work on anything else in parallel.

Dave Longley: (and a number of those things will benefit from more incubation in the time frame).

Ted Thibodeau Jr.: Also note that while REC-track-in-progress should not be "parked" as NOTE, REC-track-in-progress can be "parked" as DRAFTs.

Manu Sporny: We could incubate these things in the CCG.
… That gives us a good argument to recharter with these things in scope.

Joe Andrieu: I think if we cannot include work that's currently noted as at risk, I will oppose rechartering.
… We don't need two years to finish what we started.

Manu Sporny: They're not getting done because people aren't doing the work.
… I'm hesitant to recharter presuming things are going to change.
… The FedID group is a good example.
… At the last minute they wanted to add digital credentials.
… The work hasn't been incubated.
… Many of the extension points are in the category that we don't know how long they're going to take.
… We have to have an active charter to fix problems and publish updated specs.
… After we finish the 11 things, that's when to discuss new charter items.
… We have extension points.

Dave Longley: asking to recharter to add more work is an item that has to happen and get consent at some point no matter what -- clearly it will be easier to get that consent later than now (based on the comments here).

Manu Sporny: A working group isn't required to use the extension points.

Ivan Herman: We have 1 month left in our charter.
… We have one shot at a 6 month extension.
… Or we can recharter for 2 years.
… Joe, what do you want?
… What is the chartering process you want at the W3C?

Joe Andrieu: I want the charter change.
… We're conflating finishing our work and our maintenance role, preventing new work from being done.

Ivan Herman: At any time, we can decide what we want in a new charter and recharter.

Dave Longley: any existing work items can reach draft form only?

Dave Longley: (that aren't already in CR).

Manu Sporny: I don't know what new text you want in the charter.
… We can do an administrative extension or a full extension.

Michael Jones: The AC has already agreed to the scope of our current charter.

Manu Sporny: Once we add new things, there will likely be objections.

Gabe Cohen: +1 to what Manu said.
… Let's take the easy option first.

Joe Andrieu: +1 is the six months "free" charter extension.

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.
… All the issues should be clearly closed.

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.
… I can give you a list.

Brent Zundel: We are going to stop talking about this.
… Ivan, please request an administrative extension.
… If we can't come to an agreement, we'll be in an unknown state.

[jandrieu]

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.

[brentzundel]

@jandrieu could you list the additional work items that you want included in this charter draft?

[iherman]

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.

[jandrieu]

@jandrieu could you list the additional work items that you want included in this charter draft?

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

[iherman]

(Admin)

It's not clear if Ivan has already pulled the trigger or not,

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).

[iherman]

(More on the content, but also Admin):

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.

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.

[decentralgabe]

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.

[iherman]

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.