Name suggestions for the proposed working group

[pchampin]

Several W3C members objected to the creation of the Solid Working Group, arguing that the charter seemed too much biased towards a per-conceived solution, rather than trying to solve a problem. See https://github.com/w3c/charter-drafts/issues/458 .

In order to respond to these objections, we intend to submit a new charter where the Solid specifications will be used as input, but where the name and mission of the working group are expressed in more generic terms. The mission has been updated but the name is still to be decided.

Please make proposals for the name of the upcoming Working Group by responding to this issue with the text:

PROPOSAL: <your proposal here>

optionally followed by an explanation/rationale for the name you propose. You may also respond with comments on previous proposals.

[VirginiaBalseiro]

As discussed in CG meeting, we will decide on a final name at the weekly CG meeting next Wednesday April 24th at 14:00 UTC, so make sure to vote on #75 before that time.

[TallTed]

@timbl --

In related news in the mailing list https://lists.w3.org/Archives/Group/group-council-2024-02/2024Feb/0010.html

Please note that the message cited above is not world-readable. Most people on this GitHub thread do not have relevant permissions, and are thus left with incomplete and inaccurate context, based on your paraphrase of what was said there.

@cwilso -- Thank you for the comment explaining the council renaming request. It seems entirely reasonable and appropriate to me, and I would suggest to whomever is in charge of naming the Council mailing lists and similar that they adopt a modified pattern like group-council-YYYY-MM-<distinct>, where <distinct> is replaced by an string that's unique per council originating within that month, which might or might not be solid in this case.

[timbl]

there was an AC meeting. People from the TAG were there as well as the people from the council. They expressed interest in seeing the new charter, especially if it addresses formal objections. If the formal objections are removed, it won't need another AC vote. We should send this new charter to the TAG as soon as possible. Even if the objections are not withdrawn, the council has the power to override them. I would like to send out new charter by the end of this week. I believe we addressed the objections as well as we could.

@pchampin , https://hackmd.io/cTf4AprtTTi2kjF6NJtAYQ?view

[timbl]

@TallTed Yes I left a reference to a non-public thing, as @cwilso does I suppose when he says "I would suggest that such an override is unlikely in this case, for reasons I can't discuss outside the council+Team, but I could be wrong.".

[cwilso]

Tim, the pointer you sent was to a confidential communication of the Council itself. Please do not share the contents of confidential communications of Councils. (https://www.w3.org/2023/Process-20231103/#council-deliberations)

Actually, part of my reasoning I CAN discuss outside the Council: there are three potential resolutions here - either

1. the Council performs further attempts to broker consensus (i.e. get the formal objectors to remove their objections), or
2. the Council has consensus, OR fails to reach consensus but votes and has a simple majority to uphold the objection (in which case, the Council may provide recommendations on mitigations), or
3. the Council has consensus, OR fails to reach consensus but votes and has a simple majority to override the objections. If this happens, the Council may make recommendations, but they are not binding (e.g. "you have to take the charter edits since the AC vote"); they are flat-out overruling the objections. This is the case that I suggested was unlikely; not because I have insider knowledge, but because it is a high bar. Again, this is merely my opinion.

[csarven]

tl;dr: Renaming is not only necessary, it shows genuine efforts made towards incorporating the feedback received, as opposed to ignoring the feedback and hoping that, by chance, the council and other teams will look the other way.

---

Background/Explanation:

The feedback from AC was summarised (and some linked to) in the form of publicly accessible issues since mid 2023-10:

https://github.com/w3c/charter-drafts/issues?q=is%3Aissue+is%3Aopen+wg%2Fsolid

Also summarised in a Solid CG meeting:

https://github.com/solid/specification/blob/main/meetings/2023-10-11.md#wg-charter-proposal-status-update

There is also the TAG review since 2023-11:

https://github.com/w3c/strategy/issues/377#issuecomment-1790209071

As well as AB feedback: [citation needed].

All touch on concerns, including (formal) objections, literally about the naming of the WG. In a nutshell, the name and charter come across as technology/solution/proprietary-centric in its totality. Although naming was just one aspect in the process to update the charter, the Solid Protocol is now even presented as one possible input document for the deliverable. We've discussed these topics in this repo as well as Solid CG meetings which are on record.

The Solid CG's position from the get-go has been to take all that feedback and work with the Team contact (Pierre-Antoine) towards a solution addressing the raised concerns as best as it could and to go from there. Of course, certain decisions within the W3C (Team) domain are beyond the Solid CG's jurisdiction, and (leading) objections regarding those matters fall outside its scope.

As I see it, ignoring feedback (including the renaming) and support to update the charter would be both illogical and undermine all the work we've done. It would also be overly hopeful (for my taste) to send something off to the assigned council and expect that they may overlook or hypothetically override, which is counter to all the signs that are given to us.

That's why we actually need a new name.

[timbl]

@cwilso said

Tim, the pointer you sent was to a confidential communication of the Council itself. Please do not share the contents of confidential communications of Councils. (https://www.w3.org/2023/Process-20231103/#council-deliberations)

Well giving the URI of a confidential communication is not the same as giving the communication itself, but I will delete my message just to be sure.

[oolivo]

I'm not at all proposing we ignore the feedback. There were objections about a number of things and many of them have been addressed. This however is one area where in trying to address it, we're likely to only create more confusion and instigate more objections. In the feedback you cite, the name is often pointed to as an issue in the scope and remit of the group not being clear. I.e. not setting a problem statement but rather just saying we're going to standardize Solid. And the name itself is not self descriptive so as a result it comes off as solution centric. Since then, a lot of work has gone in to make the problem statement and scope much clearer in the charter.

So we can still change the name to fully satisfy the objections, and potentially trigger a handful of new objections to be raised due to the new name (I'd be pleasantly surprised if this wasn't the case). Or we can point to the heavy clarifications that have been made in scope and problem statement, and see if this satisfies most if not all of the objections around it not being obvious what the goals of the group are.

I guess what I'm missing is the W3C making an authoritative statement that all WG's should be named after the problem space they are solving and therefore Solid WG is not an acceptable name . If that's the case, then renaming makes perfect sense and the objection is valid. But if there is no such authoritative statement, and we're making such a major change that is likely to introduce additional complexity and confusion in the space, as well as likely raise additional objections and lose all brand recognition to newcomers, then I just don't get why we would do it to address an objection that is in many ways already addressed by the updates to the charters scope. Changing the name effectively decouples the WG from this CG as well as from all the work that has led up to this proposal. Are we planning on also renaming the CG?

I would like to know the W3C's official stance on this before we make a decision and determine this is necessary. This introduces a lot of noise that I've yet to be convinced or seen compelling evidence is required to move forward. But that doesn't mean it's not out there, but there are a lot of WGs currently in existence that describe the solution being worked on, not the problem space so it's unclear at best.

[csarven]

We are taking the feedback and finding ways to improve the situation so that when the updated charter is revisited, there is a sense of mutual understanding among different parties that there was an attempt to address the issues in good faith.

FWIW, have a look over active groups at https://www.w3.org/groups/wg/ or dig deeper into closed WGs or even other CG names. Yes, they mainly focus on problem areas. So are the names that are proposed in this issue. "Solid WG" is nothing like those. Even our earlier use of "Social Linked Data" (SoLiD) would be a more meaningful WG name than "Solid". Having been on Solid since 2015, I can safely say that the term meant absolutely nothing to anyone who didn't have the background or context already, besides a state of matter. If anything, it overlaps with several projects that are also using the term "solid".

As already mentioned, insisting on "Solid WG" works against the feedback. All things being equal, it is safer to go with a different name. We are essentially removing what was once the target of an objection. That's a way to reduce potential objections and tends to hold true the same way for working through the W3C Recommendation Track. The name of the WG is certainly not the hill to die on. Do we want to "fix the Web" (TM) or get stuck on naming / worry about marketing or whatever?

Unfortunately, you'll have to read between the lines to see the "authoritative statements." But as I see it, that's already the feedback from the W3C Community to some degree, in addition to what one draws from various guidance, e.g., https://www.w3.org/Guide/standards-track/#criteria . I'm sure in due time there'll be a crystal clear answer to such questions (if not already out there) but perhaps in the meantime consider creating an issue at https://github.com/w3c/charter-drafts .

The suggested WG names and poll results will be handed off to W3C Team. They or the W3C Community can respond back with what works or doesn't. We ought to still follow W3C community's guidance on this because that's just how this stuff rolls. If the new name becomes an issue, we'll cross that bridge then.

Aside: I don't have a carrot in the naming patch. In fact, I chose to abstain from voting on the name and will be content with the consensus, whether it stays as "Solid" or changes to something else.

Lastly, discussing whether to name or not at the 11th hour is rather strange. Not that we can't undo, but the Solid CG had ample time to discuss this matter. So, I don't particularly find this constructive.

[oolivo]

Thanks @csarven, appreciate the thoughts. Perhaps we should take this conversation to another thread. I'm not trying to be disruptive at the 11th hour or be non-constructive. There is simply a lack of clarity in this whole process that is somewhat frustrating.

If I'm being candid, the reason I'm coming in at "the 11th hour" is because I was standing by the sidelines waiting for official guidance from the W3C on what we should address vs. shouldn't. It's perfectly reasonable for the group to discuss how we address all objections, if possible. But it's also reasonable for us to agree to disagree on some and receive guidance from the W3C on where to go from there.

The idea in this issue is that "if we address all objections in the revised charter then it will be accepted" seems fraught. Some objections are clear and obvious and simple to address. But there are a number of objections that we simply are not addressing. Some objections were that we should include blockchain in the scope, for example. We clearly are not addressing that objection. Is that going to be a problem? If so, who decides whether those objections are valid or not? Whats the criteria for which objections need addressing and which ones don't and merit holding the line on? And who's giving that guidance?

I realize I'm asking a larger question, outside the scope of this issue so I'll take it elsewhere. But I'd like clarity on where the guidance is coming from and whether it is transparant and available somewhere. I hear you that on this particular issue it seems like that may be the direction the W3C is moving in and "I need to read between the lines", but that shouldn't be the case. These things should be clear so that we aren't wasting the groups time and so that folks can better judge where to spend their time.

I've been closely following all the CG meetings and minutes and issues. And nowhere have I seen clear guidance on which objections need addressing vs. which don't and what the W3C's expectations are for approval. If agreements have been made behind closed doors, I guess thats fine since theres politics involved, but it feels awfully opaque for a process that should be open and transparant. It all feels a bit backwards that a policy that doesn't actually exist today is being used to object and block a charter, and that the fact that it successfully did so will be used as a precedent to essentially will the policy into existence. The W3C should just make the policy and then call it a day. Or not.

I hear your point that we should just move forward and try to compromise as much as possible (within reason) to get the group formed. Ultimately I agree with that and this is not a hill to die on. So I'm not so much objecting to the name change as much as I'm asking for clarification to just how in the world this W3C objection and revision process actually works because it all seems a bit arbitrary and opaque. But I realize this probably isn't the place to do it at this point as i'm asking a much more meta question. I'll take this elsewhere.

Thanks.

[cwilso]

@oolivo "The W3C" cannot give definitive guidance on what must be addressed. I would say you should try to address all feedback. Ultimately, the "must" will be determined by either 1) a lack of Formal Objections from the AC, or 2) a Formal Objection Council. There is no single arbiter of decisions. The easiest path is to address all the feedback in all FOs received; if the Team or Council can broker all formal objectors removing their FOs, you would be done.

Of course, that may not be possible, or may not be something you want to do. I don't see any request that blockchain be in the scope in the AC poll; but if there were something really antithetical - or something that was a clear "if we fix this FO, we're trading for this other FO" - then it would probably ultimately go to a FO Council to adjudicate.

(In this case, I would point out there were eight different comments in the charter response citing the focus on SOLID in the name or the choice of SOLID as the only possible solution, including all four Formal objections. That does in fact seem like something that should be addressed.)

[elf-pavlik]

I am speaking from the perspective of a regular Solid CG participant. To my understanding, the W3C Team is proposing a new working group, and Solid CG provides feedback to our best capacity. Given that, I trust @pchampin to lead this process and incorporate Solid CG feedback in the best possible way.

Wherever the W3C process appears unclear, maybe we should raise it in https://github.com/w3c/w3process/issues/. This would hopefully help all future groups go through their chartering process.

[melvincarvalho]

Seems to be 2 projects, 2 names, with an overlap

1. Social project stems from Linked data and FOAF, foaf-protocols etc. and is about users, connections, and friends. Typical apps: micro blogging, chat

2. Data storage stems from Linked Data Platform, and is about standards to read and write data with access control. Typical apps: document editor, file explorer.

Name should indicate whether the focus will be on chunk (1) or chunk (2) or a "big tent" approach. Personally (1) resonates with me quite alot. Each choice will have a few trade-offs. Probably the easiest way to reduce the objections is to cut out the non-essential stuff, and move that into v2.